Sécurité Active Directory : gestion des GPO sur l’OU Domain Controllers
Sommaire
I. Présentation
Dans ce tutoriel, nous allons parler des bonnes pratiques sur l’utilisation des GPOs au niveau des contrôleurs de domaine. Comme nous le savons tous, les GPOs permettent d’appliquer les paramètres de manière automatique sur les objets de l’annuaire. Une mauvaise gestion peut impacter le fonctionnement de notre infrastructure et mettre en péril sa sécurité. Nous allons voir ensemble comment éviter cela sur les contrôleurs du domaine qui jouent un rôle très important dans un environnement Microsoft.
Cet article a été écrit en collaboration avec Mehdi DAKHAMA, et c'est un retour d'expérience relevé chez plusieurs clients. Le but est d'améliorer et optimiser la gestion des GPOs pour les contrôleurs de domaine.
Relecture par Florian BURNEL.
II. Rappel sur l’application des GPOs
A. Hiérarchie d’application des mises à jour
Pour rappel, la hiérarchie d’application des OU est la suivante: stratégie locale > site >> domaine >> OU. Dans la hiérarchie précédente, le symbole ">>" signifie que l'héritage est appliqué.
Deux stratégies de groupes sont créées par défaut lors de l’installation du domaine :
- Default Domain Policy liée à la racine du domaine
- Default Domain Controller Policy liée sur l’OU "Domains Controllers"
B. Risques potentiels
Au vu de la hiérarchie présentée ci-dessus, nous constatons que si une GPO est appliquée au niveau du site ou à la racine d’un domaine, elle sera aussi appliquée aux contrôleurs de domaine via le conteneur "Domain controllers".
Est-ce une bonne ou une mauvaise pratique ? Voyons cela ensemble.
Intéressons-nous aux deux scénarios suivant:
- Une première GPO machine est créée et liée à la racine du domaine
- Une seconde GPO liée à une unité d’organisation comprenant un compte administrateur du domaine
C. Exemple n°1 - GPO liée à la racine
Nous allons créer une GPO qui désactive l’UAC (User Account Control) sur Windows. Vous savez, l'UAC c'est la fenêtre de confirmation qui s'affiche quand on a besoin de réaliser une action qui implique des privilèges élevés (administrateur).
Pour cela, nous créons une GPO à la racine du domaine en la nommant "Disabled UAC", nous allons ensuite la modifier via un clic droit "Modifier".
Dans la partie Configuration Ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Contrôle de compte d’utilisateur nous avons modifié le paramètre "Contrôle de compte d'utilisateur : comportement de l'invite d'élévation pour les administrateurs en mode d'approbation Administrateur", comme indiqué sur les images ci-dessous :
Une fois que c'est fait, nous appliquons la GPO avec la commande gpupdate /force sur le contrôleur de domaine Active Directory. De par son positionnement, la GPO s'applique sur les contrôleurs de domaine et les autres machines du domaine.
Nous constatons que les paramètres ont été appliqués et changés sur le contrôleur du domaine.
Il est clair que ce paramètre est dangereux pour un contrôleur de domaine ! De ce fait, il faudrait éviter de lier les GPOs à la racine en vue de limiter les conséquences d’une telle action ! On peut considérer qu'il y a eu une mauvaise analyse de l'impact sur l’ensemble des objets concernés. Cependant, cette recommandation ne suffit pas, voyons pourquoi...
D. Exemple n°2 - GPO pour connecter un lecteur réseau
Réalisons le second exemple basé sur le mappage d'un lecteur réseau dans une session et analysons le résultat.
Sur l'OU IT-Connect, nous allons créer une GPO nommée "mapper_lecteur_user". Comme ceci :
Nous modifions les paramètres pour mapper un dossier partagé sur le DC comme lecteur perso "Z:". Ce qui donne :
Pour rappel, notre OU contient des admins du domaine :
Après application de la GPO, nous constatons que le lecteur réseau remonte lors de la connexion sur le contrôleur de domaine avec un compte de cette OU. En effet, les paramètres utilisateurs suivent l’utilisateur et s’appliquent là où ils ouvrent leur session.
Imaginez que ce lecteur contient un fichier suspect et que ce dernier correspond à un ransomware ?! Était-il nécessaire d’avoir ce lecteur réseau "Perso" lors d’une connexion sur le contrôleur du domaine ? Ce cas peut s’appliquer sur plein de paramètres des GPOs, parfois un paramètre s’applique par récursivité à un groupe lointain, ce qui accroît le risque de dysfonctionnement ou d’erreur sur les DCs.
Maintenant, intéressons-nous aux recommandations.
III. Recommandations pour l'OU "Domain Controllers"
L'objectif va être de bloquer l'héritage sur l'OU "Domain Controllers" de notre annuaire Active Directory pour isoler, en quelque sorte, les contrôleurs de domaine puisqu'ils sont regroupés dans cette OU. De plus, pour mieux contrôler les paramètres utilisateurs qui s’appliquent sur les contrôleurs de domaine, il faudrait que les paramètres utilisateurs liés aux GPO liés à l’OU "Domains Controllers" prennent précédence sur le reste. Microsoft a prévu cette configuration : le traitement par boucle de rappel.
Le schéma ci-dessous résume les étapes :
Nos recommandations sont les suivantes:
- Recommandation n°1 : bloquer l'héritage sur l’OU "Domain Controllers" : cela permettra d'éviter toutes configurations issues de la racine. Pour empêcher l’application des configurations utilisateurs des administrateurs qui se connectent, cette recommandation doit être effectuée
- Recommandation n°2 : dupliquer la GPO "Default Domain Policy" et l’appliquer sur l’OU "Domain Controllers" : dans le but de conserver et d’appliquer les paramètres de mot de passe et Kerberos
Pour bloquer l'héritage, effectuer un clique droit sur l’OU "Domain Controllers", et choisissez "Bloquer l'héritage".
Ce qui donne :
Note : attention si vous "Appliqué" (Enforced en anglais) une GPO à la racine, cela forcera l’héritage et les paramètres seront configurés sur les Contrôleurs de domaine. Malheureusement, ce paramètre est trop souvent utilisé à mauvais escient.
- Recommandation n°3 : activer le traitement par boucle de rappel
Pour configurer ce paramètre, suivez le chemin suivant dans une nouvelle GPO : Configuration de l'ordinateur > Modèles d'administration > Système > Stratégie de groupe
Ici, choisissez le paramètre nommé "Configurez le mode de traitement par bouclage de la stratégie de groupe utilisateur" et cochez "Activé" ainsi que "Remplacer".
- Recommandation n°4 : renommer les GPOs appliquées sur les contrôleurs de domaine
Nous devons partir du principe que les GPOs appliqués sur l’OU "Domain Controllers" ne doivent pas être utilisées sur une autre OU. Pour les identifier, il convient d'utiliser un nom différent en respectant une nomenclature spécifique pour vos contrôleurs de domaine. Ainsi, pour une même GPO, vous pouvez faire la différence entre la version qui s'applique aux ordinateurs et autres serveurs, et la version pour les contrôleurs de domaine.
Pour en savoir plus sur ces différentes notions, vous pouvez consulter ces pages :
- GPO - Traitement par boucle de rappel
- Les stratégies de groupe et l’option « Appliqué » (Enforced)
- LinkedIn Learning - Désactiver l'héritage GPO
IV. Conclusion
Les contrôleurs de domaine doivent être extrêmement protégés, le blocage de l'héritage et des paramètres utilisateurs constituent une solution. A cela doit s’accompagner la surveillance, ce sera le focus de notre prochain article.
