Je viens de faire des tests en jouant avec les sécurité des objets.
Dans ce scénario :
J'ai un utilisateur "toto", membre du groupe "admin du domaine".
"toto" est en accès refusé sur le groupe "test".
Lorsque "toto" parcours l'AD et qu'il veut lire les attributs du groupe "test", l'accès est refusé.
Ce scénario est viable.
Cependant, dans autre scénario (qui ressemble à mon cas) :
J'ai un utilisateur "toto", membre du groupe "admin_France". Le groupe "admin_France" est membre du groupe "admin du domaine".
"admin_France" est en accès refusé sur le groupe "test".
Lorsque "toto" (utilisateurs du groupe "admin_france" ) parcours l'AD et qu'il veut lire les attributs du groupe "test", l'accès est refusé.
Mais si "toto" est un peu malin, il s'ajoute directement dans le groupe "admin du domaine" et se supprime du groupe "admin_france" et que "toto" veut lire les attributs du groupe "test", l'accès est autorisé.
Ce scénario n'est pas viable.
Donc dans mon cas, je n'ai pas de solution moins invasive que celle proposé par splinter_five0
NOTE : si à la place de "toto" je prend le compte "builtin\administrateur", et que je lui mets un accès refusé sur le groupe "test", il n'aura pas accès aux attributs, cependant, la gestion de la sécurité reste possible. On ne peux pas se couper la branche sur laquelle on est assit.
Message édité par arnaudperfect le 15-02-2016 à 16:38:17