使用者“NT AUTHORITYANONYMOUS LOGON”登錄失敗
我有一個執行 Windows Server 2012R2 和 SQL Server 2014 Enterprise 後端的操作伺服器。此伺服器用於通過 SQL 代理作業呼叫的 cmd 文件將新程式碼部署到其他生產伺服器。所有伺服器都在同一個域中。
伺服器 A 執行 Windows Server 2008R2 和 SQL Server 2008R2 後端。此伺服器有一個連結伺服器連接到伺服器 B 上的數據庫，執行與 A 相同的作業系統和 SQL Server 版本。連結伺服器配置有選項@useself=TRUE。
- 所有三台伺服器都使用啟用了委派的服務帳戶。
- 此服務帳戶在所有三個 SQL Server 實例上都具有 sa 特權。
- 所有三台伺服器都使用該帳戶配置了 SPN，並被委派將 Kerberos 用於關聯的 MSSQLSVC 服務。
我可以在每個上執行以下命令並返回“Kerberos”
SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@spid此外，我可以毫無問題地從任何這些伺服器遠端登錄、ping 等到任何其他伺服器 - 一切都已連接。程式碼部署從未出現過問題，並且經常引用連結伺服器並且沒有問題……除了一種情況，我不明白為什麼。
雙跳場景
- 操作伺服器上的 SQL 代理作業由除 SQL 代理服務帳戶之外的任何系統管理員臨時執行，並在操作伺服器上執行 cmd 文件。
- SQL 代理作業被配置為“執行方式”一個 SQL 代理服務帳戶，具有 sa 權限。
- 部署的程式碼來自操作伺服器上的 .sql 文件。
- cmd 文件呼叫 SQLCMD 來針對伺服器 A 執行 .sql 文件中的程式碼。
- .sql 文件中的程式碼引用連結伺服器並失敗並出現錯誤
消息 18456，級別 14，狀態 1，伺服器 ServerB，第 1 行使用者“NT AUTHORITY\ANONYMOUS LOGON”登錄失敗。 .
該錯誤針對連結伺服器 - 伺服器 B。如果我使用 SQLCMD 從操作伺服器對伺服器 A 手動執行此程式碼，它執行良好。如果我以 SQL 代理服務帳戶身份登錄到一個框並執行 SQL 代理作業，它執行良好。只有當 SQL 代理作業由 SQL 代理服務帳戶以外的其他人執行時，我才會收到錯誤消息。
我已經閱讀了很多關於 Kerberos、雙跳等的文章、部落格和 MSDN 文章，告訴我去做已經做過的事情。我錯過了什麼？
附加資訊 我終於能夠回到這個並找到一些附加資訊。根據 Bogdan 的建議，我執行了 Process Explorer 並驗證了第一個躍點的憑據是否如預期來自 SQL 代理服務帳戶，並且正在使用 TCP。唉，這就是我能夠從該工具中獲得的所有有用資訊。
我深入研究了 Window 的應用程序日誌並四處尋找機器上不同實例的登錄資訊，發現甚至沒有使用 Kerberos！相反，正在使用 NTLM。
所以這就是我要走的新路徑——為什麼要使用 NTLM 身份驗證，當 Kerberos 設置好並且埠和實例存在正確的 FQDN SDN 時？我是否需要以某種方式在 cmd 文件或 SQLCMD 呼叫中指定身份驗證類型？還是我有一些我沒有考慮的錯誤配置？
謎底加深 SQLCMD 呼叫通過別名引用了“第一跳”伺服器。我修改了對實際命名實例的 SQLCMD 伺服器引用並重新執行了該作業。有效！我們還為我們的機器和 SQL 實例使用 cNames，所以我嘗試使用它。它也奏效了！為了咧嘴笑和咯咯笑，我重新嘗試了別名……它工作了？？？我去檢查每個這些的 Windows 應用程序日誌，它仍然將身份驗證報告為 NTLM！
在這一點上，我完全感到困惑，不知道如何解釋這種行為來修復我們環境的其餘部分。
終於想通了！
我們使用 SQL 別名和規範名稱引用了許多非常活躍的 SQL Server 和實例。這使我們能夠在不中斷程式碼的情況下執行並行升級和切換機器。出於同樣的原因，SQL 別名都被配置為引用規範名稱。我們註冊的標準 SPN 用於機器名稱。
範例 SQL Server SSxyz\xyzInstance 在埠 12345 上偵聽已註冊 SPN：
- MSSQLSVC/SSxyz.mydomain.com:12345
- MSSQLSVC/SSxyz:12345
- MSSQLSVC/SSxyz:xyzInstance
這些都註冊到該機器上擁有 MSSQLSVC 的服務帳戶，並且為每個帳戶設置了委派以傳遞憑據。
伺服器和實例也有規範名稱 cxyz\xyzInstance。最後，SQL Server 有一個 32 位和 64 位別名 xyzAlias，指向規範名稱 cxyz\xyzInstance。
在從我的本地 pc 到 xyzAlias 到 abcAlias 的雙躍點場景中，Kerberos 身份驗證失敗並回退到 NTLM，因為無法解析別名和 SPN。這就是日誌顯示 NTLM 的原因。
修復方法是添加更多 SPN 以將伺服器的規範名稱註冊為實際名稱。然後將 SQL 服務註冊到另一個 SPN。像這樣：
- setspn -s 主機/cxyz SSxyz
- setspn -s 主機/cxyz.mydomain.com SSxyz
- setspn -s MSSQLSVC/cxyz:12345 sqlserviceaccountname
- setspn -s MSSQLSVC/cxyz:xyzInstance sqlserviceaccountname
註冊後，將為每個 SPN 配置委派。這些顯示為唯一的 SPN，並允許 SQL 別名解析為實際的機器名稱。記錄的雙跳身份驗證是 kerberos，每個人都很高興！除了廣告人……他們將在幾個小時內註冊很多 SPN。