Des utilisateurs reçoivent un message d’alerte leur indiquant que leur mot de passe Active Directory expirera alors qu’ils l’ont changé depuis à peine plus d’un mois ; pourtant la stratégie « Maximum password age » de la Default Domain Policy est fixée à 365 jours. Cet article détaille les causes, les vérifications à réaliser et la méthode complète pour résoudre cet écart et rétablir un cycle d’expiration conforme aux exigences de sécurité de votre organisation.
Contexte et symptôme observé
Le service informatique constate une vague de tickets : environ quarante jours après un changement de mot de passe, Windows affiche déjà la notification « Votre mot de passe expirera bientôt ». Le paramètre GPO du domaine prévoit pourtant un maximum d’un an (365 jours). Le contrôle de gpresult /R confirme que la Default Domain Policy est bien appliquée, et l’attribut LDAP pwdLastSet reflète la date réelle de changement (par exemple 19 mars 2024). Aucun second contrôleur de domaine ne risque donc d’introduire un décalage de réplication.
Vérifications préalables effectuées
- GPO appliquée : la Default Domain Policy est reçue sans erreur.
- Autres stratégies : aucune autre GPO ne définit de paramètres de mot de passe.
- Registre serveur : une valeur
MaximumPasswordAgeà 30 jours sousHKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parametersa été repérée puis portée à 365 jours, sans impact observable. - Infrastructure : un seul DC ; la réplication n’est donc pas en cause.
Comprendre la véritable priorité des politiques
Depuis Windows Server 2008, les stratégies de mot de passe à granularité fine (Fine‑Grained Password Policies, FGPP) autorisent l’application d’âges maximums différents selon les groupes ou même selon l’utilisateur. Elles résident dans le conteneur « Password Settings Container » de la partition de domaine et disposent d’une priorité supérieure à la Default Domain Policy. Il suffit qu’un utilisateur soit membre, même indirectement, d’un groupe ciblé par une FGPP pour qu’il hérite silencieusement d’un nouveau cycle d’expiration – souvent 30 ou 42 jours, valeurs héritées d’anciennes normes de sécurité.
| Cause possible | Description du phénomène | Action corrective |
|---|---|---|
| Fine‑Grained Password Policy | Une FGPP prévoit un MaxPasswordAge plus court et s’applique à l’utilisateur ou à un de ses groupes. | Recenser toutes les FGPP, identifier celles qui visent l’utilisateur, puis ajuster ou supprimer la politique fautive. |
| Appartenance à des groupes imbriqués | L’utilisateur hérite d’une FGPP via un groupe secondaire ou un groupe imbriqué oublié. | Analyser la chaîne de groupes avec PowerShell et vérifier l’attribut msDS-PSOApplied de chaque groupe. |
Valeur registre MaximumPasswordAge | Se limite au mot de passe du compte ordinateur, sans effet sur les comptes utilisateurs. | Aucune action requise pour l’expiration utilisateur ; s’assurer qu’aucun script ne lit cette valeur pour contrôler les comptes humains. |
Diagnostic détaillé pas à pas
Recherche des FGPP existantes
Ouvrez l’Active Directory Administrative Center et naviguez jusqu’au conteneur Password Settings Container. Chaque objet répertorié représente une FGPP. Pour une liste rapide en ligne de commande, exécutez :
Get-ADFineGrainedPasswordPolicy -Filter * |
Select-Object Name, MaxPasswordAge, PrecedenceIdentification des cibles d’une FGPP
Pour comprendre qui est réellement impacté, inspectez la propriété AppliesTo :
Get-ADFineGrainedPasswordPolicy -Identity "Nom_FGPP" |
Select-Object -ExpandProperty AppliesToNotez qu’un groupe répertorié peut contenir d’autres groupes. Pour tracer l’héritage complet :
Get-ADUser -Identity <SamAccountName> -Property MemberOf |
Select-Object -ExpandProperty MemberOfVérification de la politique réellement appliquée
Pour un diagnostic final, comparez les valeurs issues de deux commandes complémentaires :
net user <login> /domain(ligne « Mot de passe expire »)Get-ADUserResultantPasswordPolicy <login>
Remédiation
- Modifier la FGPP fautive
Si l’entreprise souhaite conserver la granularité mais allonger l’âge maximal, saisissez :Set-ADFineGrainedPasswordPolicy -Identity "Nom_FGPP" ` -MaxPasswordAge (New-TimeSpan -Days 365) - Détacher ou supprimer la FGPP
Supprimez les liaisons ou l’objet entier lorsqu’il n’a plus d’utilité. - Actualiser les stratégies
Sur chaque poste, forcezgpupdate /forceou laissez la GPO se réappliquer lors du prochain ticket Kerberos. - Valider la correction
Renouveleznet userouGet-ADUserResultantPasswordPolicy. La date d’expiration doit maintenant se situer à +365 jours.
Informations complémentaires
- Niveau fonctionnel de domaine : la présence de FGPP nécessite un niveau au moins égal à Windows Server 2008. Une rétrogradation involontaire peut déstabiliser la hiérarchie de règles.
- Ordre de priorité : FGPP → Default Domain Policy → stratégies locales ; les stratégies locales n’ayant aucune chance de prévaloir en environnement AD.
- Alerte côté client : l’invite « changez votre mot de passe dans x jours » dépend du paramètre :
User Configuration → Policies → Administrative Templates → System → Ctrl+Alt+Del Options → Prompt user to change password before expiration. Si vous passez de 30 à 365 jours, pensez à allonger le pré‑avis, sous peine d’une alerte 350 jours avant l’échéance ! - Redémarrage non requis : seule une nouvelle authentification Kerberos suffit à prendre en compte la nouvelle politique.
Bonnes pratiques pour prévenir les dérives
Documentez chaque création de FGPP, limitez rigoureusement les groupes cibles, surveillez régulièrement les valeurs de MaxPasswordAge et activez un audit mensuel via script PowerShell pour détecter toute divergence. En CI/CD, intégrez une vérification automatique de la date d’expiration lors du provisioning d’un compte.
Foire aux questions
Un script old‑school modifie la clé Netlogon : est‑ce dangereux ?
Non pour l’utilisateur ; oui pour le compte ordinateur. Désactivez‑le ou mettez à jour la valeur pour rester cohérent.
Est‑il possible d’appliquer plusieurs FGPP à un même utilisateur ?
Non. Si plusieurs FGPP s’appliquent, seule celle dont l’attribut Precedence est le plus bas (priorité la plus haute) sera effective.
Puis‑je conserver la FGPP mais neutraliser son effet sur certains comptes ?
Oui : retirez simplement ces comptes ou groupes de l’attribut AppliesTo, ou créez une FGPP plus permissive avec une priorité plus haute (valeur numérique plus basse).
Conclusion
Quand l’alerte d’expiration de mot de passe apparaît après seulement quarante jours alors que la norme de domaine prévoit 365 jours, le coupable est presque toujours une Fine‑Grained Password Policy oubliée. En suivant le diagnostic présenté – recensement des FGPP, analyse des appartenances, mesure de la politique effective – puis en adaptant ou supprimant la FGPP, vous ramènerez le cycle d’expiration aux valeurs attendues. Pensez enfin à consigner chaque changement et à automatiser la supervision : la cohérence d’une infrastructure Active Directory repose sur une gouvernance documentée et un contrôle continu.