Comment attribuer un accès complet à la sécurité d'un groupe Active Directory dans SQL Server 2008?


40

Je souhaite utiliser la sécurité intégrée avec mon application interne, qui est entièrement sur un domaine. Malheureusement, je n'ai jamais réussi à faire en sorte que cela fonctionne bien. J'aimerais attribuer à un groupe Exchange (Active Directory) entier un rôle dans SQL Server pour un accès en lecture / écriture à certaines tables. De cette façon, je n'aurais pas à créer d'opérateur chaque fois qu'une personne est embauchée ni à supprimer un opérateur chaque fois qu'une personne est renvoyée. Est-ce possible? Quelles mesures prendrais-je pour le faire?

Réponses:


48
  • Définissez le groupe AD comme identifiant. Et "connexion" signifie une connexion au niveau du serveur et non le concept AD d'utilisateur / connexion. En langage SQL Server, il s’agit d’un principal de niveau serveur
  • Créez un utilisateur mappé dans. Vous ne devriez pas vraiment autoriser un utilisateur directement sur les tables. Et "utilisateur" signifie utilisateur de base de données et non le concept d'utilisateur AD: dans SQL Server, il s'agit d'un "principal de niveau base de données".
  • Ajouter un utilisateur à un rôle (également un "principal au niveau de la base de données")
  • Accordez des autorisations sur les rôles sur les tables (une table ou une procédure, etc. est une "sécurité")

Exemple de script

USE master;
GO
CREATE LOGIN [MYDOMAIN\APPLICATION SUPPORT] FROM WINDOWS;
GO
USE mydb;
GO
CREATE USER [MYDOMAIN\APPLICATION SUPPORT] FROM LOGIN [MYDOMAIN\APPLICATION SUPPORT];
GO
CREATE ROLE rSupport;
GO
EXEC sp_addrolemember 'rSupport', 'MYDOMAIN\APPLICATION SUPPORT';
GO
GRANT SELECT, INSERT,UPDATE, etc ON Mytable TO rSupport;
GO

sp_addrolememberest obsolète à partir de SQL Server 2012, où ALTER ROLEdoit être utilisé à la place.


3
Il serait utile d’expliquer pourquoi vous devez attribuer des autorisations à des rôles plutôt qu’à des utilisateurs SQL (dans ce cas, des groupes AD).
Drew Chapin

Vous voulez peut-être dire "créer un utilisateur [...] pour la connexion [...]", au lieu de "à partir de la connexion"?
Agostino

CREATE USER ... FOR LOGIN ...; et CREATE USER ... FROM LOGIN ...; les deux fonctionnent pour moi (MSSQL2016). Vous ne savez pas s'il y a une différence?
Ingénieur inversé


4

L'attribution d'autorisations dans SQL Server à un groupe AD est relativement simple. Cela peut être fait via T-SQL ou Management Studio.

Par exemple, si vous avez un groupe AD appelé MYDOMAIN\APPLICATION SUPPORT, vous devez créer une connexion au niveau du serveur, puis utiliser des mappages sur des bases de données individuelles pour donner des autorisations légèrement plus granulaires telles que le lecteur de données.

Idéalement, tous les accès aux applications doivent se faire par le biais de procédures stockées *. Par conséquent, seules les autorisations d'exécution sur les procédures stockées de cette base de données sont requises.

* Du point de vue de la sécurité, pour permettre à un utilisateur particulier de voir des données spécifiques, vous pouvez créer une procédure et lui accorder l’ autorisation d’ exécution , et rien d’autre. Permettre à l'utilisateur d'interroger directement signifie donner l' autorisation de sélectionner sur toutes les tables impliquées. Il est également plus facile de travailler avec des procédures et de déboguer.

Les procédures abstraites des procédures stockées accèdent à distance et limitent l’accès. Pour les types DBA, c'est comme "laissez-moi voir toutes vos variables d'instance: je ne veux pas utiliser de méthodes, de getters ou de setters".


3

De la réponse de marc_s "Comment ajouter un groupe d'utilisateurs Active Directory en tant que connexion dans SQL Server" :

Dans SQL Server Management Studio, allez à Object Explorer > (your server) > Security > Loginset cliquez-droit New Login:

entrez la description de l'image ici

Puis, dans la boîte de dialogue qui s’ouvre, choisissez les types d’objets que vous souhaitez voir ( Groupsdésactivé par défaut - cochez-le!), Choisissez l’emplacement où vous souhaitez rechercher vos objets (par exemple, utilisation Entire Directory), puis recherchez votre groupe AD. .

entrez la description de l'image ici

Vous avez maintenant une connexion SQL Server normale, comme lorsque vous en créez une pour un utilisateur AD unique. Donnez à cette nouvelle connexion les autorisations sur les bases de données dont elle a besoin, et c'est parti!

Tout membre de ce groupe AD peut maintenant se connecter à SQL Server et utiliser votre base de données.


2
Il est probablement utile de se lier à cette réponse SO, mais vous n’ajoutez rien de nouveau au message, n’est-ce pas. Vous auriez pu simplement poster le lien en tant que commentaire.
Andriy M

2
La réponse a une belle capture d'écran pour vérifier les groupes sous le type d'objet, puisque c'est ce qui me manquait lorsque j'essayais de le faire. Un lien ne le montre pas de manière aussi utile à mon avis. J'essaie juste d'aider la personne suivante ...
Même Mien

Que voulez-vous dire? Habituellement, un lien est présent pour le suivre, et toutes les personnes qui suivent le lien verront la belle capture d'écran dont vous parlez, ainsi que tout ce que vous avez posté à nouveau ici. Ne pas discuter, cependant, vous faire savoir que mon opinion n’a pas changé: un lien (dans un commentaire) ferait tout aussi bien l'affaire.
Andriy M

4
Mon opinion est également inchangée. Un lien dans un commentaire ne transmet pas les mêmes informations qu'une image réelle sur une page Web. "Montrez, ne dites pas."
Même Mien

1

Si l'utilisateur est membre d'un groupe DOMAIN \ SecurityGroup disposant de l'autorité Sysadmin en SQL, il sera utilisé lors de l'accès à des bases de données. Sinon, vous devez rechercher le (s) domaine (s) DOMAIN \ SecurityGroup (s) attribué (s) à une autorité dans chaque base de données. Si l'utilisateur est membre de 2 SecurityGroups, avec SecGroupA ayant une autorité de sélection et SecGroupB ayant une autorité d'insertion, l'utilisateur peut alors sélectionner et insérer.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.