Définir un mode de délégation centralisé

d’autres, sans les rendre pour autant
administrateurs de la totalité du domaine.
De plus, quiconque a le droit
Change permissions sur un objet peut
accorder ou retirer des permissions
pour cet objet à  toute autre personne
de son choix. Pour prolonger
l’exemple vu ci-dessus, je pourrais faire
toute confiance à  Chip pour gérer l’OU
New York (par exemple pour créer et
supprimer des objets, maintenir des
membres du groupe), mais je peux ne
pas vouloir qu’il étende ce niveau d’autorité
à  d’autres. Je pourrais aussi vouloir
l’empêcher de supprimer d’éventuels
droits que j’aurais accordés à 
d’autres. Mais, s’il a le droit Change
permissions sur son OU New York, il
peut faire ces deux choses. Il pourrait
laisser l’employé du courrier supprimer
des comptes dans l’OU, et il pourrait
ôter aux membres du groupe Help
Desk central la possibilité de redéfinir des mots de passe dans l’OU.
L’administration de délégation, si elle
est mal pensée, n’offre pas un environnement
sécurisé parce que le coeur
d’une bonne sécurité est un modèle de
sécurité défini centralement et appliqué
de façon homogène. Toutefois,
vous pouvez encore donner aux administrateurs
niveau OU une possibilité
limitée de déléguer leur autorité sans
mettre la pagaille dans votre modèle
de délégation déterminé centralement.

Vous commencez à  développer
votre modèle de délégation en définissant
centralement chaque rôle délégué
(OU Manager, User Account Manager,
Computer Account Manager, par
exemple). Vous attribuez ensuite à  chacun
de ces rôles un ensemble de permissions
spécifique, que vous devez
documenter au début et modifier
au fur et à  mesure que les besoins changent. Testez ces rôles au labo, puis
déployez-les dans une phase pilote OU
New York par exemple. Si vos rôles
fonctionnent bien là , ils fonctionneront
partout ailleurs.