Kerberos AES-256 Keytab失效求助：JBoss应用迁移AES遇阻

你遇到的这个问题我之前在团队迁移RC4到AES的时候也碰过，SLES12和Win2016 AD的组合确实容易在细节上踩坑，结合你的情况，我整理几个核心排查点：

• 验证AES Keytab的有效性
  首先用klist -kte /path/to/your/keytab查看keytab条目，确认存在aes256-cts-hmac-sha1-96类型的条目，且对应的principal（比如HTTP/your-jboss-host@YOUR-REALM）完全匹配AD中注册的SPN，注意realm必须是大写。
  另外，生成keytab时的ktpass命令要确保指定了正确的加密类型，比如：

  ktpass /princ HTTP/jboss.example.com@EXAMPLE.COM /mapuser jboss-svc-account@EXAMPLE.COM /pass * /out jboss.keytab /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /mapop set
  

  要是生成时没指定/crypto AES256-SHA1，keytab里还是会用RC4，这是很多人犯的错。

• 检查krb5.conf的加密类型优先级
  确保[libdefaults]里把AES加密类型放在最前面，避免Kerberos还是优先尝试RC4，配置示例：

  [libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_realm = false
    dns_lookup_kdc = true
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac
  

  同时确认[realms]里的KDC指向Win2016 AD的正确地址，realm名称大写。

• 启用AD服务账户的AES加密权限
  这是最容易被忽略的一步：打开AD用户和计算机，找到你的JBoss服务账户，右键「属性」→「账户」，勾选「为此账户使用Kerberos AES 256位加密」（如果需要128位也可以一起勾）。如果没开这个，AD会拒绝AES类型的认证请求。

• 用kinit带 verbose 参数排查具体错误
  执行kinit -V -k -t /path/to/keytab HTTP/your-jboss-host@EXAMPLE.COM，看详细报错信息：

  • 如果是Preauthentication failed：大概率是AD账户的预认证没开启（同样在账户属性里勾选「需要 Kerberos 预认证」），或者keytab的密钥和AD账户的密钥不一致（重新生成keytab试试）。
  • 如果是Encryption type not permitted：要么是krb5.conf没配置AES类型，要么是AD账户没开AES权限。

• JBoss配置和JDK兼容性检查
  确认JBoss的JAAS配置（比如login-config.xml）里的Kerberos模块没有强制指定RC4，且keytab路径、principal正确，示例配置：

  <application-policy name="SPNEGO">
      <authentication>
          <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">
              <module-option name="useKeyTab">true</module-option>
              <module-option name="keyTab">/opt/jboss/standalone/configuration/jboss.keytab</module-option>
              <module-option name="principal">HTTP/jboss.example.com@EXAMPLE.COM</module-option>
              <module-option name="storeKey">true</module-option>
              <module-option name="useTicketCache">false</module-option>
              <module-option name="isInitiator">false</module-option>
          </login-module>
      </authentication>
  </application-policy>
  

  另外，SLES12上的JDK如果是Oracle JDK 8，需要安装无限强度加密政策文件（OpenJDK 8u161及以后默认支持AES256），否则会出现加密类型不支持的错误。

• 确认时间同步正常
  Kerberos对时间差非常敏感，SLES服务器和AD的时间差不能超过5分钟。用timedatectl status查看本地时间，和AD服务器时间对比，确保同步正常。

如果以上步骤都排查完还是有问题，建议把kinit -V的完整报错日志、krb5.conf的核心部分以及keytab的klist输出贴出来，这样能更精准定位问题。

内容的提问来源于stack exchange，提问作者Spezieh