Comment actualiser le groupe de sécurité AD sur les autorisations du serveur SQL

12

J'utilise Sql Server 2008 sur Small Business Server 2003; le client utilise WinXP.

J'ai ajouté un utilisateur à mon groupe de sécurité Active Directory; Pourquoi cet utilisateur ne peut-il pas accéder immédiatement à la base de données? Il semble qu'il y ait un délai avant que l'utilisateur ne soit reconnu dans Sql Server.

J'utilise des groupes de sécurité AD pour les autorisations expressément afin de ne pas avoir besoin d'ajouter des utilisateurs individuels dans Sql Server. Donc, efficacement, je n'ai rien d'autre à faire que d'ajouter l'utilisateur au groupe de sécurité AD pour accorder l'accès.

Mais pour une raison quelconque, Sql Server ne reconnaît pas immédiatement l'ajout. Je l'ai vu plusieurs fois. J'ajoute l'utilisateur au groupe mais cet utilisateur ne peut pas accéder aux données avant le lendemain. Il semble qu'il n'interroge pas Active Directory en temps réel. Pouvez-vous confirmer qu'il en est ainsi?

Que dois-je faire pour que Sql Server "actualise" la liste des utilisateurs d'Active Directory?

sql-server-2008 permissions active-directory

— D_Bester
source

Dans SQL Server 2008 Management Studio, j'ai ajouté une connexion au serveur à l'aide du groupe de sécurité et dans la base de données, j'ai créé un utilisateur mappé à cette connexion. Cela fonctionne très bien!

— D_Bester

Cependant, après avoir ajouté un nouvel utilisateur au groupe de sécurité, il n'a pas pu accéder à la base de données spécifiée. Cet utilisateur a accès au serveur à l'aide d'un autre groupe, donc le simple test de la connexion au serveur SQL a bien fonctionné. J'étais en train d'ajouter une connexion à Sql Server pour l'utilisateur (sur son ordinateur). Quand j'ai spécifié la base de données que je voulais, elle a dit que la base de données n'était pas disponible.

— D_Bester

Vérification ponctuelle de divers contrôleurs de domaine Je constate que la réplication est en effet terminée après 15 minutes, mais SQL ignore le nouvel utilisateur du groupe AD. Le redémarrage de SQL Server résout le problème, tout comme l'attente 24 heures. Ça doit être une meilleure façon.

— Aaron Auseth

12

L'utilisateur doit se déconnecter de son poste de travail et se reconnecter. C'est pourquoi les modifications semblent prendre effet le lendemain. La raison en est que lorsque l'utilisateur se connecte le lendemain, il obtient un nouveau jeton du contrôleur de domaine et ce jeton contient la liste des groupes de domaine dont il est membre. Ce jeton avec la liste des groupes de domaines n'est mis à jour que lorsque l'utilisateur se connecte à son ordinateur, donc si l'utilisateur ne se déconnecte jamais, le jeton n'est jamais mis à jour.

Il existe également des retards de réplication de domaine multisite qui doivent être pris en compte si vos contrôleurs de domaine sont dans des emplacements physiques différents.

— mrdenny
source

1

Existe-t-il une commande ou un script que l'on peut exécuter sur le poste de travail pour «actualiser» son jeton AD afin qu'il puisse «savoir» que l'utilisateur est maintenant membre du nouveau groupe de domaines et éviter ainsi le retard? --Update: semble qu'une personne a recommandé klist purgeà dba.stackexchange.com/a/44922/29371 , mais avec la mise en garde qu'il pourrait casser d'autres accesseurs de ressources mis en cache que l'utilisateur devrait rétablir / reconnecter.

— NateJ

@mrdenny Des recommandations sur la façon de gérer cela pour les comptes de service? Nous exécutons toutes les instances SQL sous des comptes de service et utilisons ces comptes de service pour les connexions entre les serveurs SQL et SSRS, etc. À tout moment, nous avons de nombreuses connexions entre les machines. Nous ne pouvons pas vraiment déconnecter toutes les connexions et effectuer une nouvelle connexion quelque part pour obtenir de nouvelles informations sur le groupe AD.

— SomeGuy

Pour les comptes de service, tout ce que vous pouvez faire, c'est redémarrer le service sur la machine qui a besoin des nouveaux droits.

— mrdenny

5

Lorsqu'un utilisateur ouvre une session, un jeton de sécurité lui est attribué qui inclut toutes les informations sur son appartenance au groupe.

Ce jeton persiste jusqu'à ce que l'utilisateur se déconnecte - moment auquel il est supprimé - même si vous apportez des modifications à l'appartenance au groupe dans AD entre-temps. Les modifications que vous apportez ne prendront effet que la prochaine fois que l'utilisateur se connectera et recevra un nouveau jeton de sécurité.

Vous pouvez reproduire le même scénario lors de l'attribution d'autorisations sur un système de fichiers, par exemple; c'est un comportement AD, pas un comportement SQL Server.

— Jon Seigel
source

1

Donc, vous obtenez des résultats immédiats serait d'obtenir de nouvelles informations d'identification à chaque fois en exécutant un cmd / script comme:

runas /netonly /user:domain\username "sqlcmd -S serverName -d dbname -q \"insert into testpermissions values (65)\""

en utilisant cmd.exe (pas PowerShell, je n'ai pas pu obtenir la citation correcte).

De cette façon, vous obtiendrez un nouveau jeton à chaque fois (mais vous devrez entrer votre pwd). Vous pourriez probablement faire quelque chose avec un mot de passe enregistré aussi, si les choses étaient trop onéreuses.

Quoi qu'il en soit, ça marche pour moi et j'espère que ça aide quelqu'un d'autre.

— Karl
source