Ich habe hier eine interessante Situation. Grundsätzlich versuchen wir, eine SQL Server-Infrastruktur auf neue Hardware zu migrieren, und in einer der Boxen (Einzelinstanz, Cluster mit zwei Knoten) wird 2008R2 ausgeführt. Die anderen sind 2012 und 2014, aber diese weisen dieses Problem nicht auf.
Es gibt eine App, die eine Verbindung zu einem Server mit dem Namen "OLD-SQL" herstellt. und sagen wir, dass IP 11.22.33.44 ist. Dies ist der Name der älteren SQL-Box, auf der die Standardinstanz SQL 2008R2 und Windows Server 2008R2 ausgeführt werden. Die Verbindungseinstellung / config / string / what der App kann derzeit nicht geändert werden.
Die neue SQL-Box, die diese ersetzen soll, heißt beispielsweise "NEW-SQL". Nehmen wir an, die IP ist 11.22.33.55. Läuft auch SQL 2008R2 (gleicher SQL-Build). Betriebssystem ist Windows Server 2012 R2 (neueres Betriebssystem). Beide Boxen sind tatsächlich Clustered Instances mit jeweils 2 Knoten (altmodisches Failover-Clustering, nichts Besonderes).
Um die Migration vorerst zu Test- / QS-Zwecken zu unterstützen, haben wir Folgendes durchgeführt: 1. Richten Sie die Hosts-Datei auf dem Client-QA-Computer ein, um den Namen "OLD-SQL" auf 11.22.33.55 (neu) umzuleiten Server). 2. Erstellt einen SQL Server-Alias auf dem NEW-SQL-Server (unter Verwendung von SQL Config Mgr.) Mit dem Namen "OLD-SQL", der auf sich selbst zeigt , Port 1433, Protokoll TCP / IP.
Um es zu testen, versuche ich, eine Verbindung über SSMS herzustellen. Ich gebe "OLD-SQL" als Servernamen ein, zu dem eine Verbindung hergestellt werden soll. Es schlägt mit dem berüchtigten Fehler "SSPI-Kontext" fehl ( https://support.microsoft.com/en-us/kb/811889 ). Das gleiche passiert mit der Anwendung, die getestet wird. Ping von cmd-Zeile wird einwandfrei aufgelöst - es ist bekannt, dass "OLD-SQL" basierend auf der Hosts-Datei in die neue IP 11.22.33.55 aufgelöst wird.
Nun , um wirklich einen Schraubenschlüssel in die Dinge zu werfen. Ich gehe zurück auf den Server NEW-SQL und füge einen weiteren Alias hinzu, dieselben Parameter, aber mit dem Namen "OLD-SQL2". Dieser Name ist innerhalb des Domänennetzwerks eindeutig. Ich gehe zurück zu meiner Box, ändere meine Hosts-Datei so, dass sie von diesem Namen auf die IP (11.22.33.55) verweist, gehe zu SSMS und versuche erneut, eine Verbindung herzustellen. DAS FUNKTIONIERT!
Ich überprüfe, ob ich auf dem "richtigen Server" bin, indem ich a mache SELECT @@SERVERNAME, und siehe da, es heißt "NEW-SQL". Aber das ist natürlich nicht der Alias, den ich wirklich will. Ich möchte ihm den Alias "OLD-SQL" geben und meine App über den Hosts-Eintrag und den SQL-Alias auf "NEW-SQL" umleiten lassen.
Was mache ich also falsch mit dem ersten Alias? Ist es nur so, dass ich mit 2008R2 nicht denselben Namen wie ein vorhandener Server im Netzwerk verwenden kann?
Ähnlicher Beitrag auf SO: /programming/6406811/alias-not-working-on-sql-server-2008-r2 (Problem wurde nicht gelöst)
PS: Ich sage speziell "mit 2008R2", denn wenn ich das gleiche Setup (Hosts, SQL-Alias) mit unseren 2012-2014-Boxen versuche, funktionieren sie auf die erste Weise einwandfrei! (Das heißt, der Alias im Feld "NEW-SQL2012" kann "OLD-SQL2012" sein, der mit einem vorhandenen Server identisch ist, und es gibt keine Verbindungsprobleme oder ähnliches.)
PPS: Ich habe gelesen, dass diese Aliase eher clientseitig sind, aber deshalb verwende ich den Hosts-Datei-Trick. Wenn wir uns auf die "echte" Migration vorbereiten, verwenden wir DNS und andere Tricks, die außerhalb meines Wissens liegen (das ist die Domäne von SysEng), um Clients (Apps / Computer) auf die neuen Server umzuleiten Zum Testen ist die Hosts-Datei ein guter Ersatz.
Update : Der Hauptunterschied zwischen den "funktionierenden" und den "nicht funktionierenden" Setups neben den SQL Server-Versionen besteht darin, dass die alte 2008R2-Instanz "SQL-OLD", wenn ich eine Verbindung mit dem "makellosen" Setup herstelle ( Keine Aliase oder Hosts-File-Redir.), verwendet Kerberos- Authentifizierung. Wenn ich eine Verbindung über einen eindeutigen Alias oder eine Umleitung wie "OLD-SQL2" herstelle, wird diese als NTLM registriert. Und in ALLEN ANDEREN funktionierenden Verbindungsmethoden ist es auch NTLM. Was zum Teufel macht Kerberos mit mir?
Antworten:
Fassen wir zusammen, was wir im Chat entdeckt haben.
Wenn beim Herstellen einer Verbindung über das Netzwerk der Windows Server in Active Directory (AD) mit einem Dienstprinzipalnamen (SPN) registriert ist, erhalten Clients, die versuchen, eine Verbindung mit der integrierten Authentifizierung herzustellen, das Kerberos-Token von AD für das AD-Objekt, das dem Servernamen entspricht an die Authentifizierung anhängen. Kerberos wird nicht verwendet, wenn entweder der Server, der verbunden ist, keinen SPN hat oder über die SQL-Authentifizierung verbunden ist.
In diesem Fall funktioniert das DNS in der lokalen Hostdatei bei Verwendung der integrierten / Windows-Authentifizierung nicht, da "OLD-SQL" noch in AD registriert ist und über ein SPN-registriertes Spoofing verfügt, da nicht angepasst wird, welches Token zurückgegeben wird. verwendet von AD. Es scheint keine Möglichkeit zu geben, den Client wissen zu lassen, dass er das Kerberos-Token für "NEW-SQL" verwendet, während der ursprüngliche "OLD-SQL" -Server noch in Betrieb ist, außer den SPN "OLD-SQL" aus AD zu entfernen um zu erzwingen, dass die Authentifizierung auf NTLM zurückgreift. Das Spoofing des DNS funktioniert für Aliase, in denen keine tatsächlichen Computernamen in AD registriert sind oder für die kein SPN registriert ist, da AD kein Token für diese zurückgibt, sodass die Authentifizierung auf die Verwendung von NTLM zurückgreift.
Verweise
Grundlegendes zu Kerberos-Schlüsseln
Registrieren eines SPN
quelle