![Exchange 2016 和 Sever 2016 DC:未知的 KDC 加密类型](https://linux22.com/image/731451/Exchange%202016%20%E5%92%8C%20Sever%202016%20DC%EF%BC%9A%E6%9C%AA%E7%9F%A5%E7%9A%84%20KDC%20%E5%8A%A0%E5%AF%86%E7%B1%BB%E5%9E%8B.png)
团队,
Exchange 环境全部为 2016,没有混合。存在父域和子域,但每个域和林的功能级别为 2012R2。直到最近,所有域控制器都是 2012R2。AD 团队(与我不同)引入了 Server 2016 域控制器,我认为这造成了问题。以下是症状:
邮件滞留在父域的服务器上,而目的地是子域。队列中的错误是“454 4.7.0 临时身份验证错误”,事件日志中的相关事件是事件 ID 2017,来源:MSExchangeTransport,消息是:
“发送连接器组织内 SMTP 发送连接器的出站身份验证失败,错误为 KdcUnknownEncryptionType。身份验证机制为 ExchangeAuth。目标是 SMTPSVC/服务器 fqdn。”
邮件将从子域流向父域,没有任何问题。就像我之前说的,我认为发生的最重大变化就是引入了 Server 2016 DC。为了暂时解决这个问题,我可以重新启动消息卡住的服务器,这样它就可以工作一段时间。这真的看起来像是一个 Kerberos 问题。
编辑:我们也设置了 ASA,但我的所有 Exchange 服务器、DC 和此 ASA 之间支持的加密类型都是“28”。
Google 搜索显示时间同步问题,但我检查了 Exchange 服务器和域控制器,一切似乎都完全同步。我还检查了复制运行状况,似乎没有任何问题。我还检查了重复或格式错误的 SPN,但没有发现任何问题。但是,我还能了解有关 SPN 的更多信息吗?比如他们请求/使用哪种加密之类的?我对 Kerberos 了解不多。
编辑:另外需要注意的是,使用 GPO,我确实从目标服务器中删除了 RC4-HMAC。结果,命令确实klist tickets
显示了正确的“AES...”,但随后我的 powershell 坏了...“可能的原因”是:
- “用户或密码错误”
- “未指定身份验证方法和用户名时使用 Kerberos”
- “Kerberos 接受域用户名,但不接受本地用户名。”
- “远程计算机名称和端口的 SPN 不存在”
- “客户端和远程计算机位于不同的域中,并且不存在信任。”
然后它建议尝试在 WinRM TrustedHosts 列表中添加目标计算机。
答案1
听起来 RC4 是 2012 DC 上允许的 Kerberos 加密类型,而您的 AD 团队引入了禁用 RC4 的 2016 DC。我很有信心地说,因为这是 Server 2016 上推荐的安全设置。目标是从环境中删除 RC4,但首先要更新您的关键任务应用程序以支持 AES。我的建议是确保所有 DC 上允许的 Kerberos 加密类型配置相同,然后在所有域控制器上启用 Kerberos 服务票证成功审核,以查看哪些应用程序仍在尝试使用 RC4。它将显示在 EventId 4769 中,加密类型为 0x17。如果您看到此消息,则表示正在使用 RC4。您需要确保每台服务器(包括 DC)上所有相关的用户帐户、计算机帐户和 Kerberos 策略都已正确配置,以使 AES 正常工作。
答案2
我认为您可以先检查 SPN,您可以运行“ SetSPN -L <ExchangeServerName>
”命令来检查 SPN 配置。它应该包含:
SMTP/<ExchangeServerName>
SMTP/<ExchangeServerName>.example.com
SMTPSVC/<ExchangeServerName>
SMTPSVC/<ExchangeServerName>.example.com
如果遗漏了,可以运行“ setspn -a <data>
”来添加。
然后在客户端的CMD中运行“klist tickets”查看ticket类型,一般是“AES-256-CTS-xxx”。
以下是有关票证类型的相关博客: https://blogs.msdn.microsoft.com/openspecification/2011/05/30/windows-configurations-for-kerberos-supported-encryption-type/
此外,根据我的研究,从 Windows Server 2016 开始,KDC 可以支持 PKInit 新鲜度扩展。也许你也可以检查这一点。