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 recouvre les politiques, les indicateurs de compte (flags) et les paramètres d'authentification hérités qui déterminent comment les identifiants sont créés, stockés et réutilisés dans le domaine. Quand ces contrôles sont faibles, l'attaquant n'a pas besoin d'une chaîne d'exploitation pour démarrer. Un mot de passe faible, un compte administrateur qui n'expire jamais, ou un mot de passe copié dans un attribut peuvent suffire.

Ces problèmes restent souvent discrets dans les opérations quotidiennes. Des comptes avec PasswordNeverExpires ou PasswordNotRequired peuvent rester en production pendant des mois, les mots de passe copiés dans les champs de description sont faciles à manquer, et des paramètres hérités comme WDigest ou NTLMv1 rendent les identifiants récupérés beaucoup plus faciles à réutiliser.

Cet article se concentre sur six erreurs de configuration liées aux mots de passe à fort impact dans Active Directory, et sur la manière de valider que les corrections ont réellement supprimé l'exposition.

Fonctionnement

Active Directory applique les contrôles de mots de passe via deux mécanismes principaux :

• Default Domain Password Policy appliquée à l'échelle du domaine via une stratégie de groupe
• Fine-Grained Password Policies (FGPP) appliquées à des utilisateurs ou groupes spécifiques via des Password Settings Objects

Les Fine-Grained Password Policies sont implémentées comme des Password Settings Objects (PSO), et leur précédence est définie via l'attribut msDS-PasswordSettingsPrecedence : une valeur plus faible signifie un PSO de priorité plus élevée. Un PSO lié directement à un utilisateur l'emporte toujours ; quand plusieurs PSO s'appliquent via l'appartenance à un groupe, celui avec la valeur de précédence la plus basse devient la politique résultante, et la Default Domain Password Policy ne s'applique que si aucun PSO ne correspond du tout. En pratique, les comptes tier-0 et les comptes de service devraient se trouver sous un PSO avec une valeur de précédence basse et une base nettement plus stricte que celle par défaut du domaine.

Si ni l'une ni l'autre n'est revue régulièrement, le résultat est prévisible : des mots de passe faibles ou trop anciens, des comptes exemptés des contrôles normaux, et des paramètres d'authentification hérités qui facilitent l'abus des identifiants une fois qu'un attaquant a pris pied.

La chaîne d'attaque

Étape 1 - Recenser les comptes faibles

Tout utilisateur authentifié du domaine peut interroger AD pour trouver des comptes avec des réglages de mot de passe faibles :

# Comptes avec des mots de passe qui n'expirent jamais
Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet | Sort-Object PasswordLastSet

# Comptes pour lesquels aucun mot de passe n'est requis
Get-ADUser -Filter {PasswordNotRequired -eq $true} -Properties PasswordNotRequired |
    Select-Object SamAccountName

# Comptes avec un mot de passe dans le champ de description
Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp|mot de passe|contrasena"} |
    Select-Object SamAccountName, Description

Étape 2 - Vérifier l'exposition aux protocoles hérités

# Vérifier si WDigest est activé
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest -Name UseLogonCredential

# Vérifier le niveau de compatibilité NTLM
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel
# Les valeurs 0-2 autorisent NTLMv1 ; la valeur 5 impose NTLMv2 uniquement

Étape 3 - Récupérer et cracker

Avec WDigest activé, une compromission locale qui atteint LSASS peut exposer directement des identifiants en clair :

# Exemple Mimikatz quand WDigest est activé
sekurlsa::wdigest

Pour les mots de passe faibles ou trop anciens, les attaquants peuvent aussi cracker le matériel NTLM hors ligne après un dump de hash :

hashcat -m 1000 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt

Étape 4 - Persister via une mauvaise hygiène des mots de passe

Les comptes avec PasswordNeverExpires sont des cibles de persistance durables. Si le compte est sensible et que le mot de passe n'est jamais renouvelé, l'attaquant conserve un chemin d'authentification valide jusqu'à ce qu'un administrateur le réinitialise explicitement.

Détection

Event IDs Windows

Signaux comportementaux

• Comptes avec des mots de passe plus anciens que votre fenêtre de rotation approuvée
• Comptes actifs avec PasswordNeverExpires ou PasswordNotRequired
• Champs de description contenant des chaînes ressemblant à des identifiants
• WDigest activé sur des postes ou serveurs où il n'est pas explicitement requis
• NTLMv1 encore négocié dans des environnements qui devraient être NTLMv2 uniquement

Requête de détection SIEM (Elastic KQL)

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

Remediation

1. Appliquer une politique de mot de passe de domaine stricte

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

2. Corriger les mots de passe non expirables

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

3. Corriger les comptes sans mot de passe requis

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

4. Supprimer les mots de passe des champs de description

Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp"} | ForEach-Object {
        Set-ADUser -Identity $_ -Description ""
        Write-Host "Description effacée pour : $($_.SamAccountName)"
    }

5. Désactiver WDigest

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

Déployez via GPO quand c'est possible : Configuration ordinateur > Modèles d'administration > MS Security Guide > WDigest Authentication = Disabled

6. Imposer NTLMv2 uniquement

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

Ou via une stratégie : Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité > Sécurité réseau : niveau d'authentification LAN Manager = Envoyer uniquement des réponses NTLMv2. Refuser LM et NTLM

7. Déployer Microsoft Entra Password Protection (environnements hybrides)

Pour les domaines synchronisés avec Microsoft Entra ID, Microsoft Entra Password Protection sur site bloque les mots de passe faibles au niveau du contrôleur de domaine lors des changements et réinitialisations de mot de passe — comblant une lacune que la politique de complexité intégrée ne couvre pas : les mots du dictionnaire, les motifs de clavier et les termes propres à l'organisation qui respectent techniquement les règles de complexité mais restent facilement devinables.

Le déploiement comporte deux composants : un service Password Protection Proxy qui récupère les listes globales et personnalisées de mots de passe bannis depuis Microsoft Entra ID, et un DC Agent installé sur chaque contrôleur de domaine qui applique localement la politique mise en cache lors des événements de changement et de réinitialisation de mot de passe. Le DC Agent continue d'appliquer la politique depuis sa copie en cache même si la connectivité au proxy est temporairement perdue.

# Confirmer que le DC Agent est installé et journalise les événements d'application
Get-EventLog -LogName "Microsoft-AADPasswordProtection-DCAgent/Admin" -Newest 20

Commencez en mode audit pour évaluer combien de mots de passe existants seraient rejetés avant de passer en mode d'application, et ajoutez des termes propres à l'organisation — noms de marque, noms de produits, noms de code de projets internes — à la liste personnalisée bannie ; la liste globale seule ne les détectera pas.

Comment EtcSec détecte cela

EtcSec audite les contrôles d'identité liés aux mots de passe à chaque scan AD.

PASSWORD_NEVER_EXPIRES signale les comptes actifs avec des mots de passe non expirables et aide à faire remonter en priorité les identités les plus à risque.

PASSWORD_POLICY_WEAK évalue la Default Domain Password Policy par rapport à la base de référence choisie pour la longueur, la complexité, l'historique et l'âge.

PASSWORD_NOT_REQUIRED identifie les comptes pour lesquels le flag PASSWD_NOTREQD est encore actif.

PASSWORD_IN_DESCRIPTION analyse les descriptions de l'annuaire à la recherche de chaînes ressemblant à des identifiants.

WDIGEST_ENABLED vérifie la mise en cache des identifiants en clair par WDigest.

NTLMV1_ALLOWED met en évidence les environnements qui autorisent encore la négociation NTLMv1.

Comptes nécessitant un traitement particulier

N'appliquez pas la même remédiation aveuglément à toutes les classes de comptes.

• Les comptes de service cassent souvent quand vous réinitialisez un mot de passe sans mettre à jour le service, la tâche planifiée ou le pool d'applications qui en dépend.
• Les comptes tier-0 ou break-glass ne doivent pas conserver des identifiants faibles ou partagés simplement parce qu'ils sont rarement utilisés ; ils nécessitent une gestion plus stricte, un stockage plus strict et une surveillance explicite.
• Les identités administratives partagées doivent être supprimées plutôt que simplement renouvelées. La rotation ne résout pas le problème de responsabilité.
• Les applications héritées qui dépendent encore de NTLMv1 ou d'une gestion faible des mots de passe nécessitent une exception limitée dans le temps et un plan de migration, pas une dérogation permanente.

À quoi ressemblent de bonnes preuves

Une revue de durcissement des mots de passe est beaucoup plus facile à défendre lorsque l'équipe conserve les preuves exactes ayant démontré que le nettoyage a bien eu lieu. Les éléments utiles incluent l'export avant/après des comptes avec PasswordNeverExpires, la liste des comptes qui avaient auparavant PasswordNotRequired, la confirmation que WDigest est désactivé sur des systèmes représentatifs, et la note de propriétaire ou de migration pour tout compte de service nécessitant encore une exception temporaire. Ces preuves comptent car l'hygiène des mots de passe a tendance à se dégrader via des exceptions urgentes et des raccourcis applicatifs.

Validation après remédiation

Ne clôturez le constat qu'après avoir relancé les mêmes étapes de découverte qu'utiliserait un attaquant :

• relancez les rapports PasswordNeverExpires et PasswordNotRequired et confirmez que les exceptions restantes sont intentionnelles
• vérifiez que les exceptions de comptes de service sont documentées, attribuées à un propriétaire et rattachées à un plan de migration comme l'adoption de gMSA
• contrôlez ponctuellement des systèmes représentatifs pour confirmer que UseLogonCredential vaut 0 là où WDigest devrait être désactivé
• validez que LmCompatibilityLevel correspond à votre plan de déploiement NTLMv2 uniquement et que les systèmes hérités ont été traités explicitement
• relancez la recherche dans les champs de description et confirmez que les identifiants ont été supprimés plutôt que simplement déplacés vers un autre attribut

Contrôles liés

L'hygiène des mots de passe devient beaucoup plus dangereuse lorsqu'elle se combine à Kerberoasting : comment les attaquants cassent les mots de passe des comptes de service, Comptes privilégiés obsolètes : un risque caché dans Active Directory, Supervision Active Directory : les Event IDs de sécurité qui comptent, ou Attaques NTLM Relay : détourner l'authentification dans AD. Passez ces contrôles en revue dans la même fenêtre de remédiation afin de supprimer le chemin d'attaque plutôt qu'un seul symptôme.