為什麼在安裝 Azure AD Connect 時 VSS 創建失敗的登錄事件（事件 ID 4625）？
我們有一個使用 Windows Server 2016 域控制器的客戶。這是一家小型企業，因此他們的伺服器基礎架構由 Hyper-V 主機和此 DC 組成。DC 託管文件共享和 Azure AD Connect，用於將身份與 Office 365 同步。
我們監控事件 ID 4625 並設置警報門檻值，以幫助我們辨識針對網路的潛在暴力攻擊。
去年 10 月，我們開始收到超出登錄失敗警報門檻值的警報。經調查，我們對問題的描述如下：
每當我們的 VSS (Datto) 備份執行或 AADC 同步時，登錄失敗事件都會自然發生
備份成功，AADC 正常同步，沒有錯誤
有兩個賬號登錄失敗：
- SERVERNAME$（例如 SYSTEM 帳戶）每當備份執行時
- AAD_* 每當 AADC 執行時
事件狀態為 0xC000006D - 使用者名或密碼失敗
事件 SUB STATUS 為 0x0 - 狀態正常
系統登錄失敗可以通過執行輕鬆複製
vssadmin list writers過去幾個月的故障排除清單很長。這不是一個完整的列表：
- 解除安裝 RRAS 和 WID（包括刪除 WID 文件夾以確保在重新安裝角色時正確設置權限）
- 清除 SYSTEM 憑證記憶體（使用 psexec &
rundll32 keymgr.dll,KRShowKeyMgr- 沒有記憶體憑證）- 使用 SQL Server Management Studio 登錄 WID 並驗證數據庫權限（對於 LOCALSERVICE 和 NETWORKSERVICE 帳戶）
- 調整各種系統資料庫項的權限（這確實消除了應用程序事件日誌中不相關的 CAPI2 和 WIDWRITER 錯誤）
- 執行 DCDIAG 並查看應用程序事件日誌並清除任何錯誤和警告（包括 DNS 警告、添加 SPN 和重新註冊 AD DNS 條目，以及執行 DFSR 的 D4 權威恢復以清除來自伺服器遷移的警告）
- 使用 sysinternals ProcessMonitor 進行監控以辨識任何拒絕訪問或其他錯誤（這讓我開始調整文件夾和系統資料庫項的權限，以確保 LOCALSERVICE 和 NETWORKSERVICE（執行 WIDWRITER 和其他 VSS 服務的服務帳戶）都可以訪問）
- 驗證 VSS 服務和編寫器、AADC 等的服務啟動類型和登錄帳戶。
- 停止服務並執行測試（停止 AADC 同步服務可解決所有登錄失敗問題。這就是我將其縮小到 AADC 的方式）
- 解除安裝 AADC
- 在 SQL Express 本地數據庫上執行修復
- 使用我們的 MS 合作夥伴支持契約致電 Microsoft 支持 - 誰說“沒有功能損失，並且您沒有無法登錄的實際使用者，所以我們無法幫助您，註冊高級支持！” （不好意思，SYSTEM不算重要使用者嗎？？？）
- 把我的頭撞在幾堵牆上和許多其他東西上
在所有這些過程中學到的有用的東西
- 解除安裝和重新安裝 AADC 時，
vssadmin list writers在安裝過程中持續執行，錯誤在安裝SQL 組件後立即開始，甚至在安裝程序完成執行之前。- 安裝 SSMS 並登錄數據庫後，我也會收到登錄時使用的 dom 管理員帳戶的登錄失敗事件，儘管我的 SSMS 會話似乎不受影響。
該問題顯然與 AADC 有關，因為我可以停止 AAD 同步服務或解除安裝 AADC，並且所有失敗的登錄事件都會消失。但是解除安裝 AADC 並刪除 AADC 文件夾並清除 AADC 使用者帳戶並清除 AADC 系統資料庫項以嘗試獲得真正的全新安裝沒有任何效果，當我重新安裝 AADC 時錯誤會立即返回。
在這一點上，我束手無策，我不知道還能做什麼，甚至不知道還能去哪裡看。我希望乙太中的某個人比我知道的更多（可能），或者以前經歷過這種情況並找到了解決辦法。
最後一點 - 伺服器的 DNS 名稱長度為 9 個字元，這意味著它與其 NETBIOS 名稱不匹配。我不認為這是原因，但如有必要，我可以重命名伺服器。對於生產中的 DC 和文件伺服器來說，這只是一件令人頭疼的事情。
這個問題最初是在 2019 年 10 月開始出現的。花了將近一年的時間，但我終於找到了一個解決方案，它暗示了一個可能的解釋。
解決方案是配置以下系統資料庫項和值：
- 鍵：HKLM\System\CurrentControlSet\Control\LSA\MSV1.0
- 值類型：多字元串值
- 值名稱：BackConnectionHostNames
- 值：伺服器的所有 DNS 主機名，每個都在單獨的行中
這解決了每當 VSS 針對 SQL 數據庫執行時登錄失敗的問題。
這是 Windows Server 2003 中引入的稱為Loopback Check Functionality的安全功能的一部分。
根據我所讀到的有關 Loopback Check Functionality 的工作原理，我相信發生的事情是，每當 VSS 登錄到 SQL 以執行備份時，它都會以 SYSTEM 身份登錄。LSA 期望 SYSTEM 的登錄來自伺服器的 DNS 名稱，但登錄實際上來自伺服器的 NETBIOS 名稱。由於在這種情況下 DNS 名稱與 NETBIOS 名稱不匹配，因此 LSA 無法通過 Kerberos 身份驗證，並且登錄回退到接受 NETBIOS 名稱的 NTLM。
通過配置
BackConnectionHostNames，我們告訴 LSA 接受來自 NETBIOS 和 DNS 名稱的連接，並且 kerberos 身份驗證成功。我能夠通過使用Sysinternals ProcessMonitor來跟踪錯誤發生時 VSS 所做的一切。我發現 VSS 訪問位於C:\Users\ {AzureADConnect Account} \AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\ADSync的文件夾，在那裡我找到了error.log文件。這些日誌包含以下錯誤：
2020-08-13 13:00:47.43 Logon Error: 17806, Severity: 20, State: 14. 2020-08-13 13:00:47.43 Logon SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed [CLIENT: <named pipe>]這是我需要的突破，因為錯誤資訊將我帶到了幾個位置，例如這個 SE question，它建議完全禁用環回檢查。不想禁用安全功能，我繼續搜尋，直到找到源(1)和(2)，這些源描述瞭如何在不禁用環回檢查功能的情況下通過創建
BackConnectionHostNames我上面概述的系統資料庫項來配置它。