Microsoft Entra ID + Active Directory : imposer l’expiration du mot de passe à 180 jours pour un groupe d’utilisateurs (hybride PHS, Intune)

Vous devez imposer l’expiration du mot de passe tous les 180 jours à un sous-ensemble d’utilisateurs dans un environnement hybride Entra ID + AD ? Voici trois approches éprouvées, une procédure pas à pas et des scripts prêts à l’emploi.

Sommaire

Mettre en place une expiration de mot de passe tous les 180 jours pour un sous‑ensemble d’utilisateurs dans un environnement hybride Entra ID + AD

Problématique

Environnement :
- Microsoft Entra ID synchronisé avec un Active Directory on‑prem via AAD Connect (Password Hash Sync).
- Tous les utilisateurs disposent d’une licence Microsoft 365 Business Premium (incluant Azure AD Premium P1 / Entra ID P1 : Accès conditionnel, SSPR, etc.).
- Postes « Microsoft Entra join » gérés par Intune.
Besoin : forcer un changement de mot de passe tous les 180 jours uniquement pour un groupe d’utilisateurs, sans impact pour les autres, avec la notification habituelle côté Microsoft 365/Office apps.

Solutions techniques

Approche	Étapes clés	Avantages	Limites / Points de vigilance
Stratégie de mot de passe affinée (FGPP) dans l’AD local	1) Créer un groupe AD contenant les comptes ciblés. 2) Dans le conteneur Password Settings, créer une PSO/FGPP (MaximumPasswordAge = 180 jours, PasswordHistory, complexité, etc.). 3) Lier la FGPP au groupe. 4) Vérifier que l’attribut `userAccountControl` ne porte pas le flag Password never expires. 5) Laisser AAD Connect synchroniser (PHS). Activer la réécriture de mot de passe si vous voulez autoriser la réinitialisation depuis le cloud.	• Granularité par groupe native. • Pas de modification structurelle côté cloud. • Le prompt M365 s’affiche dès que l’utilisateur doit changer son mot de passe (avec writeback/flux adapté).	• Niveau fonctionnel de domaine ≥ Windows Server 2008 requis. • Les comptes restent « source of authority » on‑prem. • Le paramétrage cloud doit respecter votre modèle (ex. SSPR avec writeback pour que l’expérience soit fluide).
Scénario « cloud‑only » pour les comptes concernés	1) Sortir ces utilisateurs de la synchro (filtrage d’OU ou cloud‑filter d’AAD Connect) ou les recréer en natifs Entra. 2) Dans le centre d’admin Microsoft 365, régler la durée d’expiration globale à 180 jours. 3) Pour les autres comptes purement cloud devant échapper à l’expiration, définir la stratégie `PasswordPolicies` = DisablePasswordExpiration utilisateur par utilisateur (PowerShell/Graph).	• Plus besoin d’AD pour ces comptes à terme. • Gouvernance et audit uniquement dans le cloud.	• Ne convient que si l’AD local n’est plus nécessaire pour ces utilisateurs. • La durée d’expiration est globale dans le tenant ; les exemptions se font cas par cas.
Alternative « rotation logique » sans FGPP	• Laisser les mots de passe « jamais expirés ». • Mettre en place une fréquence d’ouverture de session Accès conditionnel (ex. réauthentification complète tous les 180 jours). • Coupler avec une réinitialisation SSPR obligatoire ou un automatisme Graph qui déclenche ForceChangePasswordNextSignIn à D+180 pour le groupe ciblé.	• Pas de dépendance à l’AD local. • Compatible MFA et Accès conditionnel. • Très flexible (groupes dynamiques, exceptions).	• Ne répond pas aux politiques qui exigent une expiration « hard » au sens AD. • Peut être moins intuitif pour l’utilisateur (réauth + demande de réinitialisation).

Procédure détaillée recommandée : FGPP dans l’AD local (ciblage par groupe)

Quand choisir cette voie ? Si votre AD on‑premise reste la source d’autorité et que vous souhaitez une expiration « hard » pour un sous‑ensemble précis, la FGPP est le meilleur levier : simple, natif, entièrement pilotable par groupe.

Pré‑requis

Niveau fonctionnel de domaine ≥ Windows Server 2008.
Modules PowerShell ActiveDirectory sur une station d’admin ou un contrôleur de domaine.
AAD Connect en mode Password Hash Sync correctement opérationnel.
Optionnel mais fortement recommandé : Password writeback activé dans AAD Connect pour permettre SSPR/changement de mot de passe depuis le cloud, même pour les comptes synchronisés.

Étape 1 : créer le groupe cible

Créez un groupe de sécurité AD qui contiendra uniquement les utilisateurs devant subir l’expiration à 180 jours (n’ajoutez pas de comptes de service).

# Exemples (à adapter : nom, OU, domaine)
New-ADGroup -Name "GG-Password-Expire-180d" `
  -GroupScope Global -GroupCategory Security `
  -Path "OU=Security Groups,DC=contoso,DC=local" `
  -Description "Utilisateurs soumis à une rotation à 180 j"

# Ajout d'utilisateurs

Add-ADGroupMember -Identity "GG-Password-Expire-180d" -Members jdupont, mdupont

Étape 2 : créer la FGPP (Password Settings Object/PSO)

Vous pouvez la créer via le Centre d’administration Active Directory (ADAC) ou en PowerShell :

# Politique affinée : 180 jours, complexité, historique 24, etc.
New-ADFineGrainedPasswordPolicy -Name "FGPP-Expire-180d" `
  -Precedence 100 `
  -MinPasswordLength 14 `
  -PasswordHistoryCount 24 `
  -ComplexityEnabled $true `
  -ReversibleEncryptionEnabled $false `
  -LockoutThreshold 10 `
  -LockoutDuration (New-TimeSpan -Minutes 15) `
  -LockoutObservationWindow (New-TimeSpan -Minutes 15) `
  -MaxPasswordAge (New-TimeSpan -Days 180) `
  -MinPasswordAge (New-TimeSpan -Days 1)

# Lier la FGPP au groupe

Add-ADFineGrainedPasswordPolicySubject -Identity "FGPP-Expire-180d" \`
-Subjects "GG-Password-Expire-180d"

Astuce : si plusieurs PSO s’appliquent, l’attribut Precedence le plus faible l’emporte (1 > 2 > 3…).

Étape 3 : s’assurer que les comptes expirent bien

Sur chaque utilisateur visé, vérifiez que le flag « Password never expires » est désactivé et que la FGPP est bien la résultante.

# Vérifier le flag "PasswordNeverExpires"
Get-ADUser jdupont -Properties PasswordNeverExpires | 
  Select-Object Name, PasswordNeverExpires

# Le désactiver si nécessaire

Set-ADUser jdupont -PasswordNeverExpires \$false

# Vérifier la politique effective (PSO résultante)

Get-ADUser jdupont -Properties msDS-ResultantPSO |
Select-Object Name, msDS-ResultantPSO

Étape 4 : activer/valider le writeback pour une expérience fluide

Avec PHS, l’authentification se fait dans le cloud. Pour que l’utilisateur puisse changer son mot de passe à l’expiration directement depuis l’interface Microsoft 365 (OWA, myaccount, Windows 11 Entra join), il est recommandé d’activer la fonction Password writeback dans AAD Connect et d’autoriser la SSPR pour le groupe cible. Sans writeback, les utilisateurs devront changer leur mot de passe sur un poste joint au domaine ou via un autre canal on‑premise.

Étape 5 : option « enforcement cloud » (à manier avec précaution)

Il existe un paramètre AAD Connect (EnforceCloudPasswordPolicyForPasswordSyncedUsers) qui amène le cloud à appliquer une politique d’expiration aux comptes synchronisés. C’est global au tenant : si vous recherchez un ciblage par groupe, privilégiez la FGPP (et n’activez cette option que si vous avez parfaitement modélisé les exceptions). Gardez en tête :

Cette option fait appliquer une politique d’expiration cloud (durée globale) aux comptes PHS.
Elle n’« importe » pas la granularité de vos FGPP dans le cloud : la sélection par groupe doit rester on‑prem via la FGPP.
Si vous l’activez, vérifiez l’impact sur les comptes qui ne doivent pas expirer (comptes de service synchronisés, etc.).

Étape 6 : tests fonctionnels bout‑en‑bout

Placez 2–3 comptes pilotes dans le groupe FGPP.
Simulez l’expiration : soit en abaissant temporairement MaxPasswordAge à 1 jour, soit en positionnant ChangePasswordAtLogon à $true pour forcer le changement au prochain sign‑in.

# Forcer un changement au prochain logon (simulation)
Set-ADUser jdupont -ChangePasswordAtLogon $true

Sur un poste Entra join, ouvrez une session Office (Outlook/Teams/OWA). Vérifiez que la bannière « Votre mot de passe a expiré » s’affiche et que le changement réussit (via writeback si activé).
Contrôlez les journaux : rapports d’audit Change password côté Azure/Entra ID et journal AAD Connect (password reset/writeback).

Étape 7 : exploitation et opérations

Onboarding/Offboarding : l’ajout/retrait du groupe FGPP déclenche automatiquement l’application ou la levée de la politique.
Communication : informez le cycle (J+170 : rappel, J+180 : blocage / réauth).
Surveillance : suivez les comptes à <10 jours de l’expiration et les échecs de writeback.

Scripts PowerShell prêts à l’emploi

Créer et lier une FGPP de 180 jours

# Paramètres
$PolicyName = "FGPP-Expire-180d"
$GroupName  = "GG-Password-Expire-180d"

# 1) Crée le groupe s'il n'existe pas

if (-not (Get-ADGroup -Filter "Name -eq '\$GroupName'" -ErrorAction SilentlyContinue)) {
New-ADGroup -Name \$GroupName -GroupScope Global -GroupCategory Security `    -Path "OU=Security Groups,DC=contoso,DC=local"`
-Description "Rotation 180 jours"
}

# 2) Crée la FGPP si besoin

if (-not (Get-ADFineGrainedPasswordPolicy -Filter "Name -eq '\$PolicyName'" -ErrorAction SilentlyContinue)) {
New-ADFineGrainedPasswordPolicy -Name \$PolicyName `    -Precedence 100 -MinPasswordLength 14 -PasswordHistoryCount 24`
-ComplexityEnabled \$true -ReversibleEncryptionEnabled \$false `    -LockoutThreshold 10`
-LockoutDuration (New-TimeSpan -Minutes 15) `    -LockoutObservationWindow (New-TimeSpan -Minutes 15)`
-MaxPasswordAge (New-TimeSpan -Days 180) \`
-MinPasswordAge (New-TimeSpan -Days 1)
}

# 3) Lier la FGPP au groupe

Add-ADFineGrainedPasswordPolicySubject -Identity \$PolicyName -Subjects \$GroupName

Rapport des utilisateurs sous FGPP + jours restants

Ce rapport calcule un indicateur simple à partir de l’historique de changement de mot de passe et de la FGPP appliquée :

# Récupère tous les membres du groupe cible et calcule l'échéance à 180 j
$GroupName = "GG-Password-Expire-180d"
$Users = Get-ADGroupMember $GroupName -Recursive | Where-Object {$_.objectClass -eq "user"} |
         ForEach-Object { Get-ADUser $_.DistinguishedName -Properties DisplayName, pwdLastSet, msDS-ResultantPSO }

\$Report = \$Users | Select-Object \`
@{n="User";e={\$*.SamAccountName}},
@{n="DisplayName";e={\$*.DisplayName}},
@{n="ResultantPSO";e={\$*.'msDS-ResultantPSO'}},
@{n="LastPwdChange";e={\[DateTime]::FromFileTime(\$*.pwdLastSet)}},
@{n="DaysSinceChange";e={(New-TimeSpan -Start (\[DateTime]::FromFileTime(\$*.pwdLastSet)) -End (Get-Date)).Days}},
@{n="DaysToExpire(180d)";e={180 - ((New-TimeSpan -Start (\[DateTime]::FromFileTime(\$*.pwdLastSet)) -End (Get-Date)).Days)}}

\$Report | Sort-Object "DaysToExpire(180d)" | Format-Table -AutoSize

Exemptions cloud‑only et automatisation Graph

Pour les comptes purement cloud à exempter de l’expiration globale, vous pouvez utiliser Microsoft Graph PowerShell :

# Connexion Graph (droits suffisants requis)
Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.ReadWrite.All"

# Désactiver l'expiration sur un compte cloud-only

Update-MgUser -UserId "[alice@contoso.com](mailto:alice@contoso.com)" -PasswordPolicies "DisablePasswordExpiration"

# Forcer le changement au prochain sign-in (utile dans l'approche "rotation logique")

Update-MgUser -UserId "[bob@contoso.com](mailto:bob@contoso.com)" -PasswordProfile @{ ForceChangePasswordNextSignIn = \$true }

# Récupérer la date du dernier changement de mot de passe (pour planification D+180)

(Get-MgUser -UserId "[alice@contoso.com](mailto:alice@contoso.com)" -Property "id,displayName,lastPasswordChangeDateTime").lastPasswordChangeDateTime

Mettre en œuvre le scénario « cloud‑only » pour un sous‑ensemble

Ce scénario vise les utilisateurs qui n’ont plus besoin des ressources on‑prem (Kerberos/NTLM, partages de fichiers non publiés, applications LDAP, etc.). La gestion bascule intégralement dans Entra ID/Microsoft 365.

Décorréler du provisioning on‑prem

Exclure les utilisateurs concernés de la portée AAD Connect : filtrage d’OU ou règle « cloud‑filter ».
Laisser passer une synchronisation delta. Les objets seront marqués « supprimés » côté cloud (Corbeille Entra). Option : restaurez‑les ensuite pour qu’ils deviennent cloud‑only avec la même identité (UPN).
Vérifiez que tout writeback n’est plus nécessaire pour eux (puisqu’ils ne reviennent plus vers l’AD).

Appliquer l’expiration uniquement à ce sous‑ensemble

Réglez la durée d’expiration globale du tenant à 180 jours.
Pour tout autre compte cloud‑only à exclure, affectez la stratégie PasswordPolicies=DisablePasswordExpiration (voir script ci‑dessus). Note : les comptes synchro ne sont pas concernés par ce levier ; gérez‑les on‑prem.

Alternative « rotation logique » sans FGPP

Si une expiration « hard » n’est pas imposée réglementairement, vous pouvez simuler un cycle de 180 jours côté cloud tout en gardant des mots de passe « jamais expirés » :

Créez une stratégie d’Accès conditionnel ciblant le groupe d’utilisateurs concernés :
- Conditions : Users = groupe Rotation‑180, Cloud apps = All cloud apps (sauf exceptions).
- Contrôles de session : Sign‑in frequency = 180 jours (réauth complète).
Déployez la SSPR (Self‑Service Password Reset) avec writeback pour ce groupe.
Automatisez via un runbook/Logic App l’inspection de lastPasswordChangeDateTime et déclenchez ForceChangePasswordNextSignIn lorsque 180 jours sont écoulés (ciblage par groupe).

Résultat : les utilisateurs sont périodiquement déconnectés et amenés à réinitialiser leur mot de passe, sans FGPP on‑prem et avec une granularité 100 % cloud.

Comparatif d’aide au choix

Critère	FGPP on‑prem	Cloud‑only	Rotation logique
Ciblage par groupe	Excellent (natif)	Exemptions au compte	Excellent (Accès conditionnel)
Conformité « expiration hard »	Oui	Oui (globale tenant)	Non (équivalent fonctionnel)
Dépendance à l’AD	Oui	Non	Non
Complexité opérationnelle	Faible	Moyenne (exclusions)	Moyenne (automatisation)
Expérience utilisateur	Native, familière	Native M365	Réauth + SSPR

Recommandations pratiques

Choisir la FGPP si l’AD on‑prem reste indispensable ; c’est la méthode la plus simple et la plus fiable pour cibler un groupe.
Tester sur un groupe pilote : s’assurer que la bannière « Votre mot de passe a expiré » apparaît dans Microsoft 365 et que la synchronisation AAD Connect ne rencontre pas d’erreurs.
Documenter la procédure d’ajout/retrait d’utilisateurs dans le groupe FGPP (script PowerShell, automatisation Intune/Entra ID Governance).
Communiquer : informer les utilisateurs du nouveau cycle de 180 jours et des moyens de réinitialiser leur mot de passe (SSPR, portail myaccount, procédure IT).
Surveiller : rapports Azure/Entra ID > Audit Change password, journal d’AAD Connect et vérification périodique des comptes à <10 jours de l’échéance.

Informations complémentaires utiles

Le réglage DisablePasswordExpiration est généralement appliqué par défaut aux comptes synchro. Si vous voulez une politique d’expiration cloud pour ces comptes, évaluez l’option EnforceCloudPasswordPolicyForPasswordSyncedUsers (effet global, à étudier selon vos exceptions).
Microsoft recommande aujourd’hui MFA + mots de passe robustes et l’abandon de l’expiration périodique, sauf contrainte réglementaire. Si une rotation reste exigée, la FGPP permet un ciblage sans ambiguïté.
Si vous envisagez de supprimer l’AD local, planifiez une migration globale (authentification cloud, décommission d’AAD Connect) avant de basculer définitivement les politiques.
Pour les postes Entra join : l’utilisateur peut changer son mot de passe via Paramètres > Comptes > Options de connexion ou via le portail web. Le writeback assure la cohérence avec l’AD on‑prem.
Comptes de service : excluez‑les explicitement de toute FGPP d’expiration et utilisez des secrets managés (Managed Identities, comptes gérés de groupe/gMSA) quand c’est possible.

FAQ et pièges courants

La FGPP s’applique‑t‑elle immédiatement ?
Oui, mais l’expiration découle de pwdLastSet. Un compte dont le mot de passe a été changé récemment n’expirera qu’à J+180. Pour tester, forcez ChangePasswordAtLogon ou réduisez temporairement MaxPasswordAge.

Pass‑through Authentication (PTA) vs Password Hash Sync (PHS) ?
Avec PTA, l’AD on‑prem fait foi lors de l’authentification en ligne, et l’expiration AD est immédiatement honorée. Avec PHS, l’auth se fait dans le cloud : d’où l’intérêt du writeback et d’un modèle d’expérience aligné.

Et si un utilisateur est souvent hors‑ligne ?
L’expiration sera appliquée au prochain renouvellement de jeton (réauth) ou lors de la première connexion réseau. Prévoyez une communication claire et des canaux SSPR pour éviter les blocages.

Comment gérer les exceptions temporaires ?
Retirez l’utilisateur du groupe FGPP pour suspendre l’expiration future, ou, côté cloud‑only, appliquez temporairement DisablePasswordExpiration. Notez que retirer l’utilisateur n’annule pas une expiration déjà atteinte : changez d’abord le mot de passe.

Dois‑je utiliser des groupes dynamiques ?
C’est possible dans Entra ID (cloud‑only). On‑prem, la FGPP ne sait lier qu’à des groupes classiques. Vous pouvez néanmoins alimenter automatiquement ce groupe via des règles HRIS/SCIM ou des scripts périodiques.

Checklist de déploiement

Valider le périmètre : comptes humains seulement, pas de comptes de service.
Créer le groupe AD cible et la FGPP (PSO) à 180 jours.
Lier la FGPP au groupe, vérifier PasswordNeverExpires = $false.
Activer SSPR + writeback pour une expérience de changement directement depuis Microsoft 365.
Effectuer un pilote (2–3 comptes) : simulation d’expiration, vérification des bannières et du writeback.
Mettre à jour la documentation IT et la communication utilisateurs.
Surveiller l’audit et produire un rapport mensuel des jours restants avant expiration.

État de la discussion d’origine

La seule réponse publiée a redirigé l’auteur vers le forum Microsoft Q&A / Entra ID pour obtenir l’aide d’un ingénieur spécialisé. Aucune solution technique n’a donc été fournie dans le fil initial ; les options et la procédure ci‑dessus constituent la synthèse et l’enrichissement nécessaires.

Annexe : modèles de communication utilisateur

J‑10 : « Votre mot de passe expirera dans 10 jours. Vous pouvez le changer dès maintenant depuis votre profil Microsoft 365 ou via Ctrl+Alt+Suppr > Modifier un mot de passe (si poste joint au domaine). »

J‑0 : « Votre mot de passe a expiré. Suivez l’assistant pour définir un nouveau mot de passe. Si vous n’y parvenez pas, utilisez la procédure SSPR. »

Annexe : gouvernance et conformité

Conservez les rapports Change password et les journaux AAD Connect pendant la période d’audit exigée.
Couplez l’expiration avec des règles de composition (longueur, complexité) cohérentes avec votre politique SSI.
Ajoutez une exigence MFA systématique lors des réauthentifications et des changements de mot de passe.

En résumé : dans un environnement hybride Entra ID + AD avec PHS, la méthode la plus robuste pour cibler un groupe spécifique reste la FGPP on‑prem, complétée par la SSPR avec writeback pour une expérience simple. Les scénarios cloud‑only et la « rotation logique » offrent des alternatives modernes lorsque l’AD n’est plus central ou que l’on souhaite rester 100 % dans le cloud.

Microsoft Entra ID + Active Directory : imposer l’expiration du mot de passe à 180 jours pour un groupe d’utilisateurs (hybride PHS, Intune)

Mettre en place une expiration de mot de passe tous les 180 jours pour un sous‑ensemble d’utilisateurs dans un environnement hybride Entra ID + AD