Почему JDK1.8.0u121 не может найти типы kerberos default_tkt_enctypes? (KrbException: нет поддерживаемых etypes по умолчанию для default_tkt_enctypes)

Ниже приведены сведения о моей среде: -

Сервер KDC: Windows Server 2012

Целевая машина: Windows 7.

Версия JDK: Oracle 1.8.0_121 (64-разрядная версия)

Я получаю следующее исключение при запуске команды Java kinit на компьютере с Windows 7: -

C:\Program Files\Java\jdk1.8.0_121\bin>kinit -k -t "C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab" HTTP/[email protected]
Exception: krb_error 0 no supported default etypes for default_tkt_enctypes No error
KrbException: no supported default etypes for default_tkt_enctypes
        at sun.security.krb5.Config.defaultEtype(Config.java:844)
        at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:249)
        at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:262)
        at sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
        at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
        at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
        at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:219)
        at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)

Вывод команды в режиме отладки: -

C:\Program Files\Java\jdk1.8.0_121\bin>kinit -J-Dsun.security.krb5.debug=true -k -t "C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomca
t_ad.keytab" HTTP/[email protected]
>>>KinitOptions cache name is C:\Users\devtcadmin\krb5cc_devtcadmin
Principal is HTTP/[email protected]
>>> Kinit using keytab
>>> Kinit keytab file name: C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab
Java config name: null
LSA: Found Ticket
LSA: Made NewWeakGlobalRef
LSA: Found PrincipalName
LSA: Made NewWeakGlobalRef
LSA: Found DerValue
LSA: Made NewWeakGlobalRef
LSA: Found EncryptionKey
LSA: Made NewWeakGlobalRef
LSA: Found TicketFlags
LSA: Made NewWeakGlobalRef
LSA: Found KerberosTime
LSA: Made NewWeakGlobalRef
LSA: Found String
LSA: Made NewWeakGlobalRef
LSA: Found DerValue constructor
LSA: Found Ticket constructor
LSA: Found PrincipalName constructor
LSA: Found EncryptionKey constructor
LSA: Found TicketFlags constructor
LSA: Found KerberosTime constructor
LSA: Finished OnLoad processing
Native config name: C:\Windows\krb5.ini
Loaded from native config
>>> Kinit realm name is DEVDEVELOPMENT.COM
>>> Creating KrbAsReq
>>> KrbKdcReq local addresses for dev26 are:

        dev26/192.168.1.229
IPv4 address

        dev26/fe80:0:0:0:78ae:388f:4f63:3717%11
IPv6 address
>>> KdcAccessibility: reset
>>> KeyTabInputStream, readName(): DEVDEVELOPMENT.COM
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): dev26.devdevelopment.com
>>> KeyTab: load() entry length: 99; type: 18
Looking for keys for: HTTP/[email protected]
Added key: 18version: 3
Exception: krb_error 0 no supported default etypes for default_tkt_enctypes No error
KrbException: no supported default etypes for default_tkt_enctypes
        at sun.security.krb5.Config.defaultEtype(Config.java:844)
        at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:249)
        at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:262)
        at sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
        at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
        at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
        at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:219)
        at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)

Ниже приведены выходные данные команды ktpass на сервере KDC (Windows Server 2012) для создания файла tomcat_ad.keytab:

C:\Users\Administrator>ktpass /out C:\tomcat_ad.keytab /mapuser [email protected] /princ HTTP/[email protected] /pass ****** /crypto AES256-SHA1 ptype KRB5_NT_PRINCIPAL
    Targeting domain controller: dev.devdevelopment.com
    Using legacy password setting method
    Successfully mapped HTTP/dev26.devdevelopment.com to devtcadmin.
    Key created.
    Output keytab to C:\tomcat_ad.keytab:
    Keytab version: 0x502
    keysize 99 HTTP/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) keylength 32 (0xf20788d7c6f99c385fc91b53c7d9ef55591d314e5340ca1fb9acac1b178c8861)

Ниже приведено содержимое файла krb5.ini, который находится в папке C:\Windows на компьютере с Windows 7:

[libdefaults]
default_realm=DEVDEVELOPMENT.COM
default_keytab_name=“C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab"
default_tkt_enctypes=aes256-cts-hmac-shal-96
default_tgs_enctypes=aes256-cts-hmac-shal-96
permitted_enctypes=aes256-cts-hmac-shal-96
udp_preference_limit=1
forwardable=true

[realms]
DEVDEVELOPMENT.COM={
    kdc=dev.devdevelopment.com:88
}

[domain_realm]
devdevelopment.com=DEVDEVELOPMENT.COM
.devdevelopment.com=DEVDEVELOPMENT.COM

Ниже приведен вывод команды Java ktab на компьютере с Windows 7:

C:\Program Files\Java\jdk1.8.0_121\bin>ktab -l -e -t -k "C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab"
Keytab name: C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab
KVNO Timestamp      Principal
---- -------------- ---------------------------------------------------------------------------------------
   3 1/1/70 5:30 AM HTTP/[email protected] (18:AES256 CTS mode with HMAC SHA1-96)

Я также обновил JAR-файлы JCE в папках C:\Program Files\Java\jre1.8.0_121\lib\security и C:\Program Files\Java. папки \jdk1.8.0_121\jre\lib\security.

Что нужно сделать, чтобы преодолеть это исключение?

EDIT 1 (продолжение моего третьего комментария): -

Ниже приведен вывод первой команды knit с файлом tomcat_ad.keytab в папке C:\Program Files\Java\jre1.8.0_121\bin папка: -

C:\Program Files\Java\jdk1.8.0_121\bin>kinit -k -t tomcat_ad.keytab HTTP/dev26.devdevelopment.com
New ticket is stored in cache file C:\Users\devtcadmin\krb5cc_devtcadmin

Ниже приведены выходные данные команды kinit с файлом tomcat_ad.keytab в папке C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\. tomcat_ad.keytab и после добавления C:\Program Files\Java\jdk1.8.0_121\bin; в переменную среды path: -

C:\Users\devtcadmin>kinit -k -t "C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\tomcat_ad.keytab" HTTP/[email protected]
New ticket is stored in cache file C:\Users\devtcadmin\krb5cc_devtcadmin

НО команда kinit в режиме отладки на этот раз выдает следующее исключение: -

C:\Users\devtcadmin>kinit -J-Dsun.security.krb5.debug=true -k -t "C:\Program Files\Apache Software Foundation\Tomcat 8.5\conf\tomcat_ad.keytab" HTTP/[email protected]
>>>KinitOptions cache name is C:\Users\devtcadmin\krb5cc_devtcadmin
Principal is HTTP/[email protected]
>>> Kinit using keytab
>>> Kinit keytab file name: C:\Program Files\Apache Software Foundation\Tomcat 8.5\conf\tomcat_ad.keytab
Java config name: null
LSA: Found Ticket
LSA: Made NewWeakGlobalRef
LSA: Found PrincipalName
LSA: Made NewWeakGlobalRef
LSA: Found DerValue
LSA: Made NewWeakGlobalRef
LSA: Found EncryptionKey
LSA: Made NewWeakGlobalRef
LSA: Found TicketFlags
LSA: Made NewWeakGlobalRef
LSA: Found KerberosTime
LSA: Made NewWeakGlobalRef
LSA: Found String
LSA: Made NewWeakGlobalRef
LSA: Found DerValue constructor
LSA: Found Ticket constructor
LSA: Found PrincipalName constructor
LSA: Found EncryptionKey constructor
LSA: Found TicketFlags constructor
LSA: Found KerberosTime constructor
LSA: Finished OnLoad processing
Native config name: C:\Windows\krb5.ini
Loaded from native config
>>> Kinit realm name is DEVDEVELOPMENT.COM
>>> Creating KrbAsReq
>>> KrbKdcReq local addresses for dev26 are:

        dev26/192.168.1.229
IPv4 address

        dev26/fe80:0:0:0:78ae:388f:4f63:3717%11
IPv6 address
>>> KdcAccessibility: reset
Looking for keys for: HTTP/[email protected]
Using builtin default etypes for default_tkt_enctypes
default etypes for default_tkt_enctypes: 18 17 16 23.
Exception: krb_error 0 Do not have keys of types listed in default_tkt_enctypes available; only have keys of following type:  No error
KrbException: Do not have keys of types listed in default_tkt_enctypes available; only have keys of following type:
        at sun.security.krb5.internal.crypto.EType.getDefaults(EType.java:280)
        at sun.security.krb5.KrbAsReqBuilder.build(KrbAsReqBuilder.java:261)
        at sun.security.krb5.KrbAsReqBuilder.send(KrbAsReqBuilder.java:315)
        at sun.security.krb5.KrbAsReqBuilder.action(KrbAsReqBuilder.java:361)
        at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.java:219)
        at sun.security.krb5.internal.tools.Kinit.main(Kinit.java:113)

Почему приведенные выше команды работают после комментирования этих строк в файле C:\Windows\krb5.ini? И почему команда kinit в режиме отладки выводит указанное выше исключение?


person Shiva    schedule 24.03.2017    source источник
comment
Я вижу тип: не должен ли aes256-cts-hmac-shal-96 быть aes256-cts-hmac-sha1-96?   -  person FlyingSheep    schedule 26.02.2020


Ответы (3)


Я видел это раньше. Попробуй это. Скопируйте keytab в каталог C:\Program Files\Java\jdk1.8.0_121\bin и повторите попытку с помощью более простой команды, показанной ниже, из этого каталога. Вам не нужно добавлять область Kerberos к имени участника-службы, так как область уже определена в krb5.conf, поэтому я удалил ее.

kinit -k -t tomcat_ad.keytab HTTP/dev26.devdevelopment.com

Если это по-прежнему не работает, убедитесь, что у вас действительно есть jar-файлы JCE неограниченной прочности в каталоге \lib\security. Хотя вы сказали, что сделали это, обновление Java JRE может перезаписать их.

РЕДАКТИРОВАТЬ: на вкладке Учетная запись учетной записи пользователя AD devtcadmin установите флажок "Эта учетная запись поддерживает 256-битное шифрование Kerberos AES< /em>" проверяется.

Если это все еще не работает, на компьютере с Windows 7 в C:\Windows\krb5.conf закомментируйте четыре строки ниже, как показано. Они не требуются, так как Kerberos в любом случае будет использовать максимально возможные типы шифрования, а в Windows 7/2008 и более поздних версиях TCP используется по умолчанию, поэтому вам не нужно устанавливать предел предпочтения UDP.

#default_tkt_enctypes=aes256-cts-hmac-shal-96
#default_tgs_enctypes=aes256-cts-hmac-shal-96
#permitted_enctypes=aes256-cts-hmac-shal-96
#udp_preference_limit=1

Взгляните на мою статью TechNet для получения дополнительной информации по этому вопросу: Вкладки ключей Kerberos — объяснение

person T-Heron    schedule 24.03.2017
comment
Спасибо, 4 за ответ @T-Heron. Попробовал ваше предложение, но все равно получил то же исключение. Я также проверил, используются ли банки JCE, выполнив следующий код: - person Shiva; 25.03.2017
comment
Мне понравилось, как вы проверили, использовались ли банки JCE с этим фрагментом кода. Тем не менее, я только что добавил правку в ответ, которая, надеюсь, должна решить проблему. - person T-Heron; 25.03.2017
comment
) С самого начала флажок Эта учетная запись поддерживает 256-битное шифрование Kerberos AES был отмечен на вкладке Учетная запись учетной записи пользователя AD devtcadmin, т. е. как только я создал < b>tomcat_ad.keytab на машине AD. Прислушиваясь к вашему второму предложению, я закомментировал строки в файле C:\Windows\krb5.ini (на компьютере с Windows 7), как вы указали, и вуаля, некоторые из kinit команд работали без каких-либо исключение. Но команда kinit в режиме отладки выдала новое исключение. Я добавил EDIT 1 с более подробной информацией в приведенном выше запросе. - person Shiva; 25.03.2017
comment
На самом деле это не исключение — ваш вывод показывает, что он работает сейчас, а вывод отладки, который вы видите, в основном говорит о том, что у него нет ключей для других типов шифрования b/c в вашей команде создания ktpass, которую вы выбрали для использования только типа шифрования AES256. -SHA1 --› /crypto AES256-SHA1. Ваш вывод ясно показывает, что вы успешно получаете билет Kerberos. Вы можете идти. - person T-Heron; 25.03.2017
comment
Терон, можете ли вы пролить свет на то, почему команда kinit сработала после комментирования (вышеупомянутых) строк в файле krb5.ini? А что касается команды kinit в режиме отладки, в ее журнале указано Using builtin default etypes for default_tkt_enctypes default etypes for default_tkt_enctypes: 18 17 16 23. за несколько строк непосредственно перед псевдоисключением (как вы сказали), а AES256-SHA1 имеет тип 18, который установлен в команде ktpass. Кроме того, в конечном итоге команда не выводит ожидаемый New ticket is stored in cache file C:\Users\devtcadmin\krb5cc_devtcadmin в конце. Есть идеи, почему? - person Shiva; 26.03.2017
comment
Я заинтересован в воспроизведении этого, чтобы дать вам более определенный ответ. Хотя на пару дней уйдет. У меня большой опыт создания таблиц клавиш и устранения неполадок, когда они не работают, но я никогда раньше не анализировал это на уровне отладки. Вызванное псевдоисключение будет иметь какое-то отношение к тому факту, что типы шифрования 17, 16 и 23 не указаны в таблице ключей, тогда как только 18 (AES256-SHA1) есть. - person T-Heron; 26.03.2017
comment
Я пошел по этому пути, прежде чем отвечать на новые вопросы в разделе «Комментарии» и даже не получать никаких кредитов за ответы. Мне придется решить, собираюсь ли я тратить свое время и исследовательский капитал на ответ на этот b/c, хотя я слышал об этом, я не знаю этого твердо с головы до ног. - person T-Heron; 27.03.2017
comment
Получил ваше беспокойство. НП. Спасибо Терон. Как вам удобно. - person Shiva; 27.03.2017
comment
Добавил два дополнительных вопроса, которые вы подняли, в мой список проектов: прикрепите отладку к команде kinit и ответьте более определенно о псевдо-исключении и о tgtsessionkey из реестра. - person T-Heron; 28.03.2017

Я видел аналогичную проблему при попытке использовать поддержку Kerberos JDK из Windows Server 2012R2 в качестве клиента с сервером Linux, который все еще использовал «устаревшую» таблицу ключей. Ошибка, которую я видел, была:

KrbException: no supported default etypes for default_tkt_enctypes

Чтобы исправить эту проблему совместимости, я посмотрел исходный код OpenJDK и нашел параметр в EType.java под названием allow_weak_crypto:

OpenJDK9 EType.java

Добавление этого параметра в мой krb5.conf решило проблему для меня:

[libdefaults]
       allow_weak_crypto = true
person Gerhard Poul    schedule 22.10.2017
comment
Хорошая подробность об этом. По моему опыту, имейте в виду, что слабая криптография обычно помечается аудитом безопасности. - person T-Heron; 16.12.2017
comment
@T-Heron определенно, но имя директивы allow_weak_crypto выбрано правильно, поэтому его должно быть легко обнаружить, и в случае аудита безопасности я надеюсь, что он сначала будет помечен для серверной стороны, что означает, что мы могли бы просто удалить тогда директива на стороне клиента. - person Gerhard Poul; 18.12.2017

Это старый пост, но похоже, что одна из проблем заключается в использовании «l» вместо «1» в типах шифрования, то есть вместо aes256-cts-hmac-shal-96 должен быть aes256-cts-hmac-sha1 -96

person Geoff    schedule 10.11.2020