EtcSecBeta
🏢Active DirectoryPrivileged AccessConfigMonitoringPermissions

Durcissement Active Directory : quoi verrouiller d’abord et comment le valider

Un guide centré sur les priorités pour le durcissement d’Active Directory : accès privilégiés, durcissement des protocoles, secrets réutilisables, exposition du plan de contrôle et validation post-changement.

Younes AZABARBy Younes AZABAR14 min read
Durcissement Active Directory : quoi verrouiller d’abord et comment le valider

Le durcissement Active Directory n’est ni un simple projet GPO ni une checklist à exécuter une fois. Un plan utile de durcissement d’Active Directory réduit le nombre de chemins privilégiés, retire les protocoles faibles et les secrets réutilisables, puis prouve que les contrôles tiennent encore après déploiement. Si vous avez d’abord besoin du workflow de revue global, commencez par Audit de sécurité Active Directory : quoi vérifier d’abord et comment prouver la remédiation. Cet article est plus étroit : il traite de ce qu’il faut verrouiller en premier.

Ce que le durcissement Active Directory signifie réellement

En pratique, le durcissement d’Active Directory consiste à réduire le nombre de façons dont un attaquant peut atteindre le contrôle privilégié, puis à protéger et surveiller les chemins d’administration qui restent. La stratégie Microsoft sur les accès privilégiés traite explicitement les accès privilégiés comme la priorité de sécurité la plus élevée et recommande de limiter les actions privilégiées à un petit nombre de voies autorisées, ensuite étroitement protégées et surveillées.

C’est pourquoi un bon travail de durcissement doit être ordonné. Si vous commencez par un tuning de baseline cosmétique avant de séparer les identités privilégiées, de durcir les postes d’administration et de supprimer les secrets réutilisables, le plan de contrôle peut rester facile à atteindre. Le Guide ANSSI Active Directory : appliquer les recommandations de sécurité en pratique arrive à la même conclusion opérationnelle par un autre angle : compartimenter d’abord le modèle d’administration, puis durcir les contrôles qui le soutiennent.

Le durcissement d’Active Directory commence par les accès privilégiés et les chemins d’administration

La première priorité est l’accès privilégié, non parce que c’est un thème à la mode, mais parce que la compromission des comptes et chemins privilégiés fait souvent tomber le reste du modèle de sécurité de l’annuaire. Le guide Microsoft sur les hôtes d’administration sécurisés est explicite : il ne faut jamais administrer un système de confiance depuis un hôte moins fiable, et les hôtes d’administration dédiés ne doivent pas exécuter les logiciels usuels des utilisateurs comme l’email, les navigateurs web ou les suites bureautiques.

Cela donne la première séquence de durcissement :

  1. Séparer les comptes privilégiés des identités du quotidien.
  2. Déplacer l’administration privilégiée vers des postes dédiés, des jump hosts ou des hôtes d’administration sécurisés équivalents.
  3. Restreindre les emplacements où les identités hautement privilégiées peuvent s’authentifier.
  4. Mesurer si des sessions privilégiées existent encore depuis des postes utilisateurs ordinaires.

C’est aussi à cet endroit que s’inscrivent des contrôles comme le groupe de sécurité Protected Users et les Authentication Policies / Authentication Policy Silos. Ce sont des contrôles de confinement utiles pour les bons comptes, mais pas des réglages universels à activer d’emblée. Microsoft documente des caveats importants : les membres de Protected Users doivent pouvoir s’authentifier en AES, les comptes de service et les comptes machine ne doivent pas être ajoutés, et les comptes très privilégiés ne doivent pas être ajoutés tant que l’impact opérationnel n’a pas été validé. Les authentication policy silos peuvent aller plus loin en limitant les hôtes sur lesquels certains comptes utilisateurs, machines et services hautement privilégiés sont autorisés à s’authentifier, ce qui les rend utiles une fois les tiers et les chemins d’administration déjà définis.

Réduire ensuite l’exposition protocolaire et annuaire

Une fois les chemins privilégiés resserrés, l’étape suivante du durcissement d’Active Directory consiste à réduire l’exposition protocolaire qui permet encore l’interception, l’altération du trafic ou le maintien d’habitudes d’administration faibles.

LDAP signing et channel binding

Microsoft documente LDAP signing et LDAP channel binding comme des protections du trafic LDAP AD DS. LDAP signing aide à vérifier l’authenticité et l’intégrité, tandis que le channel binding relie la couche applicative à la session TLS sous-jacente pour aider à empêcher le détournement et les scénarios de type man-in-the-middle. En pratique, cela signifie qu’un plan de durcissement sérieux doit vérifier si des liaisons SASL non signées ou des usages LDAP faibles restent tolérés par les contrôleurs de domaine.

L’erreur classique consiste à forcer le paramètre à l’aveugle. Avant de le durcir, il faut valider quelles applications, appliances, scripts ou middlewares legacy dépendent encore d’un comportement LDAP faible. Ensuite, il faut conserver la preuve de cette revue de compatibilité et de l’état final appliqué. Le deep dive associé reste en anglais : LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

SMB signing

Le guidage Microsoft sur SMB signing est tout aussi utile comme contrôle de durcissement, car il protège l’intégrité des messages et aide à se défendre contre les attaques par relay et usurpation. Exiger SMB signing sur les chemins d’administration et de gestion de fichiers à haute valeur est souvent un contrôle à traiter tôt.

Là encore, l’ordre d’application compte. Microsoft note que des problèmes de compatibilité peuvent apparaître lorsque l’on impose la signature dans des environnements utilisant des serveurs de fichiers non Microsoft. Le bon mouvement n’est donc pas « l’activer partout immédiatement », mais « mesurer où le SMB non signé subsiste encore, valider les dépendances, puis imposer avec preuve ». Le deep dive associé est Signature SMB désactivée : pourquoi cela permet encore le NTLM relay.

Le durcissement d’Active Directory passe par la réduction des secrets réutilisables

De nombreuses intrusions AD s’accélèrent encore parce que les secrets réutilisables restent trop faciles à voler, rejouer ou réutiliser latéralement. C’est la troisième priorité parce qu’elle limite souvent jusqu’où une compromission d’hôte unique peut se propager.

Windows LAPS

Microsoft documente Windows LAPS comme la fonctionnalité intégrée qui gère et sauvegarde automatiquement les mots de passe des comptes administrateur locaux, et qui peut aussi gérer le mot de passe DSRM sur les contrôleurs de domaine Windows Server Active Directory. Cela en fait un contrôle de durcissement central, pas une simple commodité. Si les mots de passe admin locaux ou DSRM restent statiques, partagés ou tournés manuellement, l’environnement conserve un risque latéral évitable.

L’objectif n’est pas seulement le déploiement. Il faut valider la rotation des mots de passe, les permissions de récupération, la cible de sauvegarde et les exceptions qui laissent encore une partie du parc hors contrôle. Deep dive associé : Windows LAPS non déployé : pourquoi les mots de passe admin locaux partagés comptent encore.

Mots de passe des comptes de service et gMSA

Le guidage Microsoft sur les group Managed Service Accounts est précieux parce qu’il réduit la charge administrative liée à la gestion des mots de passe des comptes de service et simplifie la gestion des SPN. Lorsque le support applicatif le permet, passer de comptes de service adossés à des utilisateurs traditionnels vers des gMSA supprime une classe de mots de passe de longue durée gérés manuellement.

Ce n’est pas un ordre de migration universel. Il faut valider le support applicatif, le comportement des clusters ou fermes, les dépendances SPN et l’ownership opérationnel avant conversion. Pour les comptes qui ne peuvent pas encore migrer vers des gMSA, il faut réduire l’ancienneté des mots de passe, retirer les privilèges inutiles et vérifier si le compte est toujours le bon principal pour le service.

Durcissement ciblé des politiques de mot de passe

Le guidage Microsoft sur les fine-grained password policies est utile ici, mais seulement au bon endroit. Les fine-grained password policies s’appliquent aux objets utilisateurs et aux groupes de sécurité globaux, pas comme remplacement universel de la gouvernance générale des mots de passe. Utilisez-les lorsque vous avez besoin d’un traitement plus strict pour certaines populations de comptes administratifs ou de service, et non comme substitut à une meilleure hygiène globale des identifiants. Pour la couche de contrôle de mot de passe adjacente, le deep dive reste en anglais : Active Directory Password Security: Misconfigurations That Matter.

Limiter la délégation et les autres chemins d’escalade

La quatrième priorité est le plan de contrôle autour de l’annuaire lui-même : permissions déléguées, contrôle des groupes privilégiés, administration des GPO et droits liés à la réplication qui ne devraient pas rester largement accessibles.

La documentation Microsoft sur Group Policy rappelle qu’une GPO n’est pas juste « un paramètre ». Elle possède une composante AD et une composante système de fichiers, et elle s’applique via la logique normale de scope de l’annuaire. C’est pourquoi les permissions GPO et la portée des liaisons doivent faire partie du durcissement, pas seulement du troubleshooting. Si des utilisateurs peu privilégiés peuvent influencer une GPO qui touche des systèmes privilégiés, le programme de durcissement a une faille structurelle. L’article adjacent reste en anglais : GPO Misconfigurations: How Group Policy Becomes an Attack Vector.

La même logique vaut pour les permissions liées à la réplication. Microsoft documente Replicating Directory Changes comme une ACE présente sur chaque partition de nommage de domaine et pouvant être explicitement accordée à des comptes. Cela signifie qu’un accès capable de réplication doit être traité comme un accès privilégié et revu explicitement, pas considéré comme anodin au seul motif qu’il ne s’appelle pas « Domain Admin ». Le problème plus large des chaînes d’abus est couvert dans Chemins d’attaque AD : comment les mauvaises configurations s’enchaînent jusqu’à Domain Admin.

Si AD CS est déployé, il faut l’ajouter au même programme de durcissement. Microsoft documente AD CS comme le rôle Windows Server qui émet et gère des certificats utilisés pour la communication sécurisée et l’authentification. Autrement dit, si l’authentification par certificat existe dans l’environnement, durcir l’annuaire en ignorant le plan de contrôle des certificats laisse un écart réel. Gardez un périmètre conditionnel : si AD CS n’est pas déployé, inutile de le forcer dans le programme. S’il est présent, relisez Attaques ADCS : comment des erreurs de certificats deviennent des chemins d’escalade Active Directory.

Intégrer la journalisation et la validation dans le plan de durcissement

Un durcissement qui ne peut pas être remesuré retombe vite dans la supposition. Les recommandations Microsoft sur les audit policies et la collecte d’événements montrent clairement le point opérationnel : il faut d’abord les bons réglages d’audit, puis le bon chemin de collecte et de rétention.

Windows Event Forwarding et Windows Event Collector peuvent centraliser les événements que vous choisissez d’acheminer, mais ils ne remplacent pas la conception de la politique d’audit. La télémétrie sur les changements d’objets annuaire n’est utile que si les réglages d’audit nécessaires et la bonne couverture SACL existent. Par exemple, Microsoft documente que l’Event 5136 est généré lorsqu’un objet d’annuaire est modifié, mais seulement si l’objet possède l’entrée SACL pertinente pour l’action d’écriture auditée.

Cela conduit à une règle pratique pour les programmes de durcissement :

  • conserver des exports avant et après changement pour la composition des groupes privilégiés, l’état des GPO, l’état des politiques LDAP et SMB, ainsi que les permissions déléguées
  • vérifier que les contrôleurs de domaine et les systèmes d’administration journalisent bien les événements sur lesquels vous comptez réellement vous appuyer
  • traiter WEF/WEC comme une infrastructure de transport et de rétention, pas comme la preuve que la conception d’audit est complète

Pour la couche de visibilité événementielle, utilisez Supervision de la sécurité AD : les événements qui comptent vraiment et Audit Active Directory récurrent : pourquoi les audits annuels dérivent et comment recontrôler dans le temps.

Matrice des priorités de durcissement d’Active Directory

Domaine de contrôlePourquoi cela vient tôtCe qu’il faut valider avant mise en applicationCe qu’il faut conserver comme preuve après déploiement
Comptes privilégiés et hôtes d’administrationLa compromission d’un chemin privilégié fait souvent tomber le reste du modèle d’annuaire en premierHôtes d’administration dédiés, identités admin séparées, chemins d’authentification autorisés, impact de Protected Users et des authentication silosInventaire des hôtes d’administration, périmètre des comptes privilégiés, affectation des politiques, validation des chemins de connexion
LDAP signing et SMB signingLes protocoles faibles laissent survivre relay, altération du trafic et workflows d’administration peu sûrsApplications legacy, appliances, scripts, serveurs de fichiers non Microsoft, dépendances TLS et LDAPÉtat effectif des politiques, registre des exceptions, résultats de tests de compatibilité
Secrets des admins locaux, DSRM et comptes de serviceLes secrets réutilisables accélèrent mouvement latéral et persistanceCouverture Windows LAPS, gestion DSRM, support gMSA, ownership des comptes de service, dépendances de rotation de mot de passePreuves de rotation, rapports de couverture LAPS, revue des ACL de récupération, traces de migration des services
Permissions déléguées, contrôle GPO et accès liés à la réplicationL’abus du plan de contrôle contourne souvent la vision centrée sur les groupes admins nommésPermissions GPO, délégations d’OU, droits capables de réplication, gouvernance des groupes privilégiés, présence d’AD CS si déployéRevue de permissions avant/après, diff GPO, inventaire des admins délégués, traces d’approbation
Politique d’audit et workflow de validationSans visibilité, le durcissement ne peut ni être remesuré ni être défendu dans le tempsCouverture d’audit, design des SACL, routage WEF/WEC, rétention, ownership des alertesÉchantillons d’événements avant/après changement, santé des collecteurs, preuves conservées pour les reruns

Si AD CS est présent, incluez l’exposition des certificate templates, la configuration de l’AC et les enrollment endpoints dans cette même matrice sous forme de ligne conditionnelle plutôt que comme futur projet séparé.

Validation après les changements de durcissement

Un programme de durcissement n’est terminé que lorsque les contrôles fonctionnent encore dans des conditions de production. Des preuves de validation utiles incluent :

  1. La preuve que l’administration privilégiée ne part plus que d’hôtes approuvés ou de jump paths définis.
  2. La preuve que les clients LDAP fonctionnent encore avec la posture cible sur LDAP signing et channel binding.
  3. La preuve que les workflows d’administration et de fichiers SMB fonctionnent encore avec les exigences de signature prévues.
  4. La preuve que Windows LAPS fait bien tourner les secrets admin locaux et DSRM et que les droits de récupération sont strictement limités.
  5. La preuve que les migrations de comptes de service vers des gMSA ou vers une gestion plus stricte n’ont pas laissé de SPN cassés ni d’exceptions non gérées.
  6. La preuve que les permissions déléguées, les droits liés à la réplication et les chemins de contrôle GPO ont été revus avant et après changement.
  7. La preuve que la politique d’audit et la chaîne de collecte capturent bien les contrôles sur lesquels vous comptez réellement.

C’est aussi pour cela que ce pillar se place à côté du pillar audit, et non au-dessus. La question hardening est « qu’est-ce qu’on verrouille d’abord ? ». La question audit est « qu’est-ce qu’on revoit régulièrement, et comment prouve-t-on la dérive ou la remédiation dans le temps ? ». Les deux comptent, mais ce ne sont pas le même workflow.

Comment EtcSec aide à des revues AD de durcissement répétables

EtcSec s’insère ici comme couche de mesure répétable, pas comme raccourci qui remplace le travail de durcissement. Un collecteur local en lecture seule peut aider à remesurer l’étalement des comptes privilégiés, les permissions capables de réplication, l’exposition LDAP signing, l’exposition SMB signing et la couverture Windows LAPS après chaque vague de changement. C’est utile quand il faut vérifier qu’une décision de durcissement a réellement réduit l’exposition, au lieu d’avoir seulement modifié un paramètre de politique sur le papier.

Références principales