Quelles sont les mauvaises configurations de sécurité Active Directory les plus courantes ? 10 problèmes à corriger d’abord

Quand les équipes demandent quelles sont les mauvaises configurations de sécurité Active Directory les plus courantes, la bonne réponse n’est pas un classement de fréquence. C’est la liste des défaillances de contrôle qui reviennent sans cesse dans les guides de durcissement Microsoft, les recommandations ANSSI et les revues AD récurrentes, parce qu’elles laissent encore de vrais chemins d’élévation de privilèges, d’exposition de crédentials ou de perte de visibilité.

Cet article présente la vue misconfigurations d’Active Directory. Ce n’est pas une checklist d’audit complète comme Audit de sécurité Active Directory : checklist pratique, et ce n’est pas non plus un guide d’ordre de déploiement comme Durcissement Active Directory : quoi verrouiller d’abord et comment le valider. L’objectif est plus étroit : identifier les mauvaises configurations AD qui comptent encore le plus, expliquer pourquoi elles comptent, et montrer quoi valider avant et après correction.

Qu’est-ce qu’une mauvaise configuration de sécurité Active Directory ?

Une mauvaise configuration de sécurité Active Directory n’est pas simplement un paramètre qui diffère d’un benchmark. En pratique, c’est une faiblesse de contrôle qui laisse l’authentification, les privilèges, la réplication, l’administration ou la gestion des politiques plus larges que nécessaire pour l’environnement.

C’est pour cela que les mêmes familles de problèmes reviennent sans cesse : trop de comptes privilégiés, mauvaise séparation des chemins d’administration, droits de réplication trop larges, trafic annuaire non signé, secrets administrateur locaux réutilisables, comptes de service à mot de passe statique, paramètres de délégation risqués et contrôle Group Policy trop permissif. Ce sont des problèmes de configuration, mais ils deviennent des problèmes de chemins d’attaque quand ils restent en production.

Quelles sont les mauvaises configurations de sécurité Active Directory les plus courantes ?

ℹ️ Note : cette liste n’est pas un classement statistique global du marché. C’est un Top 10 pratique des familles de mauvaises configurations qui reviennent de façon récurrente dans les guides Microsoft, ANSSI et les revues AD, et qui créent encore une exposition matérielle dans des environnements réels.

1. Trop de comptes privilégiés et de groupes sensibles

C’est la famille de mauvaises configurations la plus basique dans AD : trop d’utilisateurs, de comptes de service ou de comptes de secours gardent une appartenance permanente à des groupes très sensibles ou à des droits délégués équivalents. Microsoft comme l’ANSSI poussent ici le même principe : réduire l’accès privilégié permanent et garder une portée d’administration explicite.

Le risque est simple. Chaque compte privilégié supplémentaire augmente l’exposition des crédentials, la surface de connexion interactive, le risque lié à la délégation et le périmètre de remédiation quand une identité est compromise. En pratique, le problème n’est généralement pas un seul compte Domain Admin. C’est l’accumulation lente d’anciens comptes admin, de comptes support, de comptes d’urgence devenus permanents et de chemins d’imbrication que personne n’épure plus.

À valider avant changement : inventaire des groupes privilégiés, imbrications, droits délégués sur les actifs Tier 0 et véritables cas d’usage d’administration. Retirer un accès sans vérifier l’ownership et la dépendance opérationnelle crée des incidents.

Preuves à conserver après correction : export de l’inventaire des groupes privilégiés, historique de suppression des accès et liste revue des identités qui nécessitent encore un privilège permanent.

2. Absence de séparation des chemins d’administration ou de postes d’admin sécurisés

Beaucoup d’environnements AD laissent encore la même identité administrer des serveurs, consulter sa messagerie, ouvrir des documents et se connecter à des postes de confiance plus faible. Le guide Microsoft sur les secure administrative hosts existe précisément parce que l’accès privilégié ne se résume pas à l’appartenance à un groupe. Il dépend aussi des endroits où les crédentials d’administration sont exposés.

Si les comptes privilégiés administrent depuis des postes généralistes, les crédentials et les tokens admin ont plus de chances d’être capturés, rejoués ou réutilisés dans un mouvement latéral. C’est pourquoi des postes d’admin dédiés, des comptes séparés et un chemin d’administration propre restent essentiels même quand l’appartenance aux groupes sensibles semble déjà raisonnable.

À valider avant changement : quels administrateurs utilisent déjà des comptes séparés, quels systèmes servent à l’administration, et quels workflows dépendent encore de postes mixtes. Beaucoup d’équipes découvrent qu’elles ont une séparation “sur le papier”, mais pas dans l’usage réel.

Preuves à conserver après correction : inventaire des postes d’administration sécurisés ou équivalents, restrictions de connexion ou d’assignation d’hôtes admin, et démonstration que l’administration sensible ne part plus de postes non maîtrisés ou généralistes.

3. Droits de réplication accordés trop largement

DCSync n’est pas seulement une étiquette offensive. Opérationnellement, c’est un problème de permissions : des identités qui n’ont pas besoin de droits de réplication les possèdent quand même. Microsoft Defender for Identity l’expose à travers l’évaluation des comptes non administrateurs disposant de droits DCSync, précisément parce que l’impact de fond est très élevé.

Quand Replicating Directory Changes, Replicating Directory Changes All ou des droits apparentés sont accordés trop largement, une identité peut demander des données annuaire extrêmement sensibles qui devraient rester sous contrôle serré. Le bon réflexe de remédiation n’est pas “bloquer DCSync”, mais “réduire au strict minimum les principals capables de répliquer”.

À valider avant changement : revue des ACL sur la racine du domaine et les objets pertinents, identification des détenteurs actuels de droits de réplication, et confirmation que chaque détenteur est réellement requis pour la sauvegarde, la synchronisation ou un outillage de sécurité.

Preuves à conserver après correction : capture de revue ACL, liste finale approuvée des identités capables de répliquer, et trace montrant que les principals retirés n’ont plus ces droits.

4. LDAP signing et channel binding mal appliqués

LDAP non signé reste l’un des meilleurs exemples d’un contrôle AD ancien mais toujours opérationnellement important. Le guide Microsoft sur LDAP signing pour AD DS existe parce que les binds SASL non signés et les simple binds peuvent affaiblir l’intégrité du trafic annuaire, et que les contraintes de compatibilité laissent souvent des environnements à moitié déployés.

La mauvaise configuration n’est pas toujours une simple valeur de registre. Plus souvent, c’est une application incohérente entre contrôleurs de domaine, des applications qui dépendent encore de comportements de bind plus faibles, ou une validation incomplète de l’impact réel sur les clients quand on augmente les exigences.

À valider avant changement : inventaire des clients LDAP, identification des usages de binds non signés, confirmation que LDAPS, signing ou channel binding ne casseront pas des applications héritées, puis montée progressive avant enforcement.

Preuves à conserver après correction : paramètres de stratégie des DC, résultats de test sur les applications critiques, et télémétrie montrant que les clients attendus utilisent bien un comportement conforme.

Pour le mécanisme détaillé et les caveats de validation, voir LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

5. SMB signing non requis là où il compte encore

SMB signing est un autre contrôle que les équipes connaissent, mais repoussent à cause d’hypothèses de performance, de craintes de compatibilité ou de baselines héritées côté postes et serveurs. Les recommandations Microsoft se sont durcies ici parce que SMB non signé laisse encore place à l’altération de trafic et soutient des conditions favorables au NTLM relay dans des environnements qui n’ont pas réduit leurs chemins de confiance hérités.

La mauvaise configuration n’est pas “SMB existe”. C’est l’absence d’exigence d’intégrité là où elle devrait être imposée, surtout sur des systèmes qui acceptent encore des flux d’authentification sensibles ou qui se trouvent sur des chemins d’administration.

À valider avant changement : appareils hérités, équipements embarqués, anciens serveurs ou chemins applicatifs qui reposent encore sur un comportement SMB plus faible. Vérifier l’état réel des politiques côté client et serveur plutôt que de supposer qu’un seul côté l’impose partout.

Preuves à conserver après correction : état effectif des politiques SMB signing, registre des exceptions pour les systèmes non encore conformes, et résultats de validation montrant que les systèmes sensibles exigent désormais la signature.

Pour l’exposition protocolaire détaillée, voir Signature SMB désactivée : pourquoi elle permet encore le NTLM relay.

6. Windows LAPS non déployé

Un grand nombre d’environnements AD protègent mieux les crédentials de domaine que les mots de passe administrateur locaux. Cela laisse un des plus vieux schémas d’exposition Windows en place : mots de passe admin locaux statiques ou réutilisés entre postes, et dans certains environnements, gestion insuffisante des mots de passe DSRM sur les contrôleurs de domaine.

Le guide Microsoft sur Windows LAPS est important parce que ce n’est pas seulement un sujet d’hygiène poste de travail. Des mots de passe admin locaux réutilisables facilitent le mouvement latéral, compliquent le confinement lors d’une fuite de mot de passe et affaiblissent la valeur d’autres mesures de durcissement.

À valider avant changement : quels endpoints utilisent déjà Windows LAPS, si l’ancien LAPS cohabite encore avec Windows LAPS, comment l’accès aux mots de passe est délégué, et si la gestion DSRM est bien incluse pour les contrôleurs de domaine.

Preuves à conserver après correction : état du déploiement des policies, couverture des machines gérées, lecteurs autorisés et vérification échantillonnée que les mots de passe tournent et ne sont récupérables que par les rôles approuvés.

Les détails de déploiement et de validation sont couverts dans Windows LAPS non déployé : pourquoi les mots de passe admin locaux partagés restent un risque.

7. Politiques de mot de passe faibles et exceptions sur les comptes privilégiés

Une politique de mot de passe faible reste courante, mais le vrai problème opérationnel dépasse un simple paramètre de domaine. On retrouve souvent des minimums trop faibles, l’absence de fine-grained password policies ciblées, des mots de passe privilégiés très anciens et des exceptions qui laissent discrètement des comptes critiques hors de la baseline voulue.

Le guide Microsoft sur les fine-grained password policies existe précisément parce que les comptes à forte valeur ne s’intègrent pas toujours à une politique unique. Dans le même temps, l’ANSSI insiste sur le fait que les comptes privilégiés et les usages d’administration doivent être gérés plus strictement que les comptes utilisateurs génériques.

À valider avant changement : stratégie de mot de passe effective du domaine, éventuelles fine-grained password policies, comptes privilégiés avec drapeaux d’exception, usages de Password never expires, et comptes de service encore gérés comme des comptes humains.

Preuves à conserver après correction : export des politiques effectives, mapping des groupes ou utilisateurs soumis à des règles renforcées, et revue documentée des exceptions restantes.

Pour les problèmes de crédentials adjacents, voir Active Directory Password Security: Misconfigurations That Matter.

8. Comptes de service hérités à mot de passe statique au lieu de gMSA quand c’est possible

Les comptes de service à mot de passe statique restent fréquents parce qu’ils survivent aux migrations, supportent d’anciens logiciels et n’ont souvent pas d’ownership clair. Microsoft pousse gMSA parce qu’il réduit le poids opérationnel de la gestion de mot de passe pour les charges compatibles, mais beaucoup d’environnements conservent encore des comptes de service privilégiés ou porteurs de SPN avec des mots de passe manuels et très anciens.

Le risque ne tient pas seulement à l’âge du mot de passe. Ces comptes sont souvent sur-privilégiés, difficiles à inventorier, exclus des revues de cycle de vie classiques et compliqués à faire tourner proprement. Quand des SPN sont présents, des crédentials de service très durables augmentent aussi la valeur d’un cracking hors ligne de tickets, d’où le recouvrement avec l’exposition de type Kerberoasting.

À valider avant changement : inventaire des comptes de service, ownership, usages de SPN, niveau de privilège, processus de rotation de mot de passe et compatibilité applicative avec gMSA. Tout ne peut pas migrer immédiatement, donc il faut cibler d’abord les comptes les plus risqués.

Preuves à conserver après correction : inventaire des comptes de service, propriétaires documentés, décisions de migration vers gMSA quand c’est possible, et preuve de rotation ou de conversion pour les comptes conservés sur un mot de passe statique.

9. Délégation Kerberos non sécurisée

La délégation Kerberos devient une mauvaise configuration quand elle est plus large que ce que le design applicatif exige réellement. Microsoft Defender for Identity met en avant la délégation non sécurisée parce que des réglages trop ouverts élargissent les chemins d’impersonation et changent matériellement la portée d’un compromis.

C’est un bon exemple d’une mauvaise configuration “courante” qui n’est pas une “correction simple”. La délégation est souvent pilotée par des contraintes applicatives. La retirer ou la convertir sans valider les flux de service peut casser l’authentification de production.

À valider avant changement : inventaire de la délégation unconstrained, constrained et resource-based quand elle existe, identification des owners applicatifs, et confirmation des systèmes qui ont encore réellement besoin de délégation.

Preuves à conserver après correction : inventaire revu de la délégation, paramètres supprimés ou convertis, et résultats de test démontrant que les flux applicatifs requis fonctionnent toujours après durcissement.

Pour l’effet de chaîne plus large, relier ce sujet à Chemins d’attaque AD : comment les mauvaises configurations s’enchaînent.

10. Permissions GPO dangereuses et faible contrôle des changements

Group Policy devient une mauvaise configuration de sécurité quand des identités de confiance faible ou trop larges peuvent modifier des GPO à fort impact, lier des paramètres dangereux ou changer des chemins de politique appliqués à des systèmes privilégiés. Microsoft comme l’ANSSI traitent l’administration GPO comme un sujet de control plane, pas seulement comme de l’outillage poste de travail.

L’impact dépasse une simple mauvaise valeur de policy. Des permissions GPO dangereuses peuvent permettre à un attaquant ou à un opérateur sur-privilégié de pousser de l’exécution de code, d’affaiblir la sécurité hôte, de changer les groupes locaux ou d’altérer la posture de systèmes placés sur des chemins d’administration.

À valider avant changement : qui peut éditer, lier ou créer des GPO, quels GPO s’appliquent aux systèmes privilégiés, et si le change control distingue les GPO à fort impact des changements bureautiques standards.

Preuves à conserver après correction : résultats de revue des permissions GPO, liste restreinte des éditeurs, traces d’approbation pour les GPO sensibles et couverture de monitoring des événements de changement GPO.

Pour l’analyse directe de ce chemin, voir GPO Misconfigurations: How Group Policy Becomes an Attack Vector.

⚠️ Si AD CS est déployé : les faiblesses de templates, d’enrollment et de configuration CA doivent entrer dans la même revue de premier niveau, même si elles ne font pas partie de ce Top 10 principal. Utiliser Attaques ADCS : chemins d’abus ESC1 à ESC8 comme deep dive dédié.

Pourquoi ces mauvaises configurations persistent-elles ?

Ces problèmes persistent parce qu’ils se situent à l’intersection de la compatibilité, de l’ownership et des exceptions accumulées. Le durcissement LDAP et SMB peut toucher des applications anciennes. Les comptes de service survivent souvent aux équipes qui les ont créés. Les réglages de délégation sont conservés parce que personne ne veut casser l’authentification. Les permissions GPO dérivent parce que l’administration des policies est répartie entre plusieurs équipes. Les comptes privilégiés restent parce que les retirer exige des preuves opérationnelles, pas seulement un avis sécurité.

C’est aussi pour cela qu’un contrôle annuel ne suffit pas. Si vous ne vérifiez ces contrôles qu’une fois par an, la dérive des privilèges, des comptes de service et des exceptions de policy peut revenir plus vite que le cycle de revue ne la détecte. Un processus récurrent compte autant que le premier nettoyage. Voir Audit Active Directory récurrent : pourquoi les audits annuels dérivent.

Comment les valider sans avancer à l’aveugle ?

Une bonne correction, ce n’est pas seulement un paramètre changé. C’est un paramètre changé, plus une preuve que le contrôle est réellement appliqué et que les workflows requis fonctionnent toujours.

C’est là que les logs et la visibilité des changements comptent. Si vous modifiez des contrôles AD centraux, vous devez aussi savoir si votre audit policy et votre modèle de collecte vous permettent réellement de voir les changements de groupes, d’ACL annuaire, de GPO et d’autres événements critiques du control plane. Utiliser Supervision sécurité AD : événements clés si votre baseline de logs reste faible.

Comment EtcSec aide à prioriser les mauvaises configurations AD

EtcSec est surtout utile ici quand l’objectif n’est pas une checklist ponctuelle, mais une vue répétable des mauvaises configurations AD qui laissent encore l’exposition la plus significative. Des findings comme EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, PASSWORD_POLICY_WEAK, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION et GPO_DANGEROUS_PERMISSIONS permettent de transformer cette liste en queue de remédiation auditable.

Le point important est la répétabilité. Après avoir durci un contrôle, il faut remesurer si l’exposition a vraiment disparu et si la dérive ne l’a pas réintroduite plus tard. C’est la différence entre lire un guide de durcissement une fois et maintenir réellement une posture AD dans le temps.

Références primaires

• Best practices for securing Active Directory
• Implementing Secure Administrative Hosts
• Privileged access strategy
• Security assessment: Remove non-admin accounts with DCSync permissions
• LDAP signing for Active Directory Domain Services
• Control SMB signing behavior
• Windows LAPS overview
• Group Managed Service Accounts overview
• Configure fine-grained password policies for AD DS
• Protected Users security group
• Authentication Policies and Authentication Policy Silos
• Security assessment: Unsecure Kerberos delegation
• Group Policy overview
• Configure Windows Event Forwarding
• Active Directory Certificate Services overview
• Guide ANSSI Active Directory