🏢Active DirectoryPasswordAccountsConfig

Sécurité des mots de passe Active Directory : erreurs critiques

Politiques de mots de passe faibles, mots de passe non expirables et stockage en clair des credentials sont parmi les vecteurs les plus exploités dans Active Directory. Apprenez à les identifier et les corriger.

ES
EtcSec Security Team
9 min read
Sécurité des mots de passe Active Directory : erreurs critiques

Qu'est-ce que la sécurité des mots de passe Active Directory ?

La sécurité des mots de passe Active Directory ne se limite pas à une longueur minimale. Elle regroupe tous les réglages qui déterminent comment un secret est choisi, stocké, dérivé, utilisé et renouvelé dans le domaine.

Dans un audit AD sérieux, six familles d'erreurs reviennent sans cesse :

  • mots de passe qui n'expirent jamais
  • politiques de mots de passe trop faibles
  • comptes avec PasswordNotRequired
  • mots de passe stockés dans des champs descriptifs
  • WDigest encore capable d'exposer du clair dans LSASS
  • NTLMv1 encore autorisé

Ce qui rend ces erreurs dangereuses, c'est qu'elles sont simples à exploiter et qu'elles s'enchaînent bien avec d'autres attaques : Kerberoasting, AS-REP Roasting, mouvement latéral via comptes de service, dump LSASS ou réutilisation de credentials anciens.

Le modèle technique à garder en tête

Les contrôles de mots de passe en environnement AD viennent de plusieurs endroits :

  • Default Domain Password Policy
  • Fine-Grained Password Policies (FGPP)
  • flags de compte dans userAccountControl
  • configuration d'authentification héritée sur les hôtes et contrôleurs de domaine
  • habitudes d'exploitation, par exemple laisser un secret dans description

Le vrai problème n'est donc pas seulement « un mot de passe faible ». Le vrai problème est la combinaison entre :

  • un secret crackable ou exposé
  • un compte utile
  • une durée de vie trop longue
  • un protocole ou un cache qui aide l'attaquant

Les six erreurs qui comptent vraiment

1. PasswordNeverExpires

Un compte avec PasswordNeverExpires = True donne à l'attaquant un secret qui peut rester exploitable pendant des années si personne ne le fait tourner.

Ce n'est pas seulement un problème d'hygiène. C'est un accélérateur de persistance, surtout sur les comptes de service, les comptes techniques et les comptes à privilèges.

2. Politique de mots de passe trop faible

Une politique trop permissive sur la longueur, l'historique ou la rotation réduit le coût du cracking hors ligne et augmente le succès des sprays.

Les FGPP compliquent souvent la lecture réelle du risque : le domaine peut paraître correctement configuré alors que certains groupes ou comptes sensibles héritent en fait d'une politique plus faible.

3. PasswordNotRequired

Le flag PASSWD_NOTREQD documenté par Microsoft est un vrai signal de posture dégradée. Il ne faut pas le banaliser. Même quand son exploitation dépend du contexte, un compte avec ce flag mérite une revue immédiate.

4. Mots de passe dans les descriptions

C'est l'une des erreurs les plus évitables et pourtant l'une des plus utiles à l'attaquant. Un secret laissé dans description ou dans un attribut texte transforme l'annuaire en dépôt de credentials.

5. WDigest encore actif

L'avis de sécurité Microsoft 2871997 existe précisément parce que WDigest peut exposer des credentials exploitables en mémoire. Si UseLogonCredential est activé, un dump LSASS peut redevenir beaucoup plus rentable pour l'attaquant.

6. NTLMv1 encore autorisé

Microsoft documente LMCompatibilityLevel depuis longtemps. Si l'environnement accepte encore des niveaux hérités, vous conservez un protocole plus faible qui facilite la réutilisation et l'analyse de réponses anciennes.

Comment un attaquant relie ces erreurs

Étape 1 - Inventorier les comptes faibles

Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet

Get-ADUser -Filter {PasswordNotRequired -eq $true} -Properties PasswordNotRequired |
    Select-Object SamAccountName

Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp|mot de passe|password"} |
    Select-Object SamAccountName, Description

Étape 2 - Vérifier les chemins d'exposition mémoire ou protocolaire

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' -Name UseLogonCredential
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel

Étape 3 - Exploiter selon le cas

Selon l'exposition trouvée, l'attaquant peut :

  • dumper LSASS pour récupérer du clair ou des dérivés exploitables
  • lancer du password spray sur des comptes trop anciens ou trop faibles
  • casser hors ligne des matériaux récupérés via Kerberoasting ou AS-REP Roasting
  • réutiliser des passwords locaux ou de service jamais changés

Le point clé est qu'une mauvaise posture mot de passe ne reste presque jamais isolée. Elle alimente d'autres techniques.

Détection

Ce qu'il faut suivre côté AD

Sur les contrôleurs de domaine, les événements liés aux comptes et aux échecs Kerberos sont utiles, mais ils ne suffisent pas seuls.

Commencez par surveiller :

  • 4738 pour les changements de compte, notamment les flags sensibles
  • 4723 et 4724 pour les changements et resets de mot de passe
  • 4771 pour les échecs de pré-authentification Kerberos pouvant révéler un spray
  • 4624 et les champs d'authentification quand l'environnement montre encore du NTLM hérité

Ce qu'il faut mesurer en posture

Le plus rentable reste souvent l'inventaire régulier de :

  • comptes avec PasswordNeverExpires
  • comptes avec PasswordNotRequired
  • comptes avec SIDHistory ou privilèges élevés combinés à une hygiène faible
  • présence de UseLogonCredential
  • valeur effective de LmCompatibilityLevel
  • utilisateurs ou comptes techniques avec PasswordLastSet très ancien

Exemple SIEM pour NTLMv1

event.code: "4624" AND
winlog.event_data.LmPackageName: "NTLM V1"

Le bon réflexe défensif n'est pas de chercher un seul Event ID magique. Il faut corréler posture faible + activité d'authentification + criticité du compte.

Remediation

1. Renforcer la politique du domaine et les FGPP

Set-ADDefaultDomainPasswordPolicy -Identity corp.local `
    -MinPasswordLength 14 `
    -ComplexityEnabled $true `
    -MaxPasswordAge (New-TimeSpan -Days 90) `
    -MinPasswordAge (New-TimeSpan -Days 1) `
    -PasswordHistoryCount 24

Le paramétrage exact dépend du contexte, mais l'objectif est clair : rendre le secret plus coûteux à casser et éviter la réutilisation triviale.

2. Corriger PasswordNeverExpires

Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} |
    Set-ADUser -PasswordNeverExpires $false

Pour les comptes de service, ne vous contentez pas d'un changement aveugle. Préparez la rotation applicative ou migrez vers des gMSA quand c'est possible.

3. Corriger PasswordNotRequired

Get-ADUser -Filter {PasswordNotRequired -eq $true} | ForEach-Object {
    Set-ADAccountControl -Identity $_ -PasswordNotRequired $false
}

4. Nettoyer immédiatement les descriptions contenant des secrets

Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp|password"} |
    ForEach-Object {
        Set-ADUser -Identity $_ -Description ""
    }

Si un mot de passe a été stocké dans un attribut, il faut considérer qu'il est exposé et le faire tourner, pas seulement effacer le texte.

5. Désactiver WDigest exposant les secrets

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' `
    -Name UseLogonCredential -Value 0

6. Forcer NTLMv2 uniquement

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' `
    -Name LmCompatibilityLevel -Value 5

Avant de le faire, vérifiez les systèmes ou applications hérités qui reposent encore sur des comportements anciens.

7. Valider la politique réellement appliquée aux comptes sensibles

Un durcissement propre doit vérifier la politique résultante sur les comptes à privilèges, les comptes de service et les comptes d'urgence. Beaucoup d'équipes relèvent la politique par défaut puis découvrent trop tard qu'une FGPP plus faible s'applique encore à certains objets critiques.

Get-ADUserResultantPasswordPolicy -Identity admin.exemple
Get-ADUserResultantPasswordPolicy -Identity svc.exemple

Le point de contrôle utile n'est pas « quelle politique a été configurée ? », mais quelle politique reçoit réellement le compte qui protège un service critique ou des privilèges élevés.

Remediation et priorisation operationnelle

L'ordre de remédiation compte. Commencez par retirer les expositions directes : secrets en clair dans description, PasswordNotRequired, WDigest encore actif. Ensuite, traitez les dépendances héritées comme NTLMv1, puis les exceptions de cycle de vie comme PasswordNeverExpires.

Pour les comptes de service, la vraie fermeture du sujet passe souvent par une migration vers gMSA ou par une rotation pilotée applicativement. Sinon, la même exception revient après le prochain incident ou la prochaine mise à jour. Une équipe technique doit donc documenter trois choses pour chaque exception restante : le propriétaire, la dépendance réelle et la date de sortie.

Une posture saine sur les mots de passe AD ne se résume pas à une case de conformité. Elle consiste à prouver qu'un secret utile est devenu plus difficile à extraire, plus difficile à casser et moins rentable à réutiliser.

Les comptes d'urgence et les comptes break-glass doivent aussi faire partie de la revue. Même peu utilisés, ils deviennent critiques si leur mot de passe échappe à la politique standard ou si leur rotation n'est jamais testée en conditions réelles.

Validation après correction

Une vraie fermeture du sujet doit permettre de démontrer :

  1. quels comptes gardent encore des exceptions (PasswordNeverExpires, PasswordNotRequired) et pourquoi
  2. que les secrets trouvés en clair dans des attributs ont été rotés, pas seulement supprimés du texte
  3. que UseLogonCredential n'expose plus de credentials en clair là où il ne devrait pas
  4. que l'environnement n'autorise plus NTLMv1
  5. que les comptes de service anciens ont un plan de migration ou de rotation crédible

Sans ces cinq points, on parle d'un nettoyage partiel, pas d'une vraie amélioration de posture. Cette validation doit aussi confirmer la politique résultante réellement appliquée aux comptes privilégiés et aux comptes de service, afin d'éviter qu'une FGPP plus faible ne recrée le même risque après la correction.

Erreurs classiques côté défense

Les erreurs qui reviennent le plus souvent :

  • considérer PasswordNeverExpires comme une simple commodité d'exploitation
  • oublier les FGPP et croire que la politique du domaine raconte toute l'histoire
  • vider un champ description sans changer le mot de passe qu'il contenait
  • désactiver un comportement hérité sur un hôte mais pas dans le reste du parc
  • corriger les flags de compte sans revoir les comptes de service, tâches planifiées et applications dépendantes

Un lecteur technique attend une conclusion simple : quels secrets restent faciles à trouver, faciles à casser ou faciles à réutiliser, et sur quels comptes cela devient critique.

Références primaires

Comment EtcSec détecte cela

EtcSec couvre ce sujet sous plusieurs angles :

  • PASSWORD_NEVER_EXPIRES
  • PASSWORD_POLICY_WEAK
  • PASSWORD_NOT_REQUIRED
  • PASSWORD_IN_DESCRIPTION
  • WDIGEST_ENABLED
  • NTLMV1_ALLOWED

Pris ensemble, ces constats permettent de répondre à une seule question utile : est-ce que vos secrets AD sont seulement conformes sur le papier, ou réellement difficiles à extraire, casser et réutiliser ?

Lectures connexes

🏢 Active DirectoryPasswordAccountsConfig
Sécurité Mots de Passe Active Directory | EtcSec