為什麼 AD 環境中的伺服器允許通過 FQDN 訪問遠端系統資料庫，但拒絕並鎖定通過 IP 地址的帳戶？
我們遇到無法安裝軟體應用程序的情況，因為安裝期間使用的管理員帳戶在先決條件檢查期間被鎖定。經過一番調查，我們找到了原因：先決條件檢查通過RPC呼叫伺服器的IP地址而不是其FQDN來查看其他伺服器的遠端系統資料庫設置，並且由於某種原因導致身份驗證失敗並鎖定帳戶。
我們通過執行以下操作驗證了這一點：
- 使用 regedit 並嘗試使用伺服器的 FQDN 連接到另一個 AD 伺服器的系統資料庫時，它可以毫無問題地連接。
- 當我們使用伺服器的 IP 地址嘗試相同的連接時，它會提示輸入新憑據。
- 所有 AD 憑據都將失敗並最終鎖定正在使用的帳戶，但使用本地管理員帳戶沒有問題。
我們也在環境中的其他伺服器上執行了此測試，但它們在通過 IP 連接和身份驗證方面沒有問題。我們比較了 NIC/DNS/WINS 設置，但沒有顯著差異。我們正在交叉檢查 GPO 設置，但我們不希望找到任何東西。
我們顯然可以只使用本地管理員帳戶，但我們想了解為什麼使用 IP 地址而不是 FQDN 的 RPC 呼叫會導致 AD 身份驗證失敗並鎖定 AD 帳戶。有任何想法嗎？
如果它鎖定帳戶，您肯定有密碼問題。否則可能是因為不會使用 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