Java 17更新 - 找不到与HMAC解密AP -REQ -RC4的合适类型的关键
我有一个使用kerberos的高产Java应用程序。
在将Java从版本16更新为17之后，我遇到了以下错误：
找不到使用HMAC
Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP-REQ - RC4 with HMAC)
at java.security.jgss/sun.security.jgss.krb5.Krb5Context.acceptSecContext(Unknown Source)
at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)
at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)
at java.security.jgss/sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(Unknown Source)
at java.security.jgss/sun.security.jgss.spnego.SpNegoContext.acceptSecContext(Unknown Source)
at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)
at java.security.jgss/sun.security.jgss.GSSContextImpl.acceptSecContext(Unknown Source)
at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator.establishContext(SPNEGOAuthenticator.java:169)
at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator$AcceptSecContext.run(SPNEGOAuthenticator.java:132)
at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator$AcceptSecContext.run(SPNEGOAuthenticator.java:122)
... 73 more
Caused by: KrbException: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP-REQ - RC4 with HMAC
at java.security.jgss/sun.security.krb5.KrbApReq.authenticate(Unknown Source)
at java.security.jgss/sun.security.krb5.KrbApReq.<init>(Unknown Source)
at java.security.jgss/sun.security.jgss.krb5.InitSecContextToken.<init>(Unknown Source)
... 83 more
ktpass/crypto的合适类型的关键。用于创建keytab文件。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
错误原因
在进行了一些研究之后，我遇到了以下：
在kerberos中删除3DE和RC4
3DE和RC4 Kerberos加密类型现已被禁用
默认。 3DE和RC4都是弱的加密算法
不使用。 Kerberos 3DE和RC4加密类型是
在RFC 8429中正式弃用。
默认情况下，DES3-HMAC-SHA1和RC4-HMAC加密类型现在为
通过设置
允许_weak_crypto属性在krb5.conf配置中
文件。但是，请注意，这也将重新启用其他弱加密
已经禁用的类型，例如DES-CBC-CRC和DES-CBC-MD5。
或者，设置default_tkt_enctypes，default_tgs_enctypes，
并允许的_enctypes属性到加密类型
允许。
问题： jdk-8139348
问题 加密：
首选解决方案是配置AD/Kerberos以使用AES 128或256位加密。
通常，以下几乎足够了，但是AD或GPO中可能还有其他配置可以阻止AES加密：
为Kerberos配置的Service-USER（用于创建keytab文件）需要以下配置：
之后在运行Java应用程序的机器上运行：
解决方案2-解决方法 - ＆gt;允许弱加密
我快速解决方法（也许您不是广告的管理员或需要等待维护窗口），以下对我有用：
创建或使用现有 krb5.conf 文件，add：
使用：
-djava.security.krb5.conf =％conf_location％/krb5.confError Cause
After a bit of research I came across the following JDK 17 Security Enhancements:
Deprecate 3DES and RC4 in Kerberos
3DES and RC4 Kerberos encryption types have now been disabled by
default. Both 3DES and RC4 are weak encryption algorithms that should
not be used. The Kerberos 3DES and RC4 encryption types are
officially deprecated in RFC 8429.
By default the des3-hmac-sha1 and rc4-hmac encryption types are now
disabled, but can be re-enabled, at your own risk, by setting the
allow_weak_crypto property to true in the krb5.conf configuration
file. However, note that will also re-enable other weak encryption
types that are already disabled such as des-cbc-crc and des-cbc-md5.
Alternatively, set the default_tkt_enctypes, default_tgs_enctypes,
and permitted_enctypes properties to the encryption types that are
allowed.
Issue: JDK-8139348
Solution 1 - use AES 128/256 encryption:
The preferred solution is, to configure the AD/Kerberos to use AES 128 or 256 bit encryption.
Mostly the following seems to be enough, but there can be other configurations in the AD or GPOs that block AES encryption:
The service-user configured for kerberos (used to create the keytab file) needs the following configuration:
Afterwards on the machine running the java application, run:
Solution 2 - workaround -> allow weak encryption
For I quick workaround (maybe you are not the admin of the AD or need to wait for a maintenance window) the following worked for me:
Create or use the existing krb5.conf file, add:
Start the java application using:
-Djava.security.krb5.conf=%CONF_LOCATION%/krb5.conf