Kerberos - AES-256 Keytab不起作用

时间：2018-03-14 15:52:53

标签： authentication kerberos sles keytab ktpass

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

有一个similar issue，但其解决方案已经为我们启用了。还有另一个人（里克莫里茨）没有回答我的问题。

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

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

旧的和新的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的提示，现在我看到了在创建keytab时从ktpass获得的SALT与kinit的trace-output之间的区别。但我不知道它来自何处以及如何改变它。在这种情况下，盐包含一个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 trace 

 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

2 个答案:

答案 0 :(得分：1)

感谢T.Heron和Samson的提示。

最后只有两个步骤。

  1. 按照T.Herons article
    2. 中的说明为帐户激活AES
  2. 使用ktpass和mapuser将salt设置为用作登录的主体。 （将显示错误，但仍将设置盐）

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

    您可以使用以下命令查看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 ""

答案 1 :(得分：0)

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

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

  2. 然后生成密钥表：

    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帐户中：

    4. setspn -L MyappEU

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

      2. Account tab

      1. 在JBOSS服务器上的standalone.xml文件中，不要忘记更新密钥表文件名，然后重新启动JBOSS引擎以使更改生效。
      2. 最后，您需要JBOSS服务器上 Java_Home \ lib \ security 目录中的unlimited encryption strength Java JAR files，否则您的keytab将无法解密AES256-SHA1 Kerberos门票。如果您确信问题不在步骤1-5中，那么可能就是这个问题。
相关问题
最新问题