Die Kerberos-Authentifizierung funktioniert nicht mit Verbindungsservern in SQL Server 2012

8

Ich richte eine DEV / TEST-Umgebung mit 2 SQL Servern ein, auf denen SQL Server 2012 unter Windows Server 2012 ausgeführt wird. Wir wechseln von SQL Server 2005 unter Windows Server 2008, wo dies bereits ordnungsgemäß ausgeführt wird.

In SQL Server 2012 funktioniert die Kerberos-Authentifizierung nicht.

Jeder Server verfügt über ein eigenes Active Directory-Konto mit den Rechten "Write Service Principal Names" und "Read Service Principal Names", die von Active Directory-Benutzern und -Computern gewährt werden. Wann immer ich eine Verbindung zu den SQL Server 2005-Servern herstelle und Folgendes ausführe:

SELECT net_transport, auth_scheme 
FROM sys.dm_exec_connections 
WHERE session_id = @@SPID;

Aha:

net_transport    auth_scheme
TCP              KERBEROS

Wenn ich dieselbe Abfrage für meine neuen SQL Server 2012-Instanzen durchführe, wird Folgendes angezeigt:

net_transport    auth_scheme
TCP              NTLM

Wenn ich SetSPN -Q MSSQLSvc/*Active Domain nach Dienstprinzipalnamen abfrage, werden sowohl die Server 2005 als auch 2012 aufgelistet, und zwar genauso wie der Name des Servers.

Zum Beispiel:

MSSQLSvc/SERVERa2005.domain.inet
MSSQLSvc/SERVERa2005domain.inet:1433
MSSQLSvc/SERVERb2005.domain.inet
MSSQLSvc/SERVERb2005domain.inet:1433
MSSQLSvc/SERVERa2012.domain.inet
MSSQLSvc/SERVERa2012domain.inet:1433
MSSQLSvc/SERVERb2012.domain.inet
MSSQLSvc/SERVERb2012domain.inet:1433

Was muss ich noch tun, um die Kerberos-Authentifizierung für SQL Server 2012 zu aktivieren? Books Online scheint nichts anderes zu sagen zu haben, als dass die SPNs eingerichtet werden müssen. Welches klar sind sie. SQL Server-Fehlerprotokolle auf beiden 2012-Computern sagen:

2012-12-10 14:55:47.630 The SQL Server Network Interface library 
                            successfully registered the Service Principal Name (SPN)
                            [ MSSQLSvc/SERVERa2012.domain.inet ] for the SQL Server
                            service. 

2012-12-10 14:55:47.630 The SQL Server Network Interface library 
                            successfully registered the Service Principal Name (SPN) 
                            [ MSSQLSvc/SERVERa2012.domain.inet:1433 ] for the SQL 
                            Server service. 

2012-12-10 14:55:47.590 SQL Server is attempting to register a Service 
                            Principal Name (SPN) for the SQL Server service. 
                            Kerberos authentication will not be possible until a 
                            SPN is registered for the SQL Server service. This is an
                            informational message. No user action is required.

— Max Vernon
quelle

2

Meine bevorzugten Kerberos-Fehler werden durch Computer verursacht, deren Uhren "zu weit" auseinander gerutscht sind. Stellen Sie sicher, dass sie mit der offiziellen Zeit der Domain synchronisiert sind.

— Straße

1

Stellen Sie außerdem sicher, dass die Zeitzone korrekt ist.

— Dave Markle

8

Der Umgang mit Active Directory macht immer so viel Spaß. Das Wichtigste dabei ist, dass Sie feststellen, dass es sich um verteilte Daten handelt, deren Verbreitung in Ihrem Netzwerk einige Zeit in Anspruch nehmen kann.

Der Name der betreffenden SQL Server wurde im Rahmen eines Aktualisierungsvorgangs geändert. Wir haben einen vorhandenen Computer (SQL01) mit SQL Server 2005 durch einen neuen Computer (SQL03) mit SQL Server 2012 ersetzt. SQL03 war der Name des neuen Computers, als ich ihn zum ersten Mal in der Domäne eingerichtet habe. SQL01 hatte einen vorhandenen SPN, der einem einzelnen Domänenkonto zugeordnet war, das wir für mehrere SQL Server verwendet haben, auf denen 2005 ausgeführt wird. Da es eine bewährte Methode ist, nur einen einzelnen Computer unter einem bestimmten Domänenkonto auszuführen, habe ich ein neues Konto erstellt und SQL03 so konfiguriert, dass es damit ausgeführt wird Kontobezeichnung. Nachdem das ursprüngliche SQL01 außer Betrieb genommen und SQL03 in SQL01 umbenannt wurde, trat ein SPN-Konflikt auf.

Ich habe das Dienstprogramm SetSPN.exe verwendet, um den widersprüchlichen SPN (auf dem alten Domänenkonto) zu löschen - und es hat immer noch nicht funktioniert. Zu diesem Zeitpunkt habe ich nichts weiter getan und bin zu anderen Punkten übergegangen. Als ich ungefähr 30 Minuten später zurückkam, funktionierte die KERBEROS-Authentifizierung. Ich musste einfach warten, bis sich die SPN-Änderung unter unseren Domänencontrollern verbreitet hatte.

Ich SetSPN -L DOMAIN\Accounthabe diese Ausgabe verwendet und verglichen, SetSPN -Q MSSQLSvc/Machine.domain.inet:1433um die doppelten SPNs zu finden, und dann SetSPN -D MSSQLSvc/Machine.domain.inet:1433 DOMAIN\Accountdie alten SPNs entfernt.

— Max Vernon
quelle

2

Weitere Informationen zur Fehlerbehebung bei Kerberos-Fehlern finden Sie unter den folgenden Links

— Peter Vandivier
quelle