Comment arrêter d'utiliser des informations de connexion SQL Server sur un serveur lié?

Question

J'ai un serveur lié basé en Italie server_italia qui se connecte à un serveur basé à Oregon USA ORDB1

nous sommes sur différents mais domaines de confiance .

La connexion de server_italia à ORDB1 est effectué via un serveur lié à l'aide d'un compte SQL Server comportant une connexion et des autorisations requises sur ORDB1.

Je suis un sysadmin et même domain admin dans mon domaine et mon server_italia mais je suis seulement sysadmin à l'intérieur du serveur SQL sur ORDB1.

Il y a une question similaire:

Comment puis-je obtenir mon serveur lié à utiliser l'authentification Windows?

mais cela ne fournit pas the réponse.

Voici mon serveur lié:

quand j'exécute les requêtes suivantes sur server_italia Je reçois les résultats suivants:

SELECT [the_server]=@@servername,
auth_scheme 
FROM sys.dm_exec_connections WHERE session_id = @@spid ;  


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

En Oregon, je reçois ceci:

Si mes collègues américains obtiennent:

1. les noms de services de service enregistrés pour les services étant exécutés par votre compte de service

2. Configurez l'authentification Kerberos sur leur serveur

3. Configurer délégation contrainte Comme cela permettra aux informations d'identification d'être transmises, sinon vous pouvez toujours rencontrer le problème double-hop . - Ajouté sur les commentaires par - John Eisbrener

Serais-je capable d'utiliser mon linked server sans le sql server account login impersonation?

Answer 1

Je ne sais pas si vous avez eu ceci résolu ou non, mais après avoir récemment effectué une nouvelle découverte des exigences pour que la délégation fonctionne, je pouvais au moins fournir une réponse au cas où les autres rencontrent votre poste avec questions similaires.

Pour aider à rendre mon post clair (surtout à quiconque la rencontrant et non à la lecture de votre question), la délégation est la capacité d'un service intermédiaire à remettre les informations d'identification du client à un service secondaire pour le compte du client. Représenté visuellement, comme suit:

Dans ce cas serveur A est le service intermédiaire qui remonte au Client Critiques sur le service secondaire, serveur B. Dans ton cas, server_italia serait considéré comme le serveur intermédiaire et ORDB1 serait le service secondaire.

Niveau fonctionnel Active Directory (Ad)

D'abord et avant tout, votre niveau fonctionnel du domaine Heureusement dicte les options à votre disposition. Si votre niveau de fonctionnement est à n'importe quelle version avant Windows 2012, la délégation entre les domaines est limitée uniquement à une délégation sans contrainte. Avant 2012, La délégation contrainte était limitée à un seul domaine uniquement et n'aurait pas de capacités croisées.

Si vous exécutez un niveau fonctionnel de 2012 ou plus tard, vous avez des options supplémentaires. Cela dépendra donc de votre préférence pour l'administration, le contrôle d'accès, etc. Un niveau fonctionnel de 2012 ouvre la capacité de déléguer des diplômes entre les domaines via une délégation non contrainte. , délégation traditionnelle contrainte , ou délégation contrainte fondée sur des ressources . Le reste de ma réponse supposera que vous utilisez un niveau fonctionnel de 2012+, mais sinon, les instructions de configuration de la délégation non contrainte sont les mêmes, quel que soit le niveau fonctionnel.

Exigences communes

Quel que soit le type de délégation que vous choisissez (toutes les options seront répertoriées ci-dessous), toutes les configurations nécessiteront la configuration de base suivante pour le compte Vous utiliserez pour exécuter le service "Intermédiaire" (par exemple Server A Dans l'image ci-dessus, mais cela peut s'appliquer à tout service intermédiaire tel qu'une base de données, un site Web hébergé sur IIS, SSIS, une application .NET, etc.). Sur le domaine, le compte exécutant les informations d'identification des délégations de service à d'autres services nécessitera que les propriétés publicitaires suivantes soient définies:

• ServicePrincipalnames : Ceci doit avoir des SPNS pour le serveur A classé qui déléguera des informations d'identification. Dans votre exemple, ceux-ci ressembleraient à ce qui suit (en supposant que vous êtes sur le domaine EURO de la forêt CONTOSO forêt): MSQLSVC/Server_italia.euro.contoso.com, MSQLSVC/SERVER_IALIA.EURO .Contoso.com: 1433
• KerberosencyptionType : AES256 (et AES128 Si vous choisissez d'utiliser ce type de cryptage) doit être activé. Ceci est important plus tard, mais ce paramètre garantira des jetons cryptés par Kerberos peut être délégué.

Remarque: Les propriétés susmentionnées peuvent être visualisées et définies via diverses méthodes. Les tilisateurs actifs de la Direcotory et ordinateurs MMC Snapin est l'interface utilisateur graphique la plus courante que vous pouvez utiliser pour ajuster ces propriétés, mais cette interface obscose beaucoup de ces propriétés et est déchets totaux lorsqu'il s'agit de gérer les comptes de service gérés par groupe . En conséquence, je vous suggère d'utiliser le module ActiveDirectory PowerShell car il vous permet de définir ces propriétés explicitement via le Set-ADUser ou Set-ADServiceAccount Commandes. De plus, vous pouvez afficher les propriétés d'un compte utilisateur/service via le Get-ADUser ou Get-ADServiceAccount Commandes.

En outre, tous les serveurs SQL doivent avoir un SPN enregistré . Vous pouvez Créez-les manuellement , mais si vous imbriquez les comptes de service exécutant vos serveurs SQL dans une OU appropriée, SPNS auto-enregistrées se produira automatiquement. Les instructions sur ce processus peuvent être trouvées ici .

Types de délégation

Encore une fois, supposant que vous utilisiez un niveau fonctionnel de 2012 de 2012 ou plus tard, vous disposez de 3 options pour effectuer une délégation croisée. Je vais les énumérer dans les plus faciles à configurer/le moins sécurisés pour la plus frustrant pour configurer/obtenir des approches les plus sécurisées. N'importe lequel d'entre eux fonctionnera et la quantité d'exposition de l'administration/de la sécurité que vous souhaitez traiter sera complètement à vous.

Une autre friche ici, est que rien n'empêche de vous empêcher de configurer un compte à utiliser plusieurs types de délégation répertoriés ci-dessous. Ces configurations ne sont pas mutuellement exclusives. Vous devriez faire de votre mieux pour éviter d'avoir une configuration de compte dans plusieurs régimes de délégation, car il utilisera probablement la configuration la moins sécurisée d'abord (section sur la détermination de la configuration de vos comptes ci-dessous).

Délégation non contrainte

La délégation non contrainte est la configuration la plus simple à la configuration et à une approche moins restrictive. Cette configuration permet au compte de service exécutant le serveur A à déléguer Toute identification à Toute service secondaire. Ceci est représenté visuellement dans l'image ci-dessus avec les flèches bleues indiquant aucune limitation de la connexion client inbounde ou du service secondaire que les informations d'identification peuvent être déléguées. Pour configurer ce type de délégation sur le Compte intermédiaire, il vous suffit de définir la propriété AD suivante (en plus de celles énumérées ci-dessus):

• fidudedfordélégation - définissez ceci sur True

Cela était tout ce qu'il y avait tout cela, mais avec Patch Security Windows de juillet 2019 , vous devrez également réactiver la délégation entre les fiducies, comme indiqué dans ce lien. Ce correctif de sécurité a été vraiment conçu pour faire face à la baisse grave de cette configuration, qui est bien mieux expliquée dans ce post: Chasse dans Active Directory: délégation non contrainte et fiducies de la délégation et des forêts . Encore une fois, sauf si vous utilisez un niveau fonctionnel de la publicité avant 2012, il n'est pas recommandé d'utiliser ce type de délégation.

Délégation traditionnelle contrainte

Délégation traditionnelle contrainte limite le serveur de services A peut déléguer des autorisations à, de sorte que le compte de service exécutant le serveur A est autorisé à déléguer des informations d'identification aux services explicitement énumérées. Par exemple, il peut toujours déléguer les informations d'identification de n'importe qui, mais elle ne peut transmettre que lesdits identifiants aux services explicitement énumérées. Donc, visuellement, nous limitant les "destinations" que nous pouvons déléguer à, comme indiqué par la flèche jaune:

Les propriétés de l'annonce (en plus de ceux énumérés dans exigences communes section ci-dessus), vous devez configurer sur le compte intermédiaire sont les suivants:

• MSDS-AWAYTODELEGATETO - Ceci doit être une liste de tous les SPN applicables que ce compte est autorisé à déléguer des informations d'identification. Dans cet exemple, ceux-ci ressembleraient aux éléments suivants: MSSQLSVC/ORDB1.USA.CONTOSOO.COM, MSSQLSVC/ORDB1.USA.CONTOSO.COM: 1433 (en supposant que le ORDB1 Server est sur un domaine USA du domaine CONTOSO forêt).

Avec cette configuration, vous limitez la délégation à AD KERBEROS Jetons uniquement. Si vous souhaitez déléguer non -KERBEROS informations d'identification, telle que celles transmises via NTLM, etc., vous pouvez configurer Ce compte à déléguer ANY protocole en définissant également les biens suivants:

• Trustedtoauthfordélégation - Placez ceci sur True

L'utilisation de la configuration de protocole ANY est intrinsèquement risquée. Cet article de blog creuse plus loin dans ces propriétés et leurs ramifications, et à moins qu'il ne soit nécessaire de définir cela sur TRUE, il est recommandé de ne pas le faire.

D'un point de vue personnel, nous utilisons souvent une délégation traditionnelle contrainte car elle est facile à configurer et relativement sécurisée (sauf si vous décidez d'utiliser la délégation pour ANY protocole, puis vous vous préparez à des problèmes, à mon avis).

Délégation contrainte basée sur les ressources

Délégation contrainte basée sur les ressources limite les services intermédiaires que le service secondaire permet des informations d'identification déléguées. Ceci est légèrement différent des autres configurations en ce que la configuration du serveur a comme dans les configurations antérieures, nous vous configurerons Server B en répertoriant les services qu'il faudra faire confiance aux informations d'identification déléguées. Ceci est fait sans avoir à apporter des modifications supplémentaires sur le compte intermédiaire exécutant le serveur A. Donc, dans ce scénario, lorsque Server a tente de transmettre les informations d'identification de BOB, Server B identifiera ce serveur A est un service "fiducié" qui peut déléguer des autorisations et l'authentification se produira sans problème. Représenté visuellement, il ressemblerait comme suit:

Pour être absolument clair ici, le compte intermédiaire (E.G. Server A) nécessite toujours les propriétés dans le Exigences communes La section ci-dessus est configurée. De plus, le service de destination (i.e. serveur A) nécessite que la propriété AD supplémentaire soit définie:

• PrincipallalleDtoDelegateToAccount - Cela doit disposer de tous les SPNS applicables énumérés de ces services qui font confiance à la délégation des diplômes. Dans cet exemple, ceux-ci ressemblent aux éléments suivants: MSSQLSVC/SERVER_IALIA.EURO.CONTOSO.COM, MSSQLSVC/SERVER_IALIA.EURO.CONTOSOO.COM: 1433

C'est ça ... conceptuellement. Testez ceci pour être certain, mais des articles que j'ai trouvés décrivant cette approche, c'est vraiment tout ce qui est nécessaire. En fait, cela article MS s'exécute dans le processus et répertorie les commandes PowerShell applicables nécessaires à la configuration de ce programme pour que un exemple de programme PowerShell puisse être exécuté pour confirmer le double saut et cette délégation contrainte basée sur des ressources travaillera pour vous. De plus, cette configuration de la délégation devrait travailler entre les domaines sans problème (ni exigence d'une confiance, de ce que j'ai lu). L'inconvénient est que nous devons configurer tous les "points de fin" qui peuvent être plus d'administration de travail à long terme en fonction de la façon dont votre configuration est.

Comment puis-je savoir à quels paramètres de délégation que j'ai configurés?

À mon avis, identifier la configuration de la délégation qu'un compte exécuté est à peu près comme clair comme boue . Heureusement Willem Kasdorp a posté un article avec A Script PowerShell Pour vous montrer ce que vos comptes sont actuellement configurés avec. Si vous exécutez ceci à partir d'un ordinateur avec le module ActiveDirectory PowerShell installé, vous devriez être prêt à partir. Espérons que la combinaison des types de configurations de délégation Je mentionne ci-dessus et la matrice que ce script génère vous donnera un coup d'œil clair sur ce que vous avez actuellement configuré.

Enfin, si vous voulez de l'aide avec les commandes AD PowerShell, Cet article fait un travail suffisant décent de montrer la syntaxe appropriée lors de la définition de certaines des propriétés dont j'ai parlé avec des listes de SPNS, etc.

Si vous avez des questions, veuillez poster un commentaire et je ferai de mon mieux pour répondre rapidement.