et, comme nous voulions

établir un domaine pour tout le monde, il fallait éviter que les

administrateurs ne puissent interférer entre eux. Notre solution a donc
consisté à  restreindre l’accès aux DC. Malheureusement, les autorisations

accordées en utilisant la Default Domain Controller Policy s’appliquent à 
chaque DC.

   Nous avons donc décidé de créer – sous le dossier Domain

Controller – un dossier OU pour chaque groupe administratif, puis d’enlever

les DC respectifs de l’OU des Domain Controllers pour les mettre dans les

sous-OU AU1 et AU2. A partir de ces sous-dossiers, nous pouvions lier

certains GPO à  certains sous-OU. Et donc, nous pouvions attribuer des
droits d’utilisateurs spécifiques aux seuls DC d’un groupe administratif
donné. Nous avons octroyé aux administrateurs les droits suivants :

– sauvegarder les fichiers et les répertoires

– changer l’heure du système

– créer un pagefile

– charger et décharger des drivers de périphériques

– se connecter (log on) localement

– restaurer les fichiers et les répertoires

– arrêter le système

  Les autres tâches, comme la modification de fichiers système

ou l’installation de services sur des DC, sont interdites aux

administrateurs locaux. N’oublions pas que certains groupes ou comptes

doivent conserver certains droits d’utilisateurs (ainsi, un compte de

service de sauvegarde doit avoir le droit de restaurer des fichiers
et des dossiers de fichiers) et d’autres ont hérité de certains droits
provenant d’un niveau de GPO différent (le niveau domaine, par exemple).
Il faut donc ajouter manuellement de tels comptes au Group Policies

définis. Le tableau 2 présente une liste des droits d’utilisateurs par

défaut sur des DC. Il faut bien sûr garder une trace de toutes les

modifications. Certains services (comme Microsoft Exchange Server)

requièrent également des droits d’utilisateurs sur les DC.