我有一个问题,我希望你们中的一些人偶然发现了同样的问题并解决了它。
我在特定域上有两个帐户(假设帐户 A 和帐户 B)。当我启用 RC4_HMAC_MD5 加密类型时,两个帐户都可以使用 kerberos 与特定网站进行通信(在同一域、同一端点、Windows Server 2012 R2 上)。它们通过同一台计算机 (Windows 10) 与服务器进行通信。当我禁用 RC4_HMAC_MD5 时,只有帐户 A 可以与 kerberos 通信,帐户 B 每次都会回退到 NTLM。
我快速查看了 AD 服务器上的帐户选项,但两个帐户都未选中“此帐户支持 Kerberos AES 128 位加密”复选框。
他们是不同组的成员,但我认为这不会阻止帐户 B 使用 Kerberos,因为当 RC4_HMAC_MD5 处于活动状态时帐户 B 正在使用 Kerberos。
有人对寻找解决方案的方式有想法吗?我可以从哪里开始?
更改帐户 B 的密码。这将为该帐户派生新的 Kerberos 密钥,如果更改是在非旧 DC 上完成的,则将导致 AES 密钥被存储(与其余密钥一起)。
然后注销并再次登录,尝试访问 Web 应用程序,并用于
klist
检查您是否获得了该服务的票证,该票证使用 AES 作为服务密钥和会话密钥。听起来帐户 B 上次密码更改是很久以前完成的,当时您的 KDC 仅支持 RC4,但不支持更新的版本。帐户的 Kerberos 密钥直接从其密码派生 - 例如,RC4 密钥实际上是 NT MD4 哈希值,而 AES 密钥是 PBKDF2 哈希值 - 这意味着 Windows 不可能“升级”它们,因为它不知道原始密码。
因此,摆脱 RC4 需要更改“krbtgt”密码,更改所有用户帐户的密码,甚至更改所有服务帐户的密码(并为那些使用密钥表的服务重新颁发新的密钥表),以便所有服务帐户都具有可用 AES 密钥。
此选项仅在帐户用作服务时相关(即另一个帐户正在请求属于该帐户的 SPN 的票证),因为 KDC 需要知道实际服务应用程序能够接收哪些票证。(KDC 不与服务通信,因此它没有其他方法可以知道服务是否可以理解 AES 票证。)
当帐户用作客户端时,该选项无关紧要,因为客户端系统直接告诉 KDC 它能够使用哪些加密类型(作为 AS-REQ 的一部分)。当然,KDC 已经知道它为该用户存储了哪些密钥。
因此,如果有的话,应该检查Web应用程序对应的服务帐户,但普通用户帐户通常不需要。