Délégation d’AD : au-delà  du basique

A première vue, le modèle de délégation
d’AD paraît simple. Tout comme
vous pouvez attribuer des permissions
NTFS pour donner à  des utilisateurs
l’accès à  une portion du système de fichiers, vous pouvez écrire des ACE (access
control entries) dans AD pour accorder
(ou refuser) aux utilisateurs l’accès
à  une portion de votre répertoire.
Vous pouvez attribuer des droits à  certains
types d’objets (comptes d’ordinateurs,
par exemple) et pas à  d’autres
(comptes de groupes, par exemple)
dans le même conteneur. Vous pouvez
également accorder des droits à  un objet
entier pour que, par exemple, un administrateur
contrôle entièrement la totalité
d’un compte utilisateur. Mais vous
pouvez également sécuriser chaque attribut
d’objet individuellement. Vous
pourriez, par exemple, permettre aux
administrateurs de changer les numéros
de téléphone des utilisateurs mais pas
leurs mots de passe. Une fois que vous
comprendrez les règles, la conception
de votre modèle de délégation ira de soi.
En fait, vous voulez donner aux administrateurs
délégués des permissions de
lecture et d’écriture sur les portions de
leur forêt d’AD dont ils ont besoin pour
accomplir le travail – ni plus ni moins.

Tout d’abord, j’explique la délégation
des droits d’options Account – en
particulier, la possibilité de forcer les
changements de mot de passe –
comme une première en délégation
d’AD. Deuxièmement, j’examine la délégation
des droits de déplacer des objets
vers et à  partir d’OU (organizational
units) pour vous montrer comment
résoudre une limitation de délégation,
de manière efficace et sûre. Sur les
bases de ces discussions, je vous guide
dans la définition d’un modèle de délégation
centralisé.

Enfin, je passe du contexte de
nommage de domaine, dans lequel résident
les tâches de délégation évoquées
jusqu’à  ce point, dans un autre
contexte de nommage d’AD, le
contexte de nommage de configuration,
pour explorer la délégation de
gestion de site.