Kerberos - AES-256 Keytab не работает

Наша команда AD собирается отключить RC4-HMAC, поэтому я должен изменить наши JBoss-приложения на AES. Я добавил типы aes в krb5.conf и создал новые keytabs, но это, похоже, не работает. Тесты помимо приложения с kinit показывают такие же результаты.

Возникла аналогичная проблема, но ее решение уже было разрешено для нас. Есть еще один парень (Рик Мориц), у которого моя проблема без ответа.

Сервер: SLES12

AD: Windows Server 2016.

krb5.conf

[libdefaults]
  debug = false
  default_realm = MY.DOMAIN
  ticket_lifetime = 24000
  default_keytab_name = /app/myapp/sso/myapp_eu.keytab_AES
  dns_lookup_realm = false
  dns_lookup_kdc = false
  default_tkt_enctypes = aes256-cts aes128-cts rc4-hmac
  default_tgs_enctypes = aes256-cts aes128-cts rc4-hmac
  permitted_enctypes = aes256-cts aes128-cts rc4-hmac

[realms]
  MY.DOMAIN = {
    kdc = my.domain
    default_domain = my.domain
  }

[domain_realm]
  .my.domain = MY.DOMAIN
  my.domain = MY.DOMAIN

[appdefaults]
  forwardable = true

Клавиатуры

keytab старый RC4:

klist -ket myapp_eu.keytab_RC4
Keytab name: FILE:myapp_eu.keytab_RC4
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   0 02/19/2018 14:41:39 [email protected] (arcfour-hmac)

keytab новый AES256:

klist -ket myapp_eu.keytab_AES
Keytab name: FILE:myapp_eu.keytab_AES
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   0 03/14/2018 15:03:31 [email protected] (aes256-cts-hmac-sha1-96)

тесты kinit (krb5 версии 1.12.5)

аутентификация с паролем (успешная):

kinit -fV [email protected]
klist -ef
Valid starting     Expires            Service principal
03/14/18 14:37:12  03/15/18 00:37:12  krbtgt/[email protected]
        renew until 03/15/18 14:37:06, Flags: FRIA
        Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

аутентификация со старым keytab RC4 (успешная):

kinit -fV -k -t /app/myapp/sso/myapp_eu.keytab_RC4 [email protected]
klist -ef
Valid starting     Expires            Service principal
03/14/18 14:36:52  03/15/18 00:36:52  krbtgt/[email protected]
        renew until 03/15/18 14:36:51, Flags: FRIA
        Etype (skey, tkt): arcfour-hmac, aes256-cts-hmac-sha1-96

аутентификация с новой клавиатурой AES256 (сбой):

kinit -fV -k -t /app/myapp/sso/myapp_eu.keytab_AES [email protected]
Using principal: [email protected]
Using keytab: /app/myapp/sso/myapp_eu.keytab_AES
kinit: Preauthentication failed while getting initial credentials

Взгляд на etypes показывает, что aes, похоже, работает. Но я не могу понять, почему я получаю ошибку предварительной аутентификации с помощью aes-keytabs.

Старая и новая вкладки были созданы с помощью следующей команды ktpass:

ktpass -princ [email protected] -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass xxxxxxxx -kvno 0 -out myapp_eu.keytab_RC4
ktpass -princ [email protected] -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass xxxxxxxx -kvno 0 -out myapp_eu.keytab_AES

Я уже пробовал с правильным kvno вместо 0 с тем же результатом.

Спасибо за вашу помощь или идеи.

P.S. анонимные MY.DOMAIN и myapp

Тестируйте со свежей скомпилированной версией krb5 1.16

Я объединил советы Самсона Шарфрихтера и Т. Херона, и теперь я вижу разницу между SALT, которую я получаю от ktpass при создании keytab, и от трассировки вывода kinit. Но я не знаю, откуда это и как это изменить. В этом случае соль состоит из одного из SPN.

ktpass

PS X:\> ktpass -out x:\MyappEUv3.keytab -mapOp set +DumpSalt -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass xxxxxx -princ [email protected]
Building salt with principalname MyappEU and domain MY.DOMAIN (encryption type 18)...
Hashing password with salt "MY.DOMAINMyappEU".
Key created.
Output keytab to x:\MyappEUv3.keytab:
Keytab version: 0x502
keysize 71 [email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 1 etype 0x12 (AES256-SHA1) keylength 32 (0x326dd53c7fce5ac4f25d1d17c6a1cf721d7d044f7eb72eaa92a20125055a3b25)

след кинита

 env KRB5_TRACE=/dev/stdout /home/akirsch/krb5-1.16_made/bin/kinit -fV -k -t /home/akirsch/MyappEUv3.keytab [email protected]
 Using default cache: /tmp/krb5cc_0
 Using principal: [email protected]
 Using keytab: /home/akirsch/MyappEUv3.keytab
 [32175] 1521108914.135563: Getting initial credentials for [email protected]
 [32175] 1521108914.135564: Looked up etypes in keytab: aes256-cts
 [32175] 1521108914.135566: Sending unauthenticated request
 [32175] 1521108914.135567: Sending request (153 bytes) to MY.DOMAIN
 [32175] 1521108914.135568: Resolving hostname MY.DOMAIN
 [32175] 1521108914.135569: Sending initial UDP request to dgram 172.18.32.134:88
 [32175] 1521108914.135570: Received answer (214 bytes) from dgram 172.18.32.134:88
 [32175] 1521108914.135571: Response was not from master KDC
 [32175] 1521108914.135572: Received error from KDC: -1765328359/Additional pre-authentication required
 [32175] 1521108914.135575: Preauthenticating using KDC method data
 [32175] 1521108914.135576: Processing preauth types: 16, 15, 19, 2
 [32175] 1521108914.135577: Selected etype info: etype aes256-cts, salt "MY.DOMAINHTTPmyapp-entw.intranet-test.my.domain", params ""
 [32175] 1521108914.135578: Retrieving [email protected] from FILE:/home/akirsch/MyappEUv3.keytab (vno 0, enctype aes256-cts) with result: 0/Success
 [32175] 1521108914.135579: AS key obtained for encrypted timestamp: aes256-cts/ECF3
 [32175] 1521108914.135581: Encrypted timestamp (for 1521108914.396292): plain 301AA011180F32303138303331353130313531345AA1050203060C04, encrypted F92E4F783F834FF6500EA86CAF8CA3088517CB02F75BD2C962E5B454DC02C6F3BBCAF59EEB6F52D58AA873FF5EDFCA1496F59D2A587701A1
 [32175] 1521108914.135582: Preauth module encrypted_timestamp (2) (real) returned: 0/Success
 [32175] 1521108914.135583: Produced preauth for next request: 2
 [32175] 1521108914.135584: Sending request (231 bytes) to MY.DOMAIN
 [32175] 1521108914.135585: Resolving hostname MY.DOMAIN
 [32175] 1521108914.135586: Sending initial UDP request to dgram 10.174.50.13:88
 [32175] 1521108914.135587: Received answer (181 bytes) from dgram 10.174.50.13:88
 [32175] 1521108914.135588: Response was not from master KDC
 [32175] 1521108914.135589: Received error from KDC: -1765328360/Preauthentication failed
 [32175] 1521108914.135592: Preauthenticating using KDC method data
 [32175] 1521108914.135593: Processing preauth types: 19
 [32175] 1521108914.135594: Selected etype info: etype aes256-cts, salt "MY.DOMAINHTTPmyapp-entw.intranet-test.my.domain", params ""
 [32175] 1521108914.135595: Getting initial credentials for [email protected]
 [32175] 1521108914.135596: Looked up etypes in keytab: des-cbc-crc, des, des-cbc-crc, rc4-hmac, aes256-cts, aes128-cts
 [32175] 1521108914.135598: Sending unauthenticated request
 [32175] 1521108914.135599: Sending request (153 bytes) to MY.DOMAIN (master)
 kinit: Preauthentication failed while getting initial credentials

authentication kerberos sles keytab ktpass
person Spezieh    schedule 14.03.2018    source источник
comment
В Java есть флаги трассировки для отладки Kerberos - нелегко понять, но, по крайней мере, вы можете сравнить сценарии OK / KO и увидеть, где эта чертова штука не работает ›› -Djava.security.debug=gssloginconfig,configfile,configparser,logincontext и -Dsun.security.krb5.debug=true   -  person Samson Scharfrichter    schedule 14.03.2018
comment
Для кода C, например. _1 _... Я не знаком с выводом KRB5_TRACE, но это может помочь. k5wiki.kerberos.org/wiki/Debugging_tips   -  person Samson Scharfrichter    schedule 14.03.2018
comment
У вас нет субъекта-службы, определенного в синтаксисе ktpass. Вместо этого вы указали принципала пользователя. См. В моей статье хороший пример синтаксиса ktpass (примерно на полпути вниз): social.technet.microsoft.com/wiki/contents/articles/   -  person T-Heron    schedule 15.03.2018
comment
По какому URL-адресу переходят клиенты, когда попадают в ваше приложение JBOSS? После этого я смогу написать подробный ответ о том, как это работает.   -  person T-Heron    schedule 15.03.2018
comment
@Samson Scharfrichter Я добавил параметры, но он не дает больше, чем мой вывод отладки по умолчанию. Я добавляю части логов к своему основному вопросу.   -  person Spezieh    schedule 15.03.2018
comment
@ T.Heron Каким-то образом приложение уже могло использовать этот UPN и его keytab с RC4. У нас тоже есть несколько SPN (http / myapp.my.domain), и с ним мы получаем те же результаты. Я использовал пользователя в примерах здесь, потому что у меня возникла такая же проблема с KINIT. Так что, думаю, проблема не в приложении, а в самой клавише. Кстати, спасибо за статью. Я собираюсь проверить это сейчас   -  person Spezieh    schedule 15.03.2018
comment
Мои 2 цента: отключить UDP. Я слышал ужасные истории о странных ошибках, которые исчезли после принудительного использования TCP для клиентов Kerberos ...   -  person Samson Scharfrichter    schedule 15.03.2018
comment
Правда. И если вы используете Active Directory 2008 или более поздней версии, сначала всегда пробуется TCP, потому что для MaxPacketSize по умолчанию установлено значение 0 в этой версии и во всех более новых версиях. Пер: support.microsoft.com/en-us/help/244474/   -  person T-Heron    schedule 15.03.2018

Ответы (2)


arrow_upward
2
arrow_downward

Спасибо T.Heron и Samson за советы.

В конце оставалось сделать всего 2 шага.

  1. Активируйте AES для учетной записи, как описано в T. Статья о цаплях
  2. Используйте ktpass с mapuser, чтобы установить соль для принципала, который используется в качестве входа в систему. (будет показана ошибка, но соль все равно будет установлена)

Вторую часть узнать было сложно. MapUser установит для SALT и UPN имя SPN, которое отображается! СОЛЬ может быть только одна.

Вы можете увидеть текущую соль в Linux, используя:

env KRB5_TRACE=/dev/stdout env KRB5_CONFIG=krb5.conf kinit -fV [email protected]

ExampleOutputLine (неправильная соль в данном случае)

[10757] 1523617677.379889: Selected etype info: etype aes256-cts, salt "MYDOMAIN.COMHTTPvm41568226", params ""
person Spezieh    schedule 29.03.2018

arrow_upward
0
arrow_downward

Убедитесь, что вы удалили SPN из учетной записи Active Directory, связанной с keytab, перед созданием новой keytab. Это малоизвестная проблема. В вашем случае я бы выполнил следующий шестиэтапный процесс, и он должен работать:

  1. setspn -D HTTP/myapp.my.domain MyappEU

  2. Затем сгенерируйте keytab:

    ktpass -princ HTTP/myapp.my.domain -mapUser [email protected] -pass xxxxxxxx -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -kvno 0 -out myapp_eu.keytab_AES

  3. Убедитесь, что нужное вам SPN находится в учетной записи Active Directory:

setspn -L MyappEU

  1. Убедитесь, что новое имя участника-службы отражено в поле «Имя пользователя для входа в систему» ​​на вкладке «Учетная запись» учетной записи Active Directory и установите флажок «Эта учетная запись поддерживает 256-битное шифрование Kerberos AES, ниже которого установлен флажок:

Вкладка

  1. В файле standalone.xml на сервере JBOSS не забудьте обновить имя файла keytab, а затем перезапустить механизм JBOSS, чтобы изменения вступили в силу.
  2. Наконец, вам понадобится Java JAR с неограниченной надежностью шифрования. файлы в вашем каталоге Java_Home \ lib \ security на сервере JBOSS, иначе ваша keytab не сможет расшифровать билеты Kerberos AES256-SHA1. Если вы уверены, что проблема не в шагах 1–5, то, возможно, это именно то, что вам нужно.
person T-Heron    schedule 15.03.2018