团队，
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 新鲜度扩展。也许你也可以检查这一点。