Politique de mots de passe AD : pourquoi ANSSI et CIS diffèrent

Qu’est-ce que la conformité de la politique de mots de passe AD ?

La conformité de la politique de mots de passe AD dépend de la règle exacte évaluée. Un domaine peut satisfaire les critères numériques cités pour le contrôle de politique de mots de passe ANSSI d’EtcSec et échouer au contrôle CIS sur la même configuration. Les contrôles lisent des attributs en partie communs, mais appliquent des seuils différents et couvrent des paramètres différents.

La question utile est donc : quel attribut a échoué, selon quel référentiel documenté et avec quelle version du détecteur ? Un résultat étiqueté ANSSI ou CIS doit mener à ces éléments de preuve. Il ne peut pas, à lui seul, établir la conformité à une publication entière.

Cette comparaison distingue les deux prédicats de détecteur documentés dans une revue du collecteur de septembre 2026 des recommandations sous-jacentes. La comparaison documentaire utilise le CIS Microsoft Windows Server 2012 R2 Benchmark v2.2.0, daté du 28 avril 2016, sections 1.1 et 1.2. Il s’agit d’une édition historique. Le catalogue CIS actuel répertorie Server 2022 v5.1.0, qui n’a pas été lu pour cet article.

Notre guide pratique ANSSI pour Active Directory explique pourquoi un programme de sécurité AD nécessite un ensemble défini de documents complémentaires, plutôt qu’une affirmation de conformité fondée sur un seul PDF.

Comment les contrôles ANSSI et CIS diffèrent

Le tableau suivant distingue les recommandations des sources des conditions citées pour Detect(). Les valeurs décrivent la configuration qui satisfait les conditions numériques citées, plutôt que les expressions d’échec elles-mêmes.

La revue du collecteur cite ad/compliance/anssi/r1-password-policy.go et ad/compliance/cis/password-policy.go. Les fichiers Go complets n’étaient pas disponibles pour cette comparaison. Le tableau permet donc de conclure sur ces extraits ; il n’établit pas les branches non citées, la gestion des erreurs ni la couverture des données de collecte manquantes.

Les sources des colonnes documentaires sont ANSSI-PG-078 et le PDF historique CIS Server 2012 R2 v2.2.0. Les colonnes des détecteurs proviennent des prédicats cités reproduits ci-dessous. Ce sont des seuils d’implémentation, et non une attribution de chaque nombre à l’ANSSI. Les différences de 60/365 jours et de 10/5 tentatives montrent aussi pourquoi une édition doit accompagner toute affirmation au niveau documentaire.

La complexité est une question distincte

Microsoft définit pwdProperties comme un champ de bits de politique de domaine relatif à la complexité et aux restrictions de stockage. Son indicateur DOMAIN_PASSWORD_COMPLEX vaut 1. Examiner la longueur, l’historique et l’âge ne permet pas d’établir l’état de cet indicateur.

Une évaluation complète doit donc consigner explicitement la complexité. Les extraits fournis pour ces deux contrôles ne montrent pas de condition de complexité. Il s’agit d’une limite des preuves d’implémentation disponibles, et non de la preuve que les détecteurs complets l’ignorent. Ne transformez pas un champ non documenté en réussite supposée.

Cas où les résultats divergent

Ces exemples sont des configurations hypothétiques évaluées selon les prédicats numériques cités. Ce ne sont pas des résultats d’un environnement client ni d’une exécution réelle du collecteur. Pour ces exemples, on suppose que les durées sont exprimées en jours, que l’absence d’expiration est représentée par maxPwdAge == 0 et que les autres champs contiennent des valeurs valides. Ces hypothèses correspondent aux comparaisons citées ; la conversion des valeurs de l’annuaire par le collecteur n’a pas été vérifiée.

Chaque ligne isole une raison du désaccord. Une politique réelle peut échouer à plusieurs conditions simultanément ; conservez donc tous les attributs en échec au lieu de ne signaler que le premier rencontré. Le plan de remédiation devient ainsi précis : un échec sur l’historique nécessite une modification de l’historique, tandis qu’un échec sur l’âge nécessite une décision explicite sur l’expiration.

L’inverse peut-il se produire ?

Pour ces prédicats cités, sur les mêmes entrées valides, satisfaire les conditions numériques CIS implique de satisfaire les conditions numériques ANSSI. Une longueur minimale de 14 satisfait aussi 12 ; un historique de 24 satisfait 12 ; un seuil de verrouillage entre 1 et 5 se situe aussi entre 1 et 10. Les conditions d’âge propres au CIS ajoutent des exigences sans assouplir celles qui sont communes.

Il n’existe donc pas d’exemple démontré de réussite CIS et d’échec ANSSI pour cette paire d’extraits. Si un audit signale cette combinaison, comparez les valeurs collectées, la version du détecteur et les détails complets du constat avant de l’expliquer par une différence entre normes. Des entrées, implémentations ou périmètres d’audit différents nécessitent leurs propres preuves.

La dernière ligne n’établit pas non plus une conformité complète au benchmark. Elle dit seulement que ces cinq entrées numériques satisfont les expressions citées. La complexité reste une vérification distincte, et un benchmark complet comprend d’autres contrôles.

Détection : lire la politique de mots de passe par défaut du domaine

Utilisez le module PowerShell Active Directory pour collecter la politique par défaut du domaine. Remplacez le domaine de l’exemple par le domaine examiné :

Get-ADDefaultDomainPasswordPolicy -Identity 'example.com' |
    Select-Object DistinguishedName, MinPasswordLength, PasswordHistoryCount,
        LockoutThreshold, MaxPasswordAge, MinPasswordAge, ComplexityEnabled

Il s’agit d’un seul pipeline en lecture seule fondé sur la documentation Microsoft de Get-ADDefaultDomainPasswordPolicy. Il n’a pas été exécuté sur un domaine réel pour cet article.

Lisez la sortie comme une preuve pour un domaine et une heure de collecte spécifiques. Conservez le nom distinctif avec les valeurs afin qu’une revue ultérieure puisse déterminer si les deux résultats d’audit décrivent effectivement la même politique. Ne comparez pas un paramètre GPO de mémoire à un résultat récent du collecteur en supposant que leurs entrées sont identiques.

MinPasswordLength est un nombre de caractères. PasswordHistoryCount correspond au nombre de mots de passe conservés ; la page du schéma pwdHistoryLength de Microsoft documente l’attribut d’annuaire. Les propriétés d’âge sont des durées, tandis que la longueur, l’historique et le seuil de verrouillage sont des nombres. Gardez ces unités explicites lors du transfert des preuves dans une feuille d’audit.

La commande renvoie la politique par défaut du domaine. Elle n’établit pas la politique effective de chaque utilisateur lorsque des stratégies de mot de passe affinées s’appliquent. Microsoft documente une requête distincte de politique de mots de passe résultante pour les utilisateurs ; n’étendez pas un résultat par défaut du domaine à une affirmation de conformité compte par compte.

Remédiation : corriger l’attribut en échec selon un référentiel nommé

Décidez d’abord quel référentiel et quelle édition régissent le changement. Documentez le résultat requis, puis modifiez les attributs qui ne le satisfont pas. Un paramètre qui supprime un constat peut en laisser un autre intact, comme le montre le tableau d’exemples.

Pour un exemple satisfaisant les deux prédicats numériques cités et les critères numériques du tableau historique, utilisez une longueur de 14, un historique de 24, un seuil de verrouillage de 5, un âge maximal de 60 jours et un âge minimal de 1 jour. La valeur de 60 jours provient de la section historique CIS 1.1.2 ; le choix plus strict de 5 tentatives provient de l’extrait du détecteur CIS. Activez la complexité pour le critère distinct de complexité du document cité. C’est un exemple de comparaison, et non une recommandation d’adopter aujourd’hui un benchmark historique.

L’exemple de configuration suivant utilise les paramètres documentés par Microsoft pour Set-ADDefaultDomainPasswordPolicy :

Set-ADDefaultDomainPasswordPolicy -Identity 'example.com' `
    -MinPasswordLength 14 -PasswordHistoryCount 24 -LockoutThreshold 5 `
    -MaxPasswordAge '60.00:00:00' -MinPasswordAge '1.00:00:00' `
    -ComplexityEnabled $true -WhatIf

-WhatIf prévisualise l’opération proposée sans l’appliquer. Cet exemple a été vérifié dans la documentation ; il n’a pas été exécuté dans un domaine réel. Un administrateur doit tester le changement prévu, puis l’appliquer selon le processus de gestion des politiques de l’organisation et répéter la requête en lecture seule ci-dessus. Une prévisualisation n’est pas un résultat de remédiation réussi.

Décider délibérément de l’expiration

ANSSI-PG-078 R24 déconseille l’expiration par défaut pour les comptes non sensibles lorsque des mots de passe robustes et les systèmes qui les accompagnent le permettent ; R25 maintient l’expiration pour les comptes privilégiés. Le texte qui précède privilégie l’authentification à deux facteurs pour ces comptes et aborde l’expiration lorsque seule l’authentification par mot de passe est utilisée. Cette distinction entre comptes ne peut pas être établie par une seule valeur d’âge à l’échelle du domaine. L’absence de constat d’âge du détecteur ANSSI ne valide pas l’ensemble de la politique d’expiration.

Si le référentiel choisi exige un âge maximal non nul, conservez cette exigence ou documentez l’exception dans votre processus d’audit. Supprimer un constat du tableau de bord et justifier une exception sont deux résultats différents ; consignez celui que vous avez obtenu.

Vérifier le changement et l’exposition restante

Conservez la sortie de politique avant et après, l’édition du référentiel et la raison de chaque attribut modifié. Relancez les deux contrôles sur la même collecte récente et examinez individuellement les constats restants. Si la configuration a changé mais pas le constat, rapprochez l’heure de collecte et les valeurs signalées avant de modifier de nouveau la politique.

La conformité de la politique de mots de passe nécessite aussi un contexte opérationnel. Notre article sur le password spraying explique comment quelques essais répartis sur de nombreux comptes peuvent éviter des verrouillages évidents par compte, et pourquoi la mitigation associe contrôles de mots de passe, authentification renforcée et surveillance corrélée. Réussir un contrôle de seuil de verrouillage ne doit pas servir de preuve que le spraying a été éliminé.

Comment EtcSec détecte ces problèmes

Le catalogue du site contient ANSSI_R1_PASSWORD_POLICY et CIS_PASSWORD_POLICY. La revue du collecteur fournit les conditions d’échec suivantes pour leurs implémentations respectives de Detect() :

ANSSI_R1_PASSWORD_POLICY
ad/compliance/anssi/r1-password-policy.go
minPwdLength < 12 OR pwdHistoryLength < 12
OR lockoutThreshold == 0 OR lockoutThreshold > 10

CIS_PASSWORD_POLICY
ad/compliance/cis/password-policy.go
minPwdLength < 14 OR pwdHistoryLength < 24
OR maxPwdAge > 365 OR maxPwdAge == 0
OR minPwdAge < 1 OR lockoutThreshold > 5 OR lockoutThreshold == 0

Les seuils d’âge ci-dessus sont exprimés en jours pour cette comparaison, conformément à l’exemple maxAge=120j de la revue (ligne 127). Les extraits n’établissent pas comment le collecteur convertit les intervalles LDAP bruts ni représente les politiques sans expiration. Ils expliquent pourquoi une même politique peut produire des constats différents et pourquoi chaque constat doit nommer son attribut en échec.

La preuve d’implémentation est la revue du collecteur dans docs/research/ad/2026-09-13-ad-catalogue-gap-diff.md, lignes 123 et 124 respectivement. Ces lignes citent les fichiers Go nommés ; les numéros de ligne du code Go n’étaient pas disponibles. Les fichiers sources complets n’étaient pas disponibles dans cette revue. La couverture de la complexité, le comportement en cas de données manquantes et toutes les autres branches non citées restent non vérifiés. Ces constats sont des signaux de configuration utiles ; leurs noms ne transforment pas un prédicat partiel en évaluation ANSSI ou CIS complète.

Références primaires

• ANSSI : Recommandations de sécurité relatives à Active Directory, DAT-NT-17 v1.1, 10 septembre 2014 ; R1, page imprimée 8.
• ANSSI : Recommandations relatives à l’authentification et aux mots de passe, ANSSI-PG-078 v2.0, 8 octobre 2021 ; R10 et R21–R25.
• CIS : catalogue des benchmarks Microsoft Windows Server et sélection de l’édition. Comparaison historique : Server 2012 R2 v2.2.0, 28 avril 2016 ; sections 1.1.1–1.1.5 et 1.2.2, PDF lié ci-dessus. Server 2022 v5.1.0 n’a pas été lu.