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 шага.
- Активируйте AES для учетной записи, как описано в статье T.Herons
- Используйте 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. Это малоизвестная проблема. В вашем случае я бы запустил следующий процесс из шести шагов, и он должен работать:
setspn -D HTTP/myapp.my.domain MyappEU
Затем сгенерируйте 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
Убедитесь, что нужное вам SPN находится в учетной записи Active Directory:
setspn -L MyappEU
- Убедитесь, что новое имя участника-службы отражено в поле "Имя пользователя для входа в систему" на вкладке "Учетная запись" учетной записи Active Directory и установите флажок "Эта учетная запись поддерживает 256-битное шифрование Kerberos AES" ниже:
- В файле standalone.xml на сервере JBOSS не забудьте обновить имя файла keytab, а затем перезапустить механизм JBOSS, чтобы изменения вступили в силу.
- Наконец, вам потребуются файлы JAR с неограниченнойнадежностью шифрования в вашем каталоге Java_Home\lib\security на сервере JBOSS, иначе ваша keytab не сможет расшифровать билеты Kerberos AES256-SHA1. Если вы уверены, что проблема не в шагах 1–5, возможно, именно в этом.