L'authentification Kerberos ne fonctionne pas avec les serveurs liés dans SQL Server 2012

8

Je mets en place un environnement DEV / TEST à l'aide de 2 serveurs SQL exécutant SQL Server 2012 sur Windows Server 2012. Nous passons de SQL Server 2005 à Windows Server 2008, où nous l'avons déjà correctement installé.

Dans SQL Server 2012, l'authentification Kerberos ne fonctionne pas.

Chaque serveur possède son propre compte Active Directory qui dispose des droits "Écrire les noms principaux du service" et "Lire les noms principaux du service" accordés par le biais des utilisateurs et des ordinateurs Active Directory. Chaque fois que je me connecte aux serveurs SQL Server 2005 et que j'exécute:

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

Je vois:

net_transport    auth_scheme
TCP              KERBEROS

Lorsque j'effectue la même requête sur mes nouvelles instances SQL Server 2012, je vois:

net_transport    auth_scheme
TCP              NTLM

Si j'utilise SetSPN -Q MSSQLSvc/*pour interroger le domaine actif pour les noms principaux de service, je vois les serveurs 2005 et 2012 répertoriés, exactement de la même manière que le nom du serveur.

Par exemple:

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

Que dois-je faire d'autre pour activer l'authentification Kerberos sur SQL Server 2012? Books Online semble n'avoir rien d'autre à dire, sauf que les SPN doivent être configurés. Ce qui est clairement le cas. Les journaux d'erreurs SQL Server sur les deux machines 2012 indiquent:

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.
sql-server sql-server-2012 linked-server kerberos Max Vernon
la source
2
Mes échecs Kerberos préférés sont causés par des ordinateurs dont les horloges ont dérivé "trop ​​loin". Assurez-vous qu'ils sont synchronisés avec l'heure officielle du domaine.
Détroit de Darin
1
Assurez-vous également que le fuseau horaire est correct.
Dave Markle

Réponses:

8

Gérer Active Directory est toujours très amusant. La chose la plus importante ici est de réaliser que vous traitez avec des données distribuées qui peuvent prendre du temps à se propager sur votre réseau.

Les serveurs SQL en question ont vu leur nom changé dans le cadre d'une procédure de mise à niveau; nous avons remplacé une machine existante (SQL01) exécutant SQL Server 2005 par une nouvelle machine (SQL03) exécutant SQL Server 2012. SQL03 était le nom de la nouvelle machine lorsque je l'ai initialement configurée dans le domaine. SQL01 avait un SPN existant associé à un compte de domaine unique que nous avons utilisé pour plusieurs serveurs SQL exécutant 2005. Puisqu'il est recommandé d'exécuter une seule machine sous un compte de domaine donné, j'ai créé un nouveau compte et configuré SQL03 pour qu'il s'exécute avec celui-ci. nom du compte. Après avoir mis hors service SQL01 d'origine et renommé SQL03 en SQL01, il y a eu un conflit SPN.

J'ai utilisé l'utilitaire SetSPN.exe pour supprimer le SPN en conflit (sur l'ancien compte de domaine) - et cela n'a toujours pas fonctionné. À ce stade, je n'ai rien fait de plus et je suis passé à d'autres éléments. Quand je suis revenu environ 30 minutes plus tard, l'authentification KERBEROS fonctionnait. J'avais simplement besoin d'attendre que le changement de SPN se propage parmi nos contrôleurs de domaine.

J'ai utilisé SetSPN -L DOMAIN\Accountet comparé cette sortie avec SetSPN -Q MSSQLSvc/Machine.domain.inet:1433pour trouver les SPN en double, puis utilisé SetSPN -D MSSQLSvc/Machine.domain.inet:1433 DOMAIN\Accountpour supprimer les anciens SPN.

Max Vernon
la source