我們遇到過這樣的情況：軟體應用程式無法安裝，因為安裝過程中使用的管理員帳戶在先決條件檢查期間被鎖定。經過一番調查，我們找到了原因：先決條件檢查透過對伺服器的IP 位址而不是其FQDN 的RPC 呼叫來查看其他伺服器的遠端註冊表設置，並且由於某種原因，這會導致身份驗證失敗並鎖定帳戶。
我們透過執行以下操作來驗證這一點：
- 當使用 regedit 並嘗試使用伺服器的 FQDN 連接到另一個 AD 伺服器的註冊表時，它可以正常連接。
- 當我們嘗試使用伺服器的 IP 位址進行相同的連線時，它會提示輸入新憑證。
- 所有 AD 憑證都會失敗並最終鎖定正在使用的帳戶，但使用本機管理員帳戶沒有問題。
我們也在環境中的其他伺服器上執行了此測試，但它們在透過 IP 連線和驗證方面沒有任何問題。我們比較了 NIC/DNS/WINS 設置，但沒有顯著差異。我們正在交叉檢查 GPO 設置，但我們預計不會找到任何結果。
顯然我們可以只使用本機管理員帳戶，但我們想了解為什麼使用 IP 位址而不是 FQDN 的 RPC 呼叫會導致 AD 驗證失敗並鎖定 AD 帳戶。有任何想法嗎？
答案1
如果它鎖定了帳戶，那麼您肯定遇到了密碼問題。否則可能是因為 Kerberos 不會被使用且 NTLM 被停用或其他原因。您需要檢查來源伺服器和目標伺服器的安全性日誌，並提供可能與驗證問題相關的任何日誌條目。
你也可以試試這個。然而，當你甚至不知道某些東西不起作用的原因時，改變東西不是很有效，並且可能會破壞其他東西。
從 Windows 10 版本 1507 和 Windows Server 2016 開始，可以將 Kerberos 用戶端設定為支援 SPN 中的 IPv4 和 IPv6 主機名稱。
預設情況下，如果主機名稱是 IP 位址，Windows 將不會嘗試對主機進行 Kerberos 驗證。它將回退到其他啟用的身份驗證協議，例如 NTLM。但是，應用程式有時會被硬編碼為使用 IP 位址，這意味著應用程式將回退到 NTLM 並且不使用 Kerberos。當環境轉向停用 NTLM 時，這可能會導致相容性問題。
為了減少停用 NTLM 的影響，引入了一項新功能，允許管理員使用 IP 位址作為服務主體名稱中的主機名稱。
閱讀更多內容
https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip