Discussion :

[maxced01]

Bonjour
J'ai actuellement des liens qui existent en deux serveurs SQL un en 2014 et l'autre en 2016.
J'ai voulu modifier les paramètres de ces serveurs liés afin que les connexions s'effectuent dans le contexte de sécurité actuelle (en plus d'un mappage) et non plus avec une attribution de compte en particulier.
Si je laisse en l'état plus personne ne peut utiliser les serveurs liés :

Msg*18456, Niveau*14, État*1, Ligne*1
Échec de l'ouverture de session de l'utilisateur*'AUTORITE NT\ANONYMOUS LOGON'.

j'ai fait les tests avec des comptes existant sur les deux serveurs, (y compris mon compte AD avec les droits sa) et le message reste le même.

Du coup j'ai du laisser le mappage et forcé l'utilisation d'un compte (seront effectuées dans ce contexte de sécurité : )

une idée de résolution autre que la montée de version ?

pour info la même configuration de serveurs liés est opérationnelle entre deux serveurs 2016.

Merci encore

[mikedavem]

Bonjour
une idée de résolution autre que la montée de version ?

Il faut que tu configures Kerberos sur tes instances SQL Server concernés, sans quoi le "double saut" au niveau authentification ne peut se faire. Pour faire court, quand tu utilises l'authentification Windows sur un serveur lié, il faut que le premier SQL Server puisse déléger le jeton d'authentification au serveur cible (serveur lié). L'erreur que tu rencontres t'indique qu'il y a un problème dans cette chaîne d'authentification.

Dans les grandes lignes:

client -> sql1 -> sql2

1) S'assurer que tous tes serveurs SQL (sql1 et sql2) ont un SPN enregistré pour le compte de service SQL
2) Autoriser la délégation sur le serveur SQL sql1

Cet article est toujours valable pour une explication détaillée et la configuration Kerberos => https://mikedavem.developpez.com/tut...tion-kerberos/

Il y a aussi un utilitaire qui peut t'aider fourni par Microsoft => https://docs.microsoft.com/fr-fr/tro...ager-available

++

[maxced01]

Merci bien pour ce retour