authentication - Kerberos - AES-256 Keytab 不起作用

Question

我们的 AD 团队将禁用 RC4-HMAC，因此我必须将 JBoss 应用程序更改为 AES。我将 aes 类型添加到 krb5.conf 并创建了新的密钥表，但这似乎不起作用。除了使用 kinit 的应用程序之外的测试显示相同的结果。

有一个类似的问题，但我们已经启用了它的解决方案。还有另一个人（里克莫里茨）对我的问题没有答案。

服务器：SLES12

广告：Windows 服务器 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

键表

密钥表旧 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)

密钥表新的 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

使用新的 keytab 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

查看 etypes 表明 aes 似乎有效。但我无法弄清楚为什么我会收到 aes-keytabs 的预身份验证错误。

新旧 keytab 由以下 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 进行测试

我结合了 Samson Scharfrichter 和 T.Heron 的技巧，现在我看到了在创建 keytab 时从 ktpass 获得的 SALT 和 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)

启动跟踪

 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

score 2 · Accepted Answer

感谢 T.Heron 和 Samson 的提示。

最后，只需要执行 2 个步骤。

为帐户激活 AES，如T.Herons 文章中所述
使用 ktpass 和 mapuser 将 salt 设置为用作登录的主体。（将显示错误但仍会设置盐）

第二部分很难找到。MapUser 会将 SALT 和 UPN 设置为映射的 SPN！只能有一种 SALT。

您可以使用以下命令在 linux 上查看当前的 salt：

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 ""

score 0 · Accepted Answer

请确保在生成新的 keytab 之前从 Active Directory 帐户中清除与 keytab 相关的 SPN。这是一个鲜为人知的问题。在您的情况下，我将运行以下六个步骤，它应该可以工作：

setspn -D HTTP/myapp.my.domain MyappEU
然后生成密钥表：

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

确保新的 SPN 反映在 Active Directory 帐户的“帐户”选项卡中的“用户登录名”字段中，并选中下方的“此帐户支持 Kerberos AES 256 位加密”复选框：

在 JBOSS 服务器上的standalone.xml 文件中，不要忘记更新那里的 keytab 文件名，然后重新启动 JBOSS 引擎以使更改生效。
最后，您需要JBOSS 服务器上Java_Home\lib\security目录中的无限加密强度 Java JAR 文件，否则您的 keytab 将无法解密 AES256-SHA1 Kerberos 票证。如果您确信问题不在步骤 1-5 中，那么也许就是这个问题。

authentication - Kerberos - AES-256 Keytab 不起作用

2 回答 2

Related

Reference