Kerberos

Question

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

有一个但它的解决方案已经为我们启用。还有另一个人 (Rick Moritz) 没有回答我的问题。

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

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

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

查看 etype 表明 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，结果相同。

感谢您的帮助或想法。

P.S。匿名 MY.DOMAIN 和 myapp

用新编译的krb5 1.16测试

我结合了 Samson Scharfrichter 和 T.Heron 的技巧，现在我看到了在创建密钥表时从 ktpass 获得的 SALT 与从 kinit 的跟踪输出获得的 SALT 之间的区别。但我不知道它来自哪里以及如何改变它。在这种情况下，盐包含 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

Answer 1

请确保在生成新密钥表之前从与密钥表相关的 Active Directory 帐户中清除 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 文件中，不要忘记在那里更新密钥表文件名，然后重新启动 JBOSS 引擎以使更改生效。
最后，您需要 JBOSS 服务器上 Java_Home\lib\security 目录中的 unlimited encryption strength Java JAR files，否则您的 keytab 不会能够 de-crypt AES256-SHA1 Kerberos 票证。如果您确信问题不在步骤 1-5 中，那么可能就是这个问题了。

Answer 2

感谢 T.Heron 和 Samson 的提示。

最后只有两步要做。

按照T.Herons article
使用 ktpass 和 mapuser 将盐设置为用作登录的主体。（将显示错误，但仍会设置盐）

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

您可以使用 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 ""

Kerberos - AES-256 Keytab 不起作用

Kerberos - AES-256 Keytab does not work

authentication

sles

keytab

ktpass