Exchange 2016 和 Sever 2016 DC：未知的 KDC 加密類型
團隊，
交換環境都是2016，沒有混用。父域和子域存在，但每個域和林的功能級別是2012R2。直到最近，所有域控制器都是 2012R2。AD 團隊（與我不同）引入了 Server 2016 域控制器，我認為它引起了問題。以下是症狀：
郵件卡在目標為子域的父域中的伺服器上。隊列上的錯誤是“454 4.7.0 臨時身份驗證錯誤”，事件日誌中的相關事件是事件 ID 2017，來源：MSExchangeTransport，消息是：
“發送連接器內部 SMTP 發送連接器的出站身份驗證失敗，錯誤 KdcUnknownEncryptionType。身份驗證機制是 ExchangeAuth。目標是 SMTPSVC/伺服器 fqdn。”
郵件將毫無問題地從子域流向父域。就像我之前所說的，我認為發生的最重要的變化就是引入了 Server 2016 DC。要臨時修復它，我可以重新啟動消息卡住的伺服器，它會工作一段時間。這看起來確實像是一個 Kerberos 問題。
編輯：我們還設置了 ASA，但我所有的交換伺服器、DC 和此 ASA 之間支持的加密類型都是“28”。
Google搜尋顯示時間同步問題，但我檢查了 Exchange 伺服器和域控制器，一切似乎完全同步。我還檢查了複製執行狀況，似乎沒有任何問題。我還檢查了重複或格式錯誤的 SPN，但沒有找到任何東西。關於 SPN，我還有更多可以研究的地方嗎？就像他們請求/使用什麼樣的加密一樣？我對 Kerberos 了解不多。
編輯：作為另一個說明，使用 GPO，我確實從目標伺服器中刪除了 RC4-HMAC。結果，該
klist tickets命令確實顯示了正確的“AES …”，但後來我的powershell被破壞了……“可能的原因”是：
- “使用者或密碼錯誤”
- “未指定身份驗證方法和使用者名時使用的 Kerberos”
- “Kerberos 接受域使用者名，但不接受本地使用者名。”
- “遠端電腦名稱和埠的 SPN 不存在”
- “客戶端和遠端電腦在不同的域中，沒有信任。”
然後它建議嘗試在 WinRM TrustedHosts 列表中添加目標電腦。
聽起來 RC4 是 2012 DC 上允許的 Kerberos 加密類型，而您的 AD 團隊引入了禁用 RC4 的 2016 DC。我這樣說是有信心的，因為它是 Server 2016 上推薦的安全設置。目標是從環境中刪除 RC4，但必須首先更新您的關鍵任務應用程序以支持 AES。我的建議是確保允許的 Kerberos 加密類型在所有 DC 上配置相同，然後在所有域控制器上啟用 Kerberos 服務票證成功審核，以查看哪些應用程序仍在嘗試使用 RC4。它將顯示在 EventId 4769 中，加密類型為 0x17。如果您看到這一點，則表明正在使用 RC4。您需要確保所有涉及的使用者帳戶、電腦帳戶、