logo标签列表

JDK 17（Java 17）+Kerberos身份验证失败。

spring-bootauthenticationkerberos
8

遇到了一个非常烦人的问题，涉及JDK 17升级和新支持的Kerberos认证。

  1. 问题：JDK 17 Kerberos不再支持rc4-hmac，因为它被标记为不安全。 INFO: Kerberos 在Kerberos中弃用3DES和RC4 默认情况下已禁用3DES和RC4 Kerberos加密类型。 3DES和RC4都是弱加密算法，不应使用。在RFC 8429中，Kerberos 3DES和RC4加密类型已正式弃用。

  2. 需要做的事情：

  • 生成具有新支持的加密类型的新keytab文件：
  • aes128-cts-hmac-sha1-96或aes128-cts-hmac-sha256-128
  • 更新AD（Active Directory）中的服务用户（2个复选框）以支持新的加密类型。

无法解决的错误：

Caused by: sun.security.krb5.KrbException: KDC has no support for encryption type (14)
at java.security.jgss/sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:69)
at java.security.jgss/sun.security.krb5.KrbTgsReq.getReply(KrbTgsReq.java:224)
at java.security.jgss/sun.security.krb5.KrbTgsReq.sendAndGetCreds(KrbTgsReq.java:235)
at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCredsSingle(CredentialsUtil.java:482)
at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:34
at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.serviceCreds(CredentialsUtil.java:31
at java.security.jgss/sun.security.krb5.internal.CredentialsUtil.acquireServiceCreds(CredentialsUtil.java:169)
at java.security.jgss/sun.security.krb5.Credentials.acquireServiceCreds(Credentials.java:493)
at java.security.jgss/sun.security.jgss.krb5.Krb5Context.initSecContext(Krb5Context.java:700)
... 39 common frames omitted
Caused by: sun.security.krb5.Asn1Exception: Identifier doesn't match expected value (906)
at java.security.jgss/sun.security.krb5.internal.KDCRep.init(KDCRep.java:140)
at java.security.jgss/sun.security.krb5.internal.TGSRep.init(TGSRep.java:65)
at java.security.jgss/sun.security.krb5.internal.TGSRep.<init>(TGSRep.java:60)
at java.security.jgss/sun.security.krb5.KrbTgsRep.<init>(KrbTgsRep.java:54)
... 47 common frames omitted

我们有所遗漏吗？

所有关于管道的内容都已更新，支持新的加密类型+keytab.conf文件。

谢谢！

“keytab.conf文件” >> 你的意思是什么？是指Keytab文件，还是krb5.conf文件，还是两者都包括？ - Samson Scharfrichter
2
引用我五年前的评论：要真正理解Java如何处理您的Kerberos/JAAS配置，您应该设置“-Djava.security.debug=gssloginconfig,configfile,configparser,logincontext”。 - Samson Scharfrichter
关于文件，是的，keytab文件已经使用新的加密类型生成，并更新了krb5.conf以反映这些更改。是的，我们已经这样做并在Kerberos级别上启用了调试-Dsun.security.krb5.debug=true，但仍然出现相同的错误，没有真正指出是什么问题，我们放弃了并开了一个官方提供商的支持票据。正在等待答复。 - Daniela Todorova
2
@DanielaTodorova 你成功了吗？我也遇到了同样的错误。 - Ankit Gautam
嗨@AnkitGautam！微软似乎对es128-cts-hmac-sha1-96或aes128-cts-hmac-sha256-128两种加密方式都有官方问题。所以我们做了以下几点：1.将应用程序升级到JDK 17；2.像以前一样保留rc4-hmac；3.保留旧的keytab文件；4.将allow_weak_encryption设置为true：docs.centrify.com/Content/config-gp/…目前所有工作都是这样完成的，说实话，直到微软修复他们的映射，我们都会保持这种状态。 - Daniela Todorova
@DanielaTodorova，微软找到了什么吗？ - Simon Müller
4个回答
4
我遇到了与此处描述的完全相同的问题。查看 Kerberos 认证流程并使用此Microsoft文章，我们发现问题出在 SQL 服务器（我们正在联系的服务）的主要服务帐户中。该主要服务帐户未设置属性“msDS-SupportedEncryptionTypes”，因此默认为 RC4 加密类型。
解决方法是为我们启用了主要服务帐户的“这个帐户支持 Kerberos AES 128 位加密”和“这个帐户支持 Kerberos AES 256 位加密”。在某些情况下，还可能需要重置此帐户的密码。
正如 Microsoft 文章中所述，默认情况下用户帐户没有设置“msDS-SupportedEncryptionTypes”的值。
4

您可以通过将krb5.conf文件中的“allow_weak_crypto”属性设置为“true”来保留现有的rc4-hmac行为。

是的，我已经在原问题下面的评论中发布了这个。这只是一个解决方法，所以我很快会发布解决方案。 - Daniela Todorova
2
解决方案是使用gMSA账户进行MSSQL服务器连接。
JDK 17应用程序-> JDK17 aes128-cts-hmac-sha256-128 keytab-> 使用用户ID调用MSSQL服务器-> 通过gMSA账户解析。
因此，MSSQL部分最初不接受新的加密类型。
0
尝试更新 krb5.ini 文件的内容：
default_tgs_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
default_tkt_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接