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

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

Keytabs

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 MyappEU@MY.DOMAIN (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 MyappEU@MY.DOMAIN (aes256-cts-hmac-sha1-96)

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

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

kinit -fV MyappEU@MY.DOMAIN
klist -ef
Valid starting     Expires            Service principal
03/14/18 14:37:12  03/15/18 00:37:12  krbtgt/MY.DOMAIN@MY.DOMAIN
        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 MyappEU@MY.DOMAIN
klist -ef
Valid starting     Expires            Service principal
03/14/18 14:36:52  03/15/18 00:36:52  krbtgt/MY.DOMAIN@MY.DOMAIN
        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 MyappEU@MY.DOMAIN
Using principal: MyappEU@MY.DOMAIN
Using keytab: /app/myapp/sso/myapp_eu.keytab_AES
kinit: Preauthentication failed while getting initial credentials

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

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

ktpass -princ MyappEU@MY.DOMAIN -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass xxxxxxxx -kvno 0 -out myapp_eu.keytab_RC4
ktpass -princ MyappEU@MY.DOMAIN -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass xxxxxxxx -kvno 0 -out myapp_eu.keytab_AES

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

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

PS анонимно MY.DOMAIN и myapp

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

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

Ktpass

PS X:\> ktpass -out x:\MyappEUv3.keytab -mapOp set +DumpSalt -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass xxxxxx -princ MyappEU@MY.DOMAIN
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 MyappEU@MY.DOMAIN ptype 1 (KRB5_NT_PRINCIPAL) vno 1 etype 0x12 (AES256-SHA1) keylength 32 (0x326dd53c7fce5ac4f25d1d17c6a1cf721d7d044f7eb72eaa92a20125055a3b25)

след kinit

 env KRB5_TRACE=/dev/stdout /home/akirsch/krb5-1.16_made/bin/kinit -fV -k -t /home/akirsch/MyappEUv3.keytab MyappEU@MY.DOMAIN
 Using default cache: /tmp/krb5cc_0
 Using principal: MyappEU@MY.DOMAIN
 Using keytab: /home/akirsch/MyappEUv3.keytab
 [32175] 1521108914.135563: Getting initial credentials for MyappEU@MY.DOMAIN
 [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 MyappEU@MY.DOMAIN 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 MyappEU@MY.DOMAIN
 [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

1 ответ

Решение

Спасибо и Т.Херону, и Самсону за подсказки.

В конце было всего 2 шага.

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

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

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

env KRB5_TRACE=/dev/stdout env KRB5_CONFIG=krb5.conf kinit -fV ADUSER@MYDOMAIN.COM

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

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

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

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

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

    ktpass -princ HTTP/myapp.my.domain -mapUser MyappEU@MY.DOMAIN -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. Наконец, вам потребуются файлы JAR с неограниченнойнадежностью шифрования в вашем каталоге Java_Home\lib\security на сервере JBOSS, иначе ваша keytab не сможет расшифровать билеты Kerberos AES256-SHA1. Если вы уверены, что проблема не в шагах 1–5, возможно, именно в этом.
Другие вопросы по тегам