Comment faire fonctionner mon serveur lié en utilisant l'authentification Windows?

J'essaie d'obtenir un serveur lié à ServerA créé sur un autre serveur, ServerB en utilisant "Être créé en utilisant le contexte de sécurité actuel de la connexion" dans un environnement de domaine. J'ai lu que je devrais avoir des SPN créés pour les comptes de service qui exécutent SQL Server sur chacun des serveurs afin d'activer Kerberos. Je l'ai fait et les deux montrent maintenant que le schéma d'authentification est Kerberos, cependant, je suis toujours confronté à l'erreur:

"Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'".

Dans Active Directory, je peux voir que le compte de service pour ServerB est approuvé pour la délégation à MSSQLSvc, mais j'ai remarqué que le compte de service pour ServerA n'a pas encore activé «Approuver cet utilisateur pour la délégation». Le serveur cible doit-il également activer cette option? Faut-il autre chose pour pouvoir utiliser la connexion Windows actuelle pour utiliser un serveur lié?

Chaque machine de la chaîne, de votre bureau au serveur que vous appelez, doit être compatible avec Kerberos pour que la confiance avance au-delà du premier saut. Donc, oui, le serveur doit faire confiance à l'utilisateur pour la délégation.

Le "Échec de la connexion pour l'utilisateur 'NT AUTHORITY \ ANONYMOUS LOGON'" indique presque toujours un problème de délégation.

• Votre compte Windows doit avoir accès à la fois à ServerA et ServerB.
• Vous ne devez pas avoir le paramètre «Le compte est sensible et ne peut pas être délégué».
• ServerA et ServerB doivent avoir leur propre SPN enregistré.
• Les serveurs doivent être TCP / IP ou des canaux nommés doivent être connectés.

L'article de la documentation en ligne de SQL Server qui offre plus de détails est «Configuration des serveurs liés pour la délégation»: http://msdn.microsoft.com/en-us/library/ms189580(v=sql.105).aspx

Deux choses ici:

1. Lorsque vous utilisez un serveur lié sans mapper la connexion du serveur local au serveur distant, ne vous connectez pas à une machine distante et utilisez une connexion Windows pour exécuter des scripts. Le problème du double saut entre en jeu car il utilise l'emprunt d'identité.

2. En outre, vous devrez configurer le DTC local via DCOMCNFG pour la communication. Voir photo ci-jointe.

(DCOMCNFG -> Services de composants -> Ordinateurs -> Poste de travail -> Coordonnateur des transactions distribuées -> LocalDTC -> Propriétés -> Sécurité)