我遇到了一个问题，我希望你们中的一些人遇到了同样的问题并解决了它。
我在特定域上有两个帐户（假设帐户 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，因为帐户 B 在 RC4_HMAC_MD5 处于活动状态时正在使用 Kerberos。
有人知道如何寻找解决方案吗？我该从哪里开始？
答案1
更改帐户 B 的密码。这将为该帐户派生新的 Kerberos 密钥，并且如果更改是在非旧 DC 上进行的，则会导致 AES 密钥被存储（与其他密钥一起）。
然后注销并重新登录，尝试访问 Web 应用程序，并用它klist来检查您是否获得了该服务的票证，该票证使用 AES 作为服务密钥和会话密钥。
听起来帐户 B 已经完成了最后一次密码更改非常很久以前，您的 KDC 仅支持 RC4，而不支持任何更新版本。帐户的 Kerberos 密钥直接来自其密码 - 例如，RC4 密钥实际上是 NT MD4 哈希，而 AES 密钥是 PBKDF2 哈希 - 这意味着，Windows 无法“升级”它们，因为它不知道原始密码。
因此，要摆脱 RC4，就需要更改“krbtgt”密码、更改所有用户帐户的密码，甚至更改所有服务帐户的密码（并为使用密钥表的服务重新发布新的密钥表），以便所有帐户都可以使用 AES 密钥。
我快速查看了 AD 服务器上的帐户选项，但两个帐户的复选框“此帐户支持 Kerberos AES 128 位加密”均未选中。
此选项仅在帐户用作服务时才有意义（即另一个帐户正在请求属于此帐户的 SPN 的票证），因为 KDC 需要知道实际服务应用程序能够接收哪些票证。（KDC 不与服务通信，因此没有其他方法可以知道服务是否可以理解 AES 票证。）
当帐户被用作客户端时，该选项无关紧要，因为客户端系统会直接告诉 KDC 它能够使用哪些加密类型（作为 AS-REQ 的一部分）。当然，KDC 已经知道它为该用户存储了哪些密钥。
因此，应该检查与 Web 应用程序相对应的服务帐户（如果有），但普通用户帐户通常不需要。