Active Directory : erreur « Your password does not meet the requirements » — diagnostic et correctifs

Dans un domaine Active Directory, toutes les tentatives de changement ou d’expiration de mot de passe renvoient « Your password does not meet the requirements ». Ce guide fournit une démarche priorisée, des commandes PowerShell et des correctifs concrets pour rétablir le changement de mot de passe.

Sommaire

Vue d’ensemble de la question

Contexte : domaine AD avec 13 contrôleurs de domaine. Tous les changements de mot de passe (forcés par expiration ou initiés par l’utilisateur) échouent avec le message générique « Your password does not meet the requirements », y compris avec des mots de passe a priori très complexes. Les paramètres sont : longueur minimale 8, complexité activée, âge minimal 0 jour. Objectif : identifier la cause réelle et appliquer la correction efficace.

Réponse & solution : plan d’investigation priorisé

L’approche ci‑dessous isole rapidement si l’échec provient (a) de la stratégie effectivement appliquée (Default Domain Policy vs PSO/FGPP), (b) d’un filtre de mot de passe tiers (Azure AD Password Protection, dictionnaire de mots bannis), (c) d’un problème de réplication/état DC, ou (d) de droits/ACL sur l’objet utilisateur.

Vérifier la stratégie effective (Default Domain Policy et PSO)

Point clé : les stratégies de mot de passe sont appliquées et validées par les contrôleurs de domaine, pas par les postes clients. Un gpupdate /force exécuté sur le poste n’influence donc pas la vérification. Seule la combinaison « Account Policies » au niveau domaine (GPO de domaine) et les PSO (Fine‑Grained Password Policies) déterminent la règle.

Commandes de base à exécuter depuis une session PowerShell avec RSAT/AD :

# Politique de mot de passe par défaut au niveau du domaine
Get-ADDefaultDomainPasswordPolicy |
  fl MinPasswordLength, ComplexityEnabled, MinPasswordAge, PasswordHistoryCount, MaxPasswordAge

# Lister toutes les PSO (FGPP) et leur priorité

Get-ADFineGrainedPasswordPolicy -Filter \* |
Select Name, Precedence, MinPasswordLength, ComplexityEnabled, MinPasswordAge, PasswordHistoryCount

# Politique réellement appliquée à un utilisateur donné

Get-ADUser \<samAccountName> | Get-ADUserResultantPasswordPolicy </code></pre>

<ul>
  <li><strong>PSO et priorité</strong> : si un PSO (FGPP) s’applique au compte (directement ou via groupe) et exige, par exemple, 14 caractères ou un âge minimal &gt; 0, il <em>écrase</em> la Default Domain Policy. La propriété <code>Precedence</code> détermine l’ordre : une valeur plus petite signifie une priorité plus haute.</li>
  <li><strong>À contrôler de suite</strong> : 
    <ul>
      <li><em>MinPasswordAge</em> doit être 0 si vous voulez autoriser l’utilisateur à rechanger immédiatement après un échec ou une réinitialisation.</li>
      <li><em>PasswordHistoryCount</em> ne doit pas empêcher la réutilisation involontaire d’un motif proche (l’historique stocke des empreintes ; évitez les petites variations).</li>
      <li><strong>Complexité</strong> : Windows exige au moins 3 catégories sur 4 (majuscules, minuscules, chiffres, caractères non alphanumériques) et <strong>rejette</strong> tout mot de passe qui contient le nom de l’utilisateur, son login (<code>sAMAccountName</code>) ou des segments de son nom affiché <em>avec au moins trois caractères consécutifs</em>. Testez avec une chaîne réellement aléatoire ne contenant <em>aucune</em> partie du nom/prénom/login.</li>
    </ul>
  </li>
  <li><strong>Bonnes pratiques de configuration</strong> : placez la stratégie de mot de passe de domaine dans la <em>Default Domain Policy</em> (DDP). Les règles différenciées par population s’implémentent exclusivement via des <em>PSO</em> (FGPP), et non via des GPO liées à des OU utilisateurs.</li>
</ul>

<h3>Rechercher la présence d’un filtre de mot de passe tiers</h3>
<p>De nombreux environnements emploient un filtre : Azure AD Password Protection on‑premises (banned passwords), Specops, etc. Ces filtres renvoient souvent le <em>même message générique</em>, ce qui masque la vraie cause.</p>

<p><strong>Identifier les filtres chargés sur un DC</strong> :</p>
<pre><code class="language-cmd">reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Notification Packages"
</code></pre>
<p>Par défaut, seule la DLL <code>scecli</code> est listée. <strong>Tout ajout</strong> (autre nom de DLL) indique un filtre de mot de passe tiers. Vérifiez que la même configuration est déployée <em>sur tous les DC</em> (même version, même paramètres).</p>

<p><strong>Journaux du filtre</strong> : consultez les journaux applicatifs spécifiques du fournisseur (par exemple : journaux « Applications et services » pour l’agent Azure AD Password Protection). Un rejet par dictionnaire (mot banni, motif clavier, saison+année, etc.) se repère rapidement.</p>

<p><strong>Test d’isolement rapide</strong> (en labo ou avec compte de test) : créez un PSO temporaire <em>sans complexité</em> pour un compte de test, forcez la réplication, puis effectuez un changement de mot de passe. Si le changement réussit sans complexité mais échoue avec, <strong>l’origine est un filtre/dictionnaire ou une FGPP trop stricte</strong>.</p>

<pre><code class="language-powershell"># Exemple de PSO de test, complexité désactivée
New-ADFineGrainedPasswordPolicy -Name "PSO-Temp-NoComplexity" `
  -Precedence 1 -MinPasswordLength 8 -ComplexityEnabled $false `
  -MinPasswordAge 0.00:00:00 -PasswordHistoryCount 0 -AppliesTo &lt;DN_du_groupe_ou_de_l_utilisateur_test&gt;
</code></pre>

<h3>Valider la santé AD et la réplication</h3>
<p>Des incohérences entre DC amènent des validations différentes selon le DC qui traite la demande (le DC dans le journal 4723/4724). Avant toute conclusion, validez l’état de réplication de l’annuaire <em>et</em> de SYSVOL (GPO).</p>

<pre><code class="language-cmd">repadmin /replsummary
repadmin /showrepl *
dcdiag /e /test:sysvolcheck /test:advertising
</code></pre>

<p>Si vous utilisez DFSR pour SYSVOL, contrôlez les arriérés de réplication :</p>
<pre><code class="language-cmd">dfsrdiag backlog /rgname:"Domain System Volume" /rfname:"SYSVOL Share" /sendingmember:&lt;DC1&gt; /receivingmember:&lt;DC2&gt;
</code></pre>

<p>Corrigez toute erreur (connectivité, permissions, santé du catalogue global, journal d’événements) et attendez la convergence complète avant de tester à nouveau.</p>

<h3>Vérifier les droits sur l’objet utilisateur</h3>
<p>Un déficit de droits « Changer le mot de passe » peut, selon les cas, se traduire par le <em>même</em> message générique. Activez « Fonctionnalités avancées » dans ADUC : onglet <strong>Sécurité</strong> &rarr; <strong>Avancé</strong>. Vérifiez que <strong>SELF</strong> et <strong>Everyone</strong> (ou <em>Authenticated Users</em>) ont l’autorisation <em>Allow</em> sur <em>Change password</em>. Assurez-vous que « User cannot change password » n’est pas coché sur l’onglet Compte.</p>

<p>Vérification par ligne de commande (exemple avec <code>dsacls</code>) :</p>
<pre><code class="language-cmd">dsacls "CN=Jean Dupont,OU=Ventes,DC=contoso,DC=local"
</code></pre>

<h3>Tester depuis un contrôleur de domaine</h3>
<p>Tester côté DC permet d’écarter un souci de poste (fournisseur d’authentification, portail, agent tiers, décalage d’horloge, etc.).</p>

<pre><code class="language-powershell"># Changement par l'utilisateur (nécessite l'ancien mot de passe)
$u = 'samAccountName'
Set-ADAccountPassword -Identity $u -OldPassword (Read-Host -AsSecureString "Ancien") `
                      -NewPassword (Read-Host -AsSecureString "Nouveau")

# Réinitialisation par un admin (n'implique pas MinPasswordAge)
Set-ADAccountPassword -Identity $u -Reset `
  -NewPassword (ConvertTo-SecureString 'MotDePasse!Test-01' -AsPlainText -Force)
</code></pre>

<p><strong>Lecture des résultats</strong> : si la réinitialisation admin fonctionne mais que l’utilisateur ne peut pas changer lui‑même, suspectez <em>MinPasswordAge &gt; 0</em> via PSO, absence de droits « Change password », ou filtre tiers.</p>

<h3>Examiner les journaux d’événements</h3>
<ul>
  <li><strong>Sur les DC</strong> (Journal : Sécurité) : 
    <ul>
      <li>Événement <strong>4723</strong> : tentative de <em>changement</em> de mot de passe.</li>
      <li>Événement <strong>4724</strong> : tentative de <em>réinitialisation</em> de mot de passe par un admin.</li>
    </ul>
    Relevez le DC impliqué, l’identifiant de l’appelant, le code/raison de l’échec (les filtres tiers consignent souvent des détails explicites).
  </li>
  <li><strong>Sur le client</strong> : synchronisation horaire (Kerberos tolère un décalage &lt; 5 minutes), affiliation au bon site AD, connectivité vers un DC sain.
    <pre><code class="language-cmd">w32tm /query /status
echo %LOGONSERVER%</code></pre>
  </li>
</ul>

<h2>Causes probables et corrections rapides</h2>
<ul>
  <li><strong>PSO plus strict</strong> que prévu (longueur &ge; 12/14, âge minimal &gt; 0, historique élevé).
    <br/>→ Ajuster le PSO ou sa <em>Precedence</em>, ou retirer l’utilisateur du groupe cible. Valider avec <code>Get-ADUserResultantPasswordPolicy</code>.</li>
  <li><strong>Filtre de mots de passe</strong> (Azure AD Password Protection ou autre) rejetant des motifs courants : « Saison+Année! », claviers (<em>azerty</em>), noms, mois, villes, etc.
    <br/>→ Mettre à jour la liste/dictionnaire, harmoniser la version/paramétrage sur tous les DC, adapter temporairement la politique pour tester.</li>
  <li><strong>Réplication défaillante</strong> (annuaire ou SYSVOL) : chaque DC applique potentiellement une règle différente.
    <br/>→ Corriger les erreurs <code>repadmin</code>/<code>dcdiag</code>, attendre convergence, retester.</li>
  <li><strong>Droits « Change password »</strong> révoqués involontairement ou « User cannot change password » activé.
    <br/>→ Rétablir les ACL par défaut (SELF + Everyone/Authenticated Users) au niveau de l’objet utilisateur.</li>
  <li><strong>Complexité</strong> : inclusion d’une partie du nom/login (≥ 3 caractères consécutifs).
    <br/>→ Essayer une phrase de passe réellement aléatoire qui ne contient aucune partie du nom, par exemple une phrase longue avec séparateurs.</li>
</ul>

<blockquote>
  <p><strong>À éviter</strong> : supprimer/recréer des profils Windows côté client. La validation des mots de passe est réalisée par le DC et n’est pas impactée par le profil local.</p>
</blockquote>

<h2>Check‑list express</h2>
<ol>
  <li>Exécuter <code>Get-ADUser &lt;sam&gt; | Get-ADUserResultantPasswordPolicy</code> sur l’utilisateur impacté.</li>
  <li>Lister tous les PSO avec leur <em>Precedence</em>, comparer à la politique attendue.</li>
  <li>Contrôler les filtres : <code>Notification Packages</code> sur 2–3 DC au hasard ; vérifier les journaux spécifiques du filtre.</li>
  <li>Valider la santé AD : <code>repadmin /replsummary</code>, <code>repadmin /showrepl *</code>, <code>dcdiag /e</code>, état DFSR SYSVOL.</li>
  <li>Vérifier les droits : ACL de l’objet utilisateur → <em>Change password</em> autorisé pour SELF + Everyone/Authenticated Users.</li>
  <li>Test ciblé : appliquer un PSO temporaire (complexité désactivée) sur un compte de test. Si succès : cause = PSO/filtre.</li>
</ol>

<h2>Tableau de diagnostic rapide</h2>
<table>
  <thead>
    <tr>
      <th>Symptôme observé</th>
      <th>Piste principale</th>
      <th>Vérification</th>
      <th>Correction</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Échec <em>pour tous</em> les utilisateurs, quel que soit le poste</td>
      <td>PSO global non documenté ou filtre tiers</td>
      <td><code>Get-ADFineGrainedPasswordPolicy</code>, <code>Notification Packages</code>, journaux du filtre</td>
      <td>Ajuster PSO/Precedence, aligner ou assouplir le filtre, retester</td>
    </tr>
    <tr>
      <td>Échec intermittent selon le moment ou le site</td>
      <td>Réplication inconsistante entre DC</td>
      <td><code>repadmin /replsummary</code>, <code>dcdiag</code>, DFSR backlog</td>
      <td>Réparer réplication, attendre la convergence</td>
    </tr>
    <tr>
      <td>Admin peut réinitialiser, l’utilisateur ne peut pas changer</td>
      <td><em>MinPasswordAge &gt; 0</em>, droits « Change password » manquants</td>
      <td>Résultante PSO, ACL SELF/Everyone</td>
      <td>Fixer PSO (âge minimal), rétablir ACL</td>
    </tr>
    <tr>
      <td>Échec malgré un mot de passe « très complexe »</td>
      <td>Motif banni / inclusion du nom / pattern clavier</td>
      <td>Journaux du filtre, test avec phrase aléatoire</td>
      <td>Adapter la liste bannie, éduquer les utilisateurs</td>
    </tr>
  </tbody>
</table>

<h2>Procédures détaillées</h2>

<h3>Contrôler et corriger les PSO (FGPP)</h3>
<ol>
  <li>Inventorier tous les PSO :
    <pre><code class="language-powershell">Get-ADFineGrainedPasswordPolicy -Filter * |
  Sort-Object Precedence |
  Format-Table Name, Precedence, MinPasswordLength, ComplexityEnabled, MinPasswordAge, PasswordHistoryCount

Vérifier la PSO effectivement appliquée à un utilisateur :

Get-ADUser &lt;sam&gt; | Get-ADUserResultantPasswordPolicy | fl *

Si un PSO indésirable s’applique via un groupe, soit en baisser la priorité (Set-ADFineGrainedPasswordPolicy -Precedence), soit retirer l’utilisateur du groupe, soit corriger les paramètres du PSO.
Documenter l’affectation des PSO aux groupes/utilisateurs :

Get-ADFineGrainedPasswordPolicy -Filter * | ForEach-Object {
  $pso = $_
  [PSCustomObject]@{
    Name        = $pso.Name
    Precedence  = $pso.Precedence
    AppliesTo   = ($pso.AppliesTo | ForEach-Object { (Get-ADObject $_ -Properties name).Name }) -join '; '
  }
} | Sort-Object Precedence | Format-Table -Auto

Diagnostiquer un filtre de mot de passe

Sur un premier DC : reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v "Notification Packages" Relever toute DLL ajoutée.
Répliquer la vérification sur plusieurs DC : s’assurer que la liste est uniforme. Un filtre installé sur seulement quelques DC produit des échecs intermittents.
Consulter les journaux dédiés du filtre pour des motifs explicites (mot banni, règle base+suffixe, etc.).
Test A/B : avec PSO temporaire sans complexité appliqué à un compte de test. Si l’échec disparaît, c’est un indice fort d’un filtre/dictionnaire.
Corriger : mettre à jour l’agent/filter, revoir les paramètres (mode audit vs enforce si prévu), aligner la version sur l’ensemble des DC.

Réparer la réplication et la cohérence

Exécuter : repadmin /replsummary repadmin /showrepl * dcdiag /e /test:sysvolcheck /test:advertising Corriger toute erreur (sites/lients, authentification, DNS, NTDS Settings).
Vérifier SYSVOL (DFSR) : aucun arriéré significatif, pas de conflit de GPO.
Tester à nouveau un changement de mot de passe en notant le DC effectif via l’événement 4723.

Rétablir les droits « Change password »

Dans ADUC, activer les fonctionnalités avancées, ouvrir l’utilisateur → Sécurité → Avancé → vérifier que SELF et Everyone/Authenticated Users ont Allow sur Change password.
Si nécessaire, réappliquer les entrées par défaut (via modèle d’héritage OU ou script d’ACL).
Contrôler que « User cannot change password » n’est pas coché.

Comprendre la complexité Windows

Au moins 3 catégories sur 4 : majuscules, minuscules, chiffres, caractères non alphanumériques.
Interdiction d’utiliser le nom complet ou le login (sAMAccountName) en clair, ainsi que des segments significatifs (≥ 3 caractères consécutifs).
Conseil : privilégiez des phrases de passe (longues, avec séparateurs) plutôt que des mots simples agrémentés d’un suffixe.

Exemples de scénarios concrets

PSO caché sur un groupe transverse

Un PSO « VIP‑Policy » avec Precedence 1 exige 14 caractères et MinPasswordAge de 1 jour. Il a été appliqué à un groupe transverse auquel appartiennent la plupart des collaborateurs. Résultat : échec du changement immédiat avec message générique. Fix : abaisser la priorité du PSO ou corriger ses paramètres, vérifier la résultante par Get-ADUserResultantPasswordPolicy.

Filtre de mots bannis partiellement déployé

L’agent de protection des mots de passe n’est installé que sur 6 DC sur 13. Les utilisateurs dépendant de ces DC voient leurs mots de passe rejetés (motifs « Saison+Année » bannis), les autres non. Fix : déployer/aligner l’agent sur tous les DC, normaliser la configuration, basculer temporairement en mode audit pour mesurer l’impact, puis réactiver l’application stricte.

Réplication SYSVOL en retard

Un GPO de domaine définissant la longueur minimale à 12 n’est pas répliqué sur tous les DC. Selon le DC qui traite la demande, la règle effective varie, générant des rejets imprévisibles. Fix : corriger DFSR, purger l’arriéré, valider dcdiag /e, puis retester.

Conseils de prévention et de gouvernance

Documenter la politique : export de la DDP, liste des PSO, affectations aux groupes, captures des événements 4723/4724 (échec/succès) pour traçabilité.
Standardiser : une seule source de vérité (DDP au niveau domaine), PSO uniquement pour les exceptions, filtres tiers déployés de façon homogène.
Automatiser des tests réguliers (comptes sentinelles) qui changent leur mot de passe via différents DC/sites, et qui remontent des alertes en cas d’échec.
Former les utilisateurs : expliquer les motifs bannis fréquents (noms, dates, saisons, claviers) et promouvoir les phrases de passe.
Superviser la réplication AD/DFSR et la santé des rôles FSMO (notamment PDC Emulator) : toute dégradation altère la cohérence de validation.

FAQ et points d’attention

Une GPO liée à une OU utilisateur peut‑elle imposer un mot de passe ?
Non. Les paramètres « Account Policies » (mot de passe, verrouillage) sont effectifs lorsqu’ils sont définis dans une GPO liée au niveau domaine. Les règles par population utilisent les PSO (FGPP).

Pourquoi l’utilisateur ne peut‑il pas changer juste après une réinitialisation ?
Si MinPasswordAge > 0 (via PSO/DDP), l’utilisateur ne peut pas changer immédiatement son mot de passe même s’il connaît l’ancien ; une réinitialisation admin contourne cet âge minimal.

Le message « does not meet the requirements » signifie‑t‑il toujours un problème de complexité ?
Non. C’est un message générique utilisé aussi par les filtres tiers, par les contraintes d’historique, par l’âge minimal, et parfois par des droits insuffisants.

Comment savoir quel DC a traité la demande ?
Consultez l’événement 4723/4724 sur les DC : l’événement journalise le DC, l’appelant et le résultat. Sur le poste, echo %LOGONSERVER% donne le DC de logon, qui n’est pas toujours celui qui a validé le changement.

La complexité Windows rejette‑t‑elle les mots de passe avec partie du nom même « hachée » ?
Oui, la vérification compare des segments (≥ 3 caractères) du nom complet et du login ; des variations mineures (ajout d’un caractère) ne suffisent pas.

Scripts utiles pour gagner du temps

Inventaire complet des PSO et affectations

$psos = Get-ADFineGrainedPasswordPolicy -Filter * | Sort-Object Precedence
$report = foreach($p in $psos){
  [pscustomobject]@{
    Name       = $p.Name
    Precedence = $p.Precedence
    MinLen     = $p.MinPasswordLength
    Complex    = $p.ComplexityEnabled
    MinAge     = $p.MinPasswordAge
    History    = $p.PasswordHistoryCount
    AppliesTo  = ($p.AppliesTo | % { (Get-ADObject $_ -Properties name).Name }) -join '; '
  }
}
$report | Format-Table -Auto

Résultante de politique pour une liste d’utilisateurs

$users = 'jdupont','mdupont','pbernard'
foreach($u in $users){
  $p = (Get-ADUser $u | Get-ADUserResultantPasswordPolicy)
  [pscustomobject]@{
    User = $u
    PSO  = $p.Name
    MinLen = $p.MinPasswordLength
    Complex = $p.ComplexityEnabled
    MinAge  = $p.MinPasswordAge
    History = $p.PasswordHistoryCount
  }
} | Format-Table -Auto

Contrôle des filtres de mot de passe sur tous les DC

Get-ADDomainController -Filter * | ForEach-Object {
  $dc = $_.HostName
  Invoke-Command -ComputerName $dc -ScriptBlock {
    try {
      (Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name "Notification Packages")."Notification Packages"
    } catch { "Erreur de lecture du Registre" }
  } | ForEach-Object { [pscustomobject]@{ DC = $dc; NotificationPackages = $_ } }
} | Format-Table -Auto

Test contrôlé d’un changement de mot de passe

$u = 'samAccountName'
$old = Read-Host -AsSecureString "Ancien"
$new = Read-Host -AsSecureString "Nouveau"
try {
  Set-ADAccountPassword -Identity $u -OldPassword $old -NewPassword $new -ErrorAction Stop
  Write-Host "Succès" 
} catch {
  Write-Warning $_.Exception.Message
}

Conclusion

Lorsque « Your password does not meet the requirements » survient à grande échelle, résistez aux actions côté poste : la cause se situe presque toujours côté contrôleur de domaine (PSO inattendu, filtre de mot de passe, réplication, droits). En appliquant la démarche priorisée — vérification de la résultante, identification des filtres, validation de la réplication, contrôle des ACL, et tests depuis un DC — vous isolez rapidement l’origine : PSO caché, filtre/dictionnaire, incohérence de réplication ou problème d’autorisations. Corrigez, documentez, puis installez des checks réguliers (scripts/sentinelles) pour prévenir toute régression.

Récapitulatif opérationnel

Voir la vraie règle : Get-ADUserResultantPasswordPolicy (utilisateur impacté).
Comprendre la source : inventaire PSO + Precedence, journal 4723, filtre de mot de passe (Notification Packages + logs).
Assainir l’infra : corriger réplication AD/DFSR, valider dcdiag /e.
Rétablir le droit : SELF + Everyone/Authenticated Users → Change password = Allow.
Tester intelligemment : PSO temporaire sans complexité pour isoler l’impact d’un filtre/FGPP.
Prévenir : standardiser DDP/PSO, homogénéiser les filtres, automatiser des tests sentinelles.

En suivant ce cheminement, vous rétablirez un changement de mot de passe fiable, cohérent sur l’ensemble des 13 DC, tout en durcissant la sécurité de façon maîtrisée.

Active Directory : erreur « Your password does not meet the requirements » — diagnostic et correctifs