Bonjour à tous,

L'une des questions les plus fréquemment posée sur les newsgroups et forums Microsoft  reste la problématique des droits utilisateurs et ceux du service IT. 

Si dans une société de taille moyenne, on voit souvent un à trois administrateurs de l'AD disposant chacun d'un compte membre du groupe "Admins. du domaine" (ou pire utilisant tous le même compte administrateur) ; lorsque le service s'étoffe, ou que des utilisateurs sont sensibilisés et doivent pouvoir avoir un certain nombre de pouvoirs sur l'AD, la question de la délégation se pose. Il est bien sur hors de question de donner un compte admin de domaine à toute la terre. C'est à ce moment que l'idée de "délégation"  d'administration entre en piste.

Comme vous le savez tous déjà, on peut parfaitement mettre des droits sur un objet AD, comme on le fait sur un dossier ou un fichier. C'est par ce moyen que l'on va travailler les OU (par assistant ou directement par l'onglet Sécurité) et les façonner de la manière souhaitée.

Avant de se lancer dans la technique, la première chose à faire est de définir les besoins. Suivant l'ampleur de votre infra, deux possibilités au moins s'offrent à vous.

  • définir X niveaux d'administration par groupe

  • plus modulaire (mais plus long!) définir une suite de tâches primaires par groupe, créer ensuite des profils d'administration imbriqués dans chaque groupe "primaire"

1- Délégation par groupes primaires

Qui peut le plus, peut le moins ; analysons l'idée de groupes primaires. L'idée derrière tout ça est donc de définir une succession de groupes mono tâches, sur le domaine ou sur chaque OU, et d'y associer les droits associés. On pourra citer en exemple :

  • lecture du contenu de l'OU

  • Création d'OU

  • Réinitialisation de mots de passe utilisateurs

  • Modification de X attributs de comptes utilisateurs

  • Création et suppression de comptes utilisateurs

  • Création et suppression de groupes

  • Création et suppression de compte ordinateurs type postes de travail

  • Création et suppression de comptes ordinateurs type serveurs

  • connexion à un serveur Terminal Serveur

  • Création de GPO

  • Liaison de GPO à une OU

  • ...

Il existe environ 10.000 droits sur un objet AD classique donc niveau choix, vous avez de la marge :)

Le choix des groupes à définir dépends entièrement des besoins de votre organisation et de sa structure. Vous pouvez par exemple décider que les groupes primaires doivent avoir pour portée le domaine, une OU ou même une arborescence d'OUs définissant un site, une région, une agence ou autre...  La définition de la matrice des droits vous appartient et aucun consultant ne pourra vous apporter LA solution miracle si ce n'est par un retour d'expérience chez une société d'activité équivalente.... ce qui ne signifie pas que la solution vous convienne!

Une fois cette -longue- étape définie et validée, vous n'aurez plus qu'à créer des groupes faisant partie de X ou Y groupes primaires et la moitié du travail sera faite.

2- Autorisations sur les objets

Reste donc à travailler sur les OU afin d'octroyer aux groupes primaires ce qu'ils clament pouvoir obtenir. Deux manières de travailler :
  • passer par l'assistant (clique droit sur l'OU et déléguer le contrôle) puis vous laisser guider. L'assistant propose des tâches préfaites (réinitialisation de mots de passe par exemple) et peut être étendu à un certain nombre de droits.

  • A l'ancienne, en allant dans l'onglet sécurité d'une OU, puis en sélectionnant "paramètres avancés" et en ajoutant des droits à chaque groupe primaire.

Illustrons la méthode n°2. Vous désirez déléguer le droit de créer des comptes utilisateurs au groupe de sécurité global primaire appelé "OU1-USRADD".

  • Dans utilisateurs et ordinateurs, commencez par afficher la vue avancée : menu affichage > fonctionnalités avancées.

  • Sélectionner ensuite l'OU pour laquelle déléguer cette tâche, puis clique droit et propriétés

  • Sélectionner l'onglet Sécurité puis paramètres avancer

  • Dans l'onglet Autorisations, faites ajouter et sélectionnez OU1-USRADD puis OK

  • Dans "appliquez à" sélectionnez le niveau d'arborescence à modifier, par exemple "Cet objet et ses sous objets" pour choisir toute l'arborescence située sous l'OU en question.

  • Dans la liste des permissions, cochez "créer des objets utilisateurs" et "supprimer des objets utilisateurs", cliquez deux fois sur OK

  • terminé :)

Répétez ces étapes pour chaque groupe primaire et / ou chaque OU afin de terminer le modèle.

3- Du script, du script!

J'en entends déjà grogner qu'ils ont défini sur papier 30 groupes utilisateurs pour chacune des 500 OU de leur arborescence, et que si les créer en masse ne posera pas trop de problème grâce à ce qu'ils ont trouvé sur scriptcenter, le côté droits sur des objets AD est une autre histoire. C'est vrai... mais pas autant qu'on peut le penser si vous connaissez dsacls.exe.

Dsacls est un outil en ligne de commande (donc scriptable!) permettant de modifier les ACL des objets de l'AD sous toutes les coutures : droits, indicateurs héritage ...

A noter que l'outil est sensible à la casse donc prudence lors de vos tests! Comme on l'a vu dans l'exemple plus haut, il faut donc positionner sur l'OU une succession de droits sur certains attributs des objets dont l'on veut déléguer le contrôle. Je ne résiste pas à copier-coller la métaphore utilisée sur Technet :


"La meilleure métaphore que j'ai entendue pour expliquer ce concept est le modèle du hamburger. Les hamburgers doivent contenir un steak haché et un petit pain pour être considérés comme des hamburgers. Ils s'agit là des attributs « doit contenir » de la classe d'objet Hamburger. Les éléments tels que les condiments, le ketchup, la laitue et autres correspondent aux attributs « peut contenir ». Si nous voulions étendre la classe d'objet afin de définir un cheeseburger, nous ajouterions du fromage à la liste des attributs « doit contenir »."

J'aime beaucoup l'idée de l'attribut ketchup :)

Quoi qu'il en soit on simplifiera donc toutes les étapes de délégation de création de comptes utilisateurs par cette ligne :

"dsacls ou=OU1,dc=domaine,dc=lan /I:T /G domaine\OU1-USRADD:CCDC;user "

Et oui, c'est tout :)
Commentons un peu la syntaxe :
dsacls : ouaip bon...
ou=OU1,dc=domaine,dc=lan : l'OU que l'on cible pour modification
/I:T : l'héritage (inheritance)de ce droit appliqué. T étant "transverse", c'est à dire le parent et les enfants
/G domaine\
OU1-USRADD:CCDC;user : /G précise le groupe, soit "domaine\OU1-USRADD". CC signifie "create child", DC signifie "delete child". le ";user" spécifie type d'objets impacté par dsacls.

Admettons que vous ayez créé un groupe OU1-USRMOD qui lui doit pouvoir lire et écrire TOUS les attributs, un coup de dsacls :
"dsacls ou=OU1,dc=domaine,dc=lan /I:S /G domaine\
OU1-USRADM:GRGW;;user" (Le GRGW signifit, vous l'aurez deviné Generic Read, Generic Write).

Nous avons donc mappés nos groupes primaires à l'OU. Soit un groupe secondaire OU1-USRADM membre de OU1-USRADD et OU1-USRMOD, celui-ci à donc les droits création/suppression + modifications des attributs des objets utilisateurs de l'OU OU1.
Vous commencez à voir l'idée maintenant?

Maintenant, pensez à un script permettant d'automatiser :
- la création d'une OU : OUab
- la création de ses sous-OU utilisateurs, groupes, postes de travail et serveurs :

  • "OU=users;OU" & OUab & "DC=domaine,DC=lan"
  • "OU=groups;OU" & OUab & "DC=domaine,DC=lan"
  • "OU=pdt;OU" & OUab & "DC=domaine,DC=lan"
  • "OU=servers;OU" & OUab & "DC=domaine,DC=lan"


- la création de groupes primaires pour les sous-OU de cette OU :

  • OUab & "-USRADD"
  • OUab & "-USRMOD"
  • OUab & "-GRPADD"
  • OUab & "-GRPMOD"
  • OUab & "-USRPWD"
  • OUab & "-PDTADD"
  • OUab & "-PDTADM"
  • OUab & "-SRVADD"
  • OUab & "-SRVADM"

- la modification en masse des sous-OU par dsacls, par exemple :
Return = owshshell.run("dsacls ou="OU=users;OU" & OUab & "DC=domaine,DC=lan /I:S /G domaine\" & OUab & "-USRADD:CCDC;user", 0, True)


- Maintenant, imaginez que vous demandez simplement le nom de l'OU par une malheureuse inputbox ou mieux, en argument.

Vous venez de refaire votre infra, félicitation :)

4- Conclusion

Comme on aura pu le lire ensemble, l'idée de déléguer l'administration, bien que brouillone au premier abord est finallement juste une affaire de bon sens. Si en plus on a quelques notions de VBS ou mieux, de powershell, l'automatisation de la création de la délégation est vraiment aisée... et quel confort après de ne plus avoir à passer par des outils tiers pour déléguer telle ou telle tâche d'administration (au hazard la reinitialisation des mots de passe).

D'un point de vue plus "architecte" la délégation d'administration vous permettra de plus d'obtenir une véritable harmonisation de votre domaine / votre forêt. Si vous respectez un schéma unique pour chaque infrastructure d'OU (ex: une infra par pays) vous gagnerez un temps fou pour toute modification et une flexibilité diabolique.