Ошибка GSS -API Принятие контекста: Ключ сервиса недоступен - Solaris Code, Windows KDC
Вопрос
Я пытаюсь получить тестовую пару клиента/сервера Kerberos, работающую против Active Directory. Я создал трех пользователей в запасном домене в нашей корпоративной сети, «Richardc», «Server1» и «Server2». Пользователи моего сервера были сопоставлены с разными именами основных услуг, один с KRB5_NT_PRINCIPAL, другой с KRB5_NT_SRV_HOST.
ktpass -out server2.keytab
-princ server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
-mapuser ServerUser2@BENCHMARKING.RDDEV.LOCAL
-pass ThePassword
-crypto All
-pType KRB5_NT_SRV_HOST
-kvno 2
На этот раз я не использовал вариант +DeSonly, надеясь, что в современных системах мне не нужен DES. Я заменил реальное доменное имя с MyDomain в этом вопросе, чтобы избежать заботы о управлении.
Это дает мне Keytab. Я могу поставить это:
KVNO Principal
---- --------------------------------------------------------------------------
2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (DES cbc mode with CRC-32)
2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (DES cbc mode with RSA-MD5)
2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (ArcFour with HMAC/md5)
2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (AES-256 CTS mode with 96-bit SHA-1 HMAC)
2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (AES-128 CTS mode with 96-bit SHA-1 HMAC)
Я даже могу использовать Kinit -K, чтобы войти в систему, используя ключ из KeyTab - так что, кажется, работает.
У меня есть как моя собственная программа тестирования, так и сбой, что программа тестирования из http://download.oracle.com/docs/cd/e19683-01/816-1331/sampleprogs-1/index.html. Анкет В этой программе, на сервере, я изменил GSS_C_NT_HOSTBADE_SERVICE на GSS_C_NT_USER_NAME с обеими KeyTabs, чтобы он распознавал имя. Я запускаю демо -сервер Oracle как
./gss-server -mech 1.2.840.113554.1.2.2 server2/serbia.mydomain.com
и клиент
./gss-client -mech 1.2.840.113554.1.2.2 serbia.mydomain.com server2 "Hello"
Результат:
GSS-API error accepting context: Invalid credential was supplied
GSS-API error accepting context: Service key not available
Как в этом случае, так и с моим собственным тестовым кодом ошибка возникает после того, как клиент отправил свой первый токен, в то время как сервер пытается его декодировать.
KLIST показывает ключ, предоставленный для клиента. Он использует Arcfour, который находится в KeyTab
Default principal: RichardC@BENCHMARKING.RDDEV.LOCAL
Valid starting Expires Service principal
07/25/11 17:36:49 07/26/11 03:35:18 krbtgt/BENCHMARKING.RDDEV.LOCAL@BENCHMARKING.RDDEV.LOCAL
renew until 08/01/11 17:36:49
07/25/11 17:36:03 07/26/11 03:35:18 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
renew until 08/01/11 17:36:03
Машина UNIX (Сербия) может быть, возможно, принадлежать другому сфере (той, которую я назвал здесь myDomain.com, хотя, похоже, у нее нет установки Kerberos. Я использую локальный файл krb5.conf, который я указал на Benchmarking.rddev.local Realm, хотя, если машина пытается использовать DNS с его именем хоста, он может получить неправильный ответ. У моего KRB5.conf есть
[libdefaults]
default_keytab_name = /users/dev/core/richardc/server1.keytab
default_realm = BENCHMARKING.RDDEV.LOCAL
dns_lookup_kdc = false
default_tkt_types = DES-CBC-MD5
[realms]
BENCHMARKING.RDDEV.LOCAL = {
kdc = gbha-dcbench01p.benchmarking.rddev.local
admin_server = gbha-dcbench01p.benchmarking.rddev.local
}
[domain_realm]
benchmarking.rddev.local = BENCHMARKING.RDDEV.LOCAL
.benchmarking.rddev.local = BENCHMARKING.RDDEV.LOCAL
mydomain.com = BENCHMARKING.RDDEV.LOCAL
.mydomain.com = BENCHMARKING.RDDEV.LOCAL
Похоже, что параметры, такие как default_tkt_types, были неэффективными.
Вопрос - как исправить свою ошибку?
Спасибо - Ричард
Решение
Проблема была в
ktpass -out server2.keytab
-princ server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
-mapuser ServerUser2@BENCHMARKING.RDDEV.LOCAL
-pass ThePassword
-crypto All
-pType KRB5_NT_SRV_HOST
-kvno 2
Это заставляет Windows увеличить номер версии. Полученный ключ не является проблемой для входа в «Kinit -K» по какой -то причине, но приводит к выходу из строя кода сервера GSS -API с помощью бесполезного «сервисного ключа, недоступного» в Solaris Systems.
Система Windows была 2008R2. Я понимаю, что поведение этой команды различалось между разными версиями Windows.
Я успешно протестировал с Desonly. Мне нужно вернуться в бедный ИТ-отдел для любых других тестов :-)
Решение состоит в том, чтобы пропустить аргумент -kvno.
ktpass -out server4.keytab
-princ server4/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
-mapuser ServerUser4@BENCHMARKING.RDDEV.LOCAL
-pass ThePassword
-crypto DES-CBC-MD5
-pType KRB5_NT_USER_PRINCIPAL
Это дает выход
Targeting domain controller: GBHA-DCBENCH01P.benchmarking.rddev.local
Using legacy password setting method
Successfully mapped server4/serbia.mydomain.com to Server4.
Key created.
Output keytab to server4.keytab:
Keytab version: 0x502
keysize 79 server4/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL ptype 1
(KRB5_NT_PRINCIPAL) vno 5 etype 0x3 (DES-CBC-MD5) keylength 8 (0xd1532a6d0f2a8631)
Account Server4 has been set for DES-only encryption.
Обратите внимание на «VNO 5» на выходе.
Я протестировал с обоими значениями на -ptype. Оба работают.
Мой код GSS использует GSS_C_NT_HOSTBADES_SERVICE, но все это, кажется, изменяется, - это формат, необходимый для ввода имени.
(Я изменил ключ выше)
Приложение
Мое окончательное решение использует -ptype krb5_nt_user_principal
Мой код GSS использует GSS_C_NT_USER_NAME, чтобы найти имя, и я указываю полное имя server4/serbia.mydomain.com@benchmarking.rddev.local. Анкет Я обнаружил, что не все платформы, над которыми я работал, приняли GSS_C_NT_HOSTBADES_SERVICE, но все они принимают GSS_C_NT_USER_NAME.
Человек, который устанавливает наше приложение сервера, устанавливает основное имя сервера в качестве параметра конфигурации. Это казалось самым надежным способом. Человек, который устанавливает ключ, так что знает, что это такое, говорит приложению напрямую, какой ключ использовать.