Linked Server avec login

Bonjour,

Je te tente de faire un linked server entre deux serveurs sql 2008 mais j'obtiens toujours un erreur :

Code:

---

1 2 3

exec sp_addlinkedserver N'Aramis', N'Sql Server';   EXEC sp_addlinkedsrvlogin 'Aramis', 'false', 'UserTestDest', 'UserTestSource', 'testlinked'

---

Code:

---

select * from [aramis]...

---

Citation:

---

Msg 18456, Level 14, State 1, Line 1
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

---

Avez vous des pistes de solution ?

Merci ! :fleur:

L'authentification mixte est-elle activée sur le serveur distant et l'avez vous rebooté ?

A +

Citation:

---

Envoyé par SQLpro

L'authentification mixte est-elle activée sur le serveur distant et l'avez vous rebooté ?

A +

---

Oui l'authentification mixte est activée, et ce depuis l'installation du serveur. Et non je n'ai pas rebooté le serveur distant... pourquoi je ferais cela, c'est un serveur de production, le moins possible on arrête les services le mieux on se porte :)

Merci :)

Pour la création du mappage du login :
0. Vérifier que le login_du_user/password_du_user est bien valide.
1. Utiliser ceci pour voir (remplacer login_du_user/password_du_user par les bonnes valeurs)

Code:

---

1 2 3 4

EXEC sp_addlinkedsrvlogin @rmtsrvname ='Aramis', @useself = 'false', @rmtuser = 'login_du_user', @rmtpassword ='password_du_user'

---

Bonjour,

Désolé du délai j'étais sur un autre dossier.

Ok oui cela fonctionne si je spécifie un login et password correct... merci. :ccool:

Et comment peux-t-on faire fonctionner le linked server en utilisant l'option "Be made using the login's current security context".

Lorsque je fais ceci :

Code:

---

1 2 3

exec sp_addlinkedserver N'Aramis', N'Sql Server';   EXEC sp_addlinkedsrvlogin 'Aramis', 'true'

---

Et que je tente une lecture sur aramis :

Code:

---

select * from aramis.usager.dbo.adresse

---

Cela me retourne l'erreur

Citation:

---

Msg 18456, Level 14, State 1, Line 1
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

---

:cry:

Citation:

---

Et comment peux-t-on faire fonctionner le linked server en utilisant l'option "Be made using the login's current security context".

---

Quel type de login est utilisé ? Windows ?

Si c'est le cas il faudra mettre en place de la délégation Kerberos.

Citation:

---

Envoyé par Ptit_Dje

Quel type de login est utilisé ? Windows ?

Si c'est le cas il faudra mettre en place de la délégation Kerberos.

---

Oui les usagers se connectent uniquement avec des accès Windows (usager AD ou groupe AD).

Je vais devoir en parler avec l'équipe d'infrastructure parce que je n'y connais rien en Kerberos.

Tu peux trouver la réponse longue ici.

La réponse courte c'est:
- Il faut enregistrer un SPN pour chacune des instances.
Un SPN est défini, dans le cas de SQL server, pour un service tournant sur un serveur pour un compte bien défini.

En gros il te faut tourner cette commande avec un compte admin du domaine pour chaque instance impliquée:

Code:

---

1 2	setspn -s MSSQLSvc/<servername.fqdn>:<portInstance> domaine\serviceAccount

---

J'appele ce SPN un "lecteur de ticket Kerberos", c'est lui qui permet à l'instance de recevoir et de traiter des connections utilisant ce protocole de sécurité.

- Pour le compte de service tournant l'instance ou tu crées ton linked server, il faut au niveau AD (dsa.msc -> recherche du compte -> tab délégation) autorisé ce compte à déléguer (trust for delégation).
Il y a alors 2 possibilités:
l'autoriser à déléguer à tous les services (en gros il peut envoyer des tickets partout) ou restreindre la délégation à un ou plusieurs services définis (plus sécure).
Dans le cas ou tu choisis le coté sécure, il faut alors enregistrer comme target le SPN défini pour le compte de service de l'instance target.

Voila, ca devrait t'aider ;)

Juste quelques rectifications sur certains termes mais la trame est bien celle proposée par Ptit_Dje.

Citation:

---

J'appele ce SPN un "lecteur de ticket Kerberos"

---

Le SPN est en réalité un identificateur unique d'un service dans l'annuaire AD. Il permet d''adresser le ticket vers le bon service. Le "lecteur de ticket" est en réalité le KDC dans l'infrastructure Kerberos.

Citation:

---

traiter des connections utilisant ce protocole de sécurité

---

Le protocole Kerberos est un protocole d'authentification plus qu'un protocole de sécurité. IPSEC est un protocole de sécurité par exemple.

++

Merci pour les précisions.:ccool:

Je suis toujours en attente de mon collègue de l'équipe d'infrastructure concernant kerberos, mais il est très occupé !!

Citation:

---

Envoyé par mikedavem

Juste quelques rectifications sur certains termes mais la trame est bien celle proposée par Ptit_Dje.



Le SPN est en réalité un identificateur unique d'un service dans l'annuaire AD. Il permet d''adresser le ticket vers le bon service. Le "lecteur de ticket" est en réalité le KDC dans l'infrastructure Kerberos.


Le protocole Kerberos est un protocole d'authentification plus qu'un protocole de sécurité. IPSEC est un protocole de sécurité par exemple.

++

---

C'est vrai que je n'étais pas trop précis :)
A vrai dire, sans le SPN le service SQL Serveur ne peut pas gérer l'authentification Kerberos -> le lien pour moi en temps que lecteur de ticket d'un point de vue SQL Server.

Concernant le "trust for delegation" du compte au niveau AD, c'est grave de le comparer à une license de taxi ? ;)
A tous les services, le compte peut aller à toutes les adresses.
Constrained, le compte peut aller seulement aux adresses définies dans la liste.

Citation:

---

Envoyé par Ptit_Dje

C'est vrai que je n'étais pas trop précis :)
A vrai dire, sans le SPN le service SQL Serveur ne peut pas gérer l'authentification Kerberos -> le lien pour moi en temps que lecteur de ticket d'un point de vue SQL Server.

---

En réalité sans le SPN le KDC (centre de distribution des clés) ne pourra pas chiffrer le TGS (ticket de service) utilisé pour l'authentification du client vers le service concerné. Sans le SPN impossible de déterminer le mot de passe à utiliser pour chiffrer le TGS ...

Citation:

---

Envoyé par Ptit_Dje

Concernant le "trust for delegation" du compte au niveau AD, c'est grave de le comparer à une license de taxi ? ;)
A tous les services, le compte peut aller à toutes les adresses.
Constrained, le compte peut aller seulement aux adresses définies dans la liste.

---

Lol grave non :-) Je préfère personnellement le comparer à un abonnement. Selon l'abonnement que tu as tu peux soit avoir accès à tout soit avoir accès à des services à la carte mais pourquoi pas une licence de taxi ;-)

++