Java 17 允许 RC4 HMAC，同时在 krb5.conf 中将allow_weak_crypto 保留为 false

Question

SSO 已在我们的 Spring 应用程序中停止工作。自从我们升级到 Java 17 并升级了 Spring 库以来。 我在身份验证过程中收到以下错误，该错误与 Java 17 禁用 RC4 的事实有关。

仅当我将allow_weak_crypto 设置为“true”时，SSO 才能正常工作，我正在寻找自定义设置以使SSO 正常工作，而无需将allow_weak_crypto 设置为“true”。

我在下面尝试过，但没有成功，你有什么建议吗？.

Caused by: sun.security.krb5.KrbException: Encryption type RC4 with HMAC is not supported/enabled
        at java.security.jgss/sun.security.krb5.EncryptionKey.findKey(EncryptionKey.java:544) ~[java.security.jgss:na]
        at java.security.jgss/sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:273) ~[java.security.jgss:na]
        at java.security.jgss/sun.security.krb5.KrbApReq.<init>(KrbApReq.java:149) ~[java.security.jgss:na]
        at java.security.jgss/sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:139) ~[java.security.jgss:na]
        at java.security.jgss/sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:837) ~[java.security.jgss:na]



default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4 arcfour-hmac rc4-hmac arcfour-hmac-md5 arcfour-hmac-exp rc4-hmac-exp arcfour-hmac-md5-exp
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4 arcfour-hmac rc4-hmac arcfour-hmac-md5 arcfour-hmac-exp rc4-hmac-exp arcfour-hmac-md5-exp
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4 arcfour-hmac rc4-hmac arcfour-hmac-md5 arcfour-hmac-exp rc4-hmac-exp arcfour-hmac-md5-exp

Answer 1

允许 RC4 HMAC，同时将allow_weak_crypto 保持为 false

不要这样做。这是一个自相矛盾的要求，因为

rc4-hmac

字面意思是“弱加密”。

KrbException：不支持/启用带有 HMAC 的加密类型 RC4

当您收到此消息时，这意味着服务或客户端只有可用的弱密钥，但解决方案不是允许弱密钥 - 解决方案是添加强密钥。

1. 我首先从 krb5.conf remove 与 enctype 相关的设置。我不确定 Java Kerberos 是否需要它们，但 MIT Kerberos 或 Heimdal Kerberos 绝对不需要它们。

2. 然后针对您的服务的密钥表运行

   klist -ket <file>

   以检查您拥有哪些服务密钥。如果列表中没有 AES – 轮换服务帐户的密码，重新发出密钥表，然后让用户运行

   klist purge

   (Windows) 或

   kinit -R

   (Linux) 以刷新他们可能拥有的任何旧票证。

3. 然后，如果您使用的是 AD，请检查该服务的 AD 帐户，以验证其在高级帐户设置下设置了“启用 AES128”和“启用 AES256”复选框。 （这对应于

   msDS-SupportedEncryptionTypes

   的

   28

   。）如果进行了更改，请再次让用户刷新其票证。

4. 最后，如果这没有帮助（或者如果您的服务已经有 AES 密钥），则更改客户端的密码，以便 KDC 为用户帐户存储新密钥。

   （客户端帐户不需要“启用 AES”复选框 - 客户端系统已经告诉 KDC 它支持哪些编码类型；只有服务帐户需要手动配置，因为服务根本不与 KDC 通信。）