SQL Server 2012 AlwaysOn Kerberos

[gugi 0]

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

[zahni 554]

Zum obigen Fehler (hast Du ja schon selber herausgefunden): Den SQL-Service-Account beim Start des SQL-Servers mal kurz Domain-Admin-Rechte geben, Dann erstellt er seinen SPN.

Dann wieder auf "normal" reduzieren.

 

Zur manuellen Erstellung: Beachte, dass die SPNs case sensitive sind.

Der Rest steht u.a  hier  http://blogs.msdn.com/b/sql_protocols/archive/2005/10/12/479871.aspx

[gugi 0]

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 :/

[Dukel 454]

Ich hatte bisher immer den SPN manuell gesetzt. Evtl. fehlen dir Einträge?

Ich habe meist mit Hostname und FQDN gesetzt und mal mit Port und ohne Port.

 

Mein SQL User hat keine Adminrechte. Auch nicht temporär bekommen.

 

Bei mir sieht das folgendermaßen aus (nutze keinen Instanznamen):

MSSQLSvc/SP-SQL.fqdn.de:1433
MSSQLSvc/SP-SQL.fqdn.de
MSSQLSvc/SP-SQL:1433
MSSQLSvc/SP-SQL
 

[gugi 0]

Ich hatte bisher immer den SPN manuell gesetzt. Evtl. fehlen dir Einträge?

Ich habe meist mit Hostname und FQDN gesetzt und mal mit Port und ohne Port.

 

Mein SQL User hat keine Adminrechte. Auch nicht temporär bekommen.

 

Bei mir sieht das folgendermaßen aus (nutze keinen Instanznamen):

MSSQLSvc/SP-SQL.fqdn.de:1433

MSSQLSvc/SP-SQL.fqdn.de

MSSQLSvc/SP-SQL:1433

MSSQLSvc/SP-SQL

 

 

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

bearbeitet 22. Dezember 2014 von gugi

[Dukel 454]

OT: Wieso hat man 9 Named Instances laufen? Geht das nicht nur mit einer Instanz?

 

Hast du alle SPN's mit Port oder mit _und_ ohne Port?

[gugi 0]

OT: Wieso hat man 9 Named Instances laufen? Geht das nicht nur mit einer Instanz?

 

Hast du alle SPN's mit Port oder mit _und_ ohne Port?

 

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.