gugi

Hallo, ich habe auf einem 2 Node AlwaysOn Cluster (SQL Server 2012, Windows Server 2008 R2 Enterprise) mehrere Named Instances laufen. Jede Server-Instanz und jeder SQL Server Agent läuft unter einem eigenen Windows Service User. Wir finden nachdem der syspolicy_purge_history Job gelaufen ist im SQL Server Log aller anderen SQL-Server Instanzen am Server folgende Einträge: Login failed for user 'DOMAIN\AGENT-SERVICE-USER'. Reason: Could not find a login matching the name provided. [CLIENT: <local machine>] Der Job selbst läuft fehlerfrei durch. Für SQL Server 2008 (R2) gibt es auch von Microsoft einen offiziellen Artikel zum Thema. Die vorgeschlagenen Lösungen funktionieren am SQL 2012 aber nicht mehr. http://support.microsoft.com/kb/955726/en-us Ich habe auch schon versucht im Step 3 des Jobs "Erase Phantom System Health Records." das Powershell Kommando so anzupassen, dass definitiv nur die richtige SQL Instanz referenziert wird, doch auch dann finden sich in den Logs der anderen Instanzen wieder die oben genannten Einträge. (Get-Item SQLSERVER:\SQLPolicy\HOSTNAME\INSTANCENAME).EraseSystemHealthPhantomRecords() ... in diversen Schreibweisen mit FQDN, Virtual Instance Name, mit Angabe des Ports,... probiert => keine Lösung. Habe auch den Port der Instanz statisch definiert, die Dienste neu gestartet => keine Lösung Auch das Verändern der Powershell Execution Policy über die Registry, wie im nachfolgenden Artikel vorgeschlagen, bringt nichts. https://social.msdn.microsoft.com/Forums/sqlserver/en-US/59ebcd5a-d252-427d-92f4-340c9cbf2bde/sql-server-2012-syspolicypurgehistory-job-causes-crossinstance-login-failures-w?forum=sqldatabaseengine Hat jemand noch eine Idee, wie das Problem gelöst werden kann? Danke!

Das habe ich so vom Vorgänger übernommen, mir ist schon klar, dass das nicht best practice ist - sollte aber mit dem eigentlichen Thema nichts zu tun haben. Jetzt habe ich alle SPNs mit und ohne Port eingetragen.

Hi, also ich habe 9 Named Instances auf dem Server. Die SPNs habe ich immer für den Netbios Namen und den FQDN gesetzt, jeweils mit Instance Name und Port. Auf die Groß-/Kleinschreibung habe ich aber bisher keine Rücksicht genommen. Bzgl. Case Sensitivity gehen die Meinungen auseinander. Einen ganz interessanten Post habe ich allerdings hier gefunden, wobei auch auf den dazugehörigen RFC eingegangen wird. http://blogs.msmvps.com/shane/2007/09/27/kerberos-and-moss-case-sensitive/ Ich werde das jetzt mal probieren. Update: So, ich hab' jetzt mal etwas herumprobiert und bin auf folgende Ergebnisse gekommen: Die manuell erstellten SPNs werden jetzt verwendet => ich kann es leider nicht mehr nachvollziehen, ob ich die alten SPNs mit einer anderen Schreibweise angelegt habe. Ich habe mich dieses Mal jedenfalls genau an den automatisch generierten Einträgen orientiert (Groß-/Kleinschreibung). Wichtig ist es scheinbar auch, dass immer einen SPN mit Angabe des Ports gibt. Ein SPN mit Instanznamen alleine funktioniert nicht, umgekehrt (mit Port alleine) schon. Übrigens werden die automatisch erstellten SPNs wieder gelöscht, auch wenn man dem Service Account die Domain Admin Rechte wieder wegnimmt, während die Instanz läuft. Ich nehme mal an, dass es daran liegt, dass im Kerberos-Tray noch ein Ticket liegt, wo die Domain Admin Gruppe "draufsteht". Möglicherweise würde es helfen 8h (oder 10?) zu warten, bis das Ticket ungültig ist bevor man die SQL Server Instanz neustartet, damit zwischendurch ein neues Ticket mit den beschränkten Rechten ausgestellt wird. Die Möglichkeit das zu testen habe ich aber gerade nicht. Wenn jemand jetzt noch eine Antwort dazu hat welche Rechte ich dem Service Account geben muss, wäre ich vollkommen zufrieden :) Danke schonmal! gugi

Hi Zahni! Danke für den Hinweis mit der Groß-/Kleinschreibung, das hab' ich bisher überlesen. Ich werde das gleich mal probieren! Bzgl. Berechtigungen: Der SQL Server schreibt / löscht den SPN ja beim Stop/Start der Instanz. Würde vermutlich funktionieren, dass man dem Account die Domain Admin Rechte einfach wieder nimmt und er dann den SPN nicht mehr löschen kann, ich glaube allerdings nicht, dass das die einzig richtige / sauberste Lösung ist. Im Netz wird ja immer wieder beschrieben, dass es möglich sei - nur hat bis jetzt noch nichts von dem bei mir geholfen :/

Hallo zusammen, ich habe ein Anliegen bzgl. der Authentifizierung bei meinem 2-Node SQL Server 2012 AlwaysOn Cluster (Server 2008 R2 SP1). Mir ist im SQL Server Log aufgefallen, dass der Server beim Starten folgenden Fehler protokolliert: The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies. Google spuckt dazu aus, dass das Problem an einem fehlenden SPN liegt. Mit der Query SELECT net_transport, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@spid habe ich herausgefunden, dass sich meine Clients via NTLM und nicht via Kerberos am SQL Server authentifzieren, was ich ja grundsätzlich möchte. Nun habe ich zwei Probleme: 1) Der SQL Server selbst versucht beim Starten prinzipiell einen SPN für FQDN\Instanzname und FQDN\SQLPort anzulegen, woran er mit dem oben genanten Fehler scheitert. Daher habe ich dem Service Account unter dem der SQL Server läuft folgende Rechte auf dem Computer Account des Clusternodes: Read Service Principle Name Write Service Principle Name und write public information auf sich selbst gegeben. Beim Neustart der Instanz protokolliert der SQL Server aber immer wieder denselben Fehler im Log. Testweise wurde der Service Account in die Gruppen Domain Admins bzw. Administrators aufgenommen, dann konnte der SPN beim Starten des SQL Servers automatisch erstellt werden. Sind die SPNs erstmal vom SQL Server erstellt worden, so wird Kerberos verwendet. Erstelle ich die SPNs allerdings selbst mit spn -S MSSQLSvc/sqlserverfqdn:Instanzname domain\service-account dann wird weiterhin NTLM verwendet. Eine Kontrolle mit spn -L domain\service-account ergibt dieselbe Ausgabe für den händisch erstellten sowie für den vom SQL Server automatisch erstellten SPN. Was ist der Grund dafür und welche Rechte benötigt der Service Account nun wirklich damit die SPNs automatisch erstellt werden können? 2) Beim Starten versucht der SQL Server nicht SPNs für die virtuellen Instanzen (AlwaysOn Listener) zu erstellen. Wenn ich diese händisch mit setspn erstelle und danach die Instanz neu starte authentifizieren sich die Clients dennoch mit NTLM anstatt mit Kerberos am SQL Server. Woran liegt das und wie kann ich die Kerberos-Authentifizierung zum laufen kriegen? Danke für eure Unterstützung! gugi