- Windows Server 2008 / Server 2008 R2 und Microsoft SQL Server 2005, 2008 und 2008 R2
Für viele Server-Dienste ist Kerberos essentiell. Doch gerade die oft unkomplizierte Fallbacklösung NTLM ist ein Grund dafür, dass man viel zu selten überprüft, ob alle Dienste mit Kerberos klar kommen. Dieser kleine Tipp soll zeigen, wie man die Funktion von Kerberos für den Microsoft SQL Server leicht überwachen kann und gleichzeitig den Auftakt bilden für eine kleine Serie, in der ich in unregelmäßigen Abständen kleine Tipps rund um den Microsoft SQL Server vorstellen möchte.
Das Problem
Mit folgender Abfrage bekommt man einen Überblick über alle derzeit bestehende Verbindungen zur Datenbank Instanz und der dabei verwendeten Authentifizierungsmethoden.
SELECT client_net_address, auth_scheme FROM sys.dm_exec_connections
Sollte es Probleme mit der Kerberos Authentifizierung geben bekommt man folgendes Ergebnis angezeigt:
Keine Verbindung benutzt Kerberos
Dies trifft besonders oft in der Kombination des SQL Servers mit den Betriebssystem Versionen Windows Server 2008 und Windows Server 2008 R2 zu. Bei der Kommunikation der unterschiedlichen Services untereinander ist jedoch eine sichere Verbindung sehr wichtig. Doch was ist die Ursache dieses Verhaltens?
Die Ursache
Betrachtet man Netzwerktraces und die Eventlogs von einigen Clients und des SQL-Servers etwas genauer kann man schnell die Ursache herausfinden. Die SQL Instanz läuft unter einem eigenen Service Account, also nicht dem lokalen Netzwerk Service. Dieses Servicekonto besitzt nicht die erforderlichen Berechtigungen, um SPNs für den SQL Server zu registrieren. Hat man einmal die Ursache für das Problem erkannt ist es leicht das Problem zu beheben. Die einfache Lösung ist dabei die MSSQL SPNs von Hand zu registrieren.
Zunächst einmal lässt man sich die registrierten SPNs für den SQL Server Service Account anzeigen mit setspn –l yourDomain\SQLSrvAccountName. Fehlen bei der Auflistung die Einträge MSSQLSvc\DBServer.yourDomain:1433 und MSSQLSvc\DBServer.yourDomain kann man die Einträge von Hand hinzufügen. Dies macht man mit dem Befehl setspn –a <ServicePrinvipleName> yourDomain\Account. Folgende SPNs müssen registriert werden:
MSSQLSvc\DBServer:1433 yourDomain\SQLSrvAccountName MSSQLSvc\DBServer.yourDomain.de:1433 yourDomain\SQLSrvAccountName MSSQLSvc\DBServer yourDomain\SQLSrvAccountName MSSQLSvc\DBServer.yourDomain.de yourDomain\SQLSrvAccountName
Anschließend muss nur noch der SQL Server Dienst und der SQL Server Agent Dienst neu gestartet werden. Allerdings ist diese Lösung nicht sonderlich elegant.
Die Lösung
Weitaus besser ist es da, dem Service Account die notwendigen Berechtigungen zu geben. Leider ist das nicht in der Active Directory Users and Computers Konsole möglich, sondern nur mit Hilfe von AdsiEdit. Zuerst sucht man sich in AdsiEdit im Default Naming Context den Account des SQL Server Services heraus und erteilt der Identität SELF die erweiterten Berechtigungen Read bzw. Write servicePrincipalName.
SQL SPN Berechtigungen
Nachdem die SQL Services neu gestartet wurden, kann man die erfolgreiche Registrierung durch den Befehl setspn -l überprüfen. Sind die SPN Einträge vorhanden? Wenn ja, dann kann man die TSQL-Abfrage vom Anfang dieses Artikels noch einmal gegen die Datenbank laufen lassen. Nun sollte die Abfrage folgendes Ergebnis ergeben:
Kerberos für alle Netzwerkverbindungen
Lediglich lokale Verbindungen und Named Pipe Verbindungen sollten nun ohne Kerberosauthentfizierung existieren. Wenn nun immer noch viele NTLM Verbindungen bestehen, dann liegt dies wahrscheinlich nicht mehr am SQL Server und die Fehlersuche muss bei den Clients fortgesetzt werden.
Ich hoffe dieser Tipp war hilfreich. Im nächsten Teil der Serie werde ich über einige kleine Kniffe bei der Installation des SQL Servers 2008 und des SQL Servers 2008 R2 schreiben, die einem das Leben leichter machen können.
