SQL Server 2008R2 別名不起作用
我這裡有一個有趣的情況。我們基本上是在嘗試將一些 SQL Server 基礎架構遷移到新硬體，其中一個機器（單實例、2 節點集群）正在執行 2008R2。其他的是 2012 年和 2014 年，但沒有出現這個問題。
有一個應用程序連接到名為“OLD-SQL”的伺服器；假設IP是11.22.33.44。這是執行預設實例、SQL 2008R2 和 Windows Server 2008R2 的舊 SQL 框的名稱。目前無法更改應用程序的連接設置/config/string/whatever。
設置為替換該 SQL 框的新 SQL 框命名為“NEW-SQL”；假設它的 IP 是 11.22.33.55。還執行 SQL 2008R2（相同的 SQL 版本）。作業系統是 Windows Server 2012 R2（較新的作業系統）。這兩個盒子實際上都是集群實例，每個都有 2 個節點（老式的故障轉移集群，沒什麼花哨的）。
因此，為了幫助遷移，目前，出於測試/QA 目的，我們已經完成了以下操作： 1. 在客戶端 QA 機器上設置 Hosts 文件，將名稱“OLD-SQL”重定向到 11.22.33.55（新伺服器）。2. 在 NEW-SQL 伺服器上創建了一個 SQL Server Alias（使用 SQL Config Mgr.），命名為“OLD-SQL”，指向自身，埠 1433，協議 TCP/IP。
為了測試它，我嘗試通過 SSMS 連接；我輸入“OLD-SQL”作為要連接的伺服器名稱。它因臭名昭著的“SSPI 上下文”錯誤（https://support.microsoft.com/en-us/kb/811889）而失敗。正在測試的應用程序也會發生同樣的事情。來自 cmd-line 的 Ping 可以很好地解析——它知道“OLD-SQL”會根據 Hosts 文件解析為新的 IP 11.22.33.55。
現在，要真正把扳手扔進東西里了。我回到伺服器 NEW-SQL，並添加另一個別名，相同的參數但名為“OLD-SQL2”。此名稱在域網路中是唯一的。我回到我的盒子，將我的 Hosts 文件更改為從該名稱指向 IP (11.22.33.55)，然後轉到 SSMS 並嘗試再次連接。 這行得通！
我通過執行驗證我在“正確的伺服器”上
SELECT @@SERVERNAME，並且你瞧，它說“NEW-SQL”。但這當然不是我真正想要的別名；我希望能夠為其提供別名“OLD-SQL”，並通過 Hosts 條目和 SQL Alias 將我的應用程序重定向到“NEW-SQL”。那麼我對第一個別名做錯了什麼？只是我不能使用與網路上現有伺服器相同的名稱，2008R2？
SO上的類似文章：https ://stackoverflow.com/questions/6406811/alias-not-working-on-sql-server-2008-r2 （沒有解決問題）
PS：我特別說“使用 2008R2”，因為當我嘗試使用我們的 2012-2014 機器進行相同的設置（主機、SQL 別名）時，它們以第一種方式工作得很好！（即“NEW-SQL2012”框上的別名可以是“OLD-SQL2012”，與現有伺服器相同，連接沒有問題。）
PPS：我確實讀到過這些別名更像是客戶端的東西，但這就是我使用 Hosts 文件技巧的原因。當我們準備好進行“真正的”遷移時，我們將使用 DNS 和我不知道的其他技巧（這是 SysEng 的域）將客戶端（應用程序/電腦）重定向到新伺服器，但他們現在說，對於測試，Hosts 文件是一個很好的替代品。
更新：除了 SQL Server 版本之外，“工作”設置和“非工作”設置之間的主要區別在於，當我使用“原始”設置進行連接時，舊的 2008R2 實例“SQL-OLD”（沒有別名或 hosts-file-redir。），使用Kerberos身份驗證。當我通過唯一別名或重定向（例如“OLD-SQL2”）連接時，它會註冊為 NTLM。在所有其他工作連接方法中，它也是 NTLM。Kerberos 到底在對我做什麼？？
總結我們在聊天中發現的內容。
通過網路連接時，如果 Windows Server 使用服務主體名稱 (SPN) 在 Active Directory (AD) 中註冊，則嘗試使用集成身份驗證連接的客戶端將從 AD 獲取與伺服器名稱匹配的 AD 對象的 Kerberos 令牌附加到身份驗證。當正在連接的伺服器沒有 SPN 或正在使用 SQL 身份驗證連接時，將不會使用 Kerberos。
在這種情況下，因為“OLD-SQL”仍然在 AD 中註冊並且有一個 SPN 註冊欺騙，當使用集成/Windows 身份驗證時，本地主機文件中的 DNS 將不起作用，因為沒有調整返回哪個令牌/從 AD 使用。似乎沒有辦法讓客戶端知道將 Kerberos 令牌用於“NEW-SQL”，而原始“OLD-SQL”伺服器仍在服務中，除了從 AD 中刪除“OLD-SQL”SPN強制身份驗證回退到 NTLM。欺騙 DNS 適用於不是在 AD 中註冊的實際電腦名稱或沒有註冊 SPN 的別名，因為 AD 不會為它們返回令牌，因此身份驗證回退到使用 NTLM。
參考