Microsoft 365 – Option « Changer le mot de passe à la première connexion » grisée : causes, impact et contournements (incident MO897396)

La création d’un nouvel utilisateur dans le Centre d’administration Microsoft 365 affiche depuis septembre 2024 une case « L’utilisateur doit changer son mot de passe lors de la première connexion » cochée et impossible à modifier. Découvrez les raisons, les risques et les solutions détaillées.

Option « L’utilisateur doit changer son mot de passe lors de la première connexion » bloquée dans le Centre d’administration Microsoft 365

Problème observé

À partir du 19 septembre 2024, les administrateurs ont constaté qu’au moment de créer un compte dans le portail d’administration Microsoft 365, la case imposant le changement de mot de passe au premier logon :

• s’affiche cochée ;
• est grisée, donc non modifiable ;
• reste bloquée même pour les administrateurs disposant du rôle Global Administrator.

Cette anomalie perturbe les procédures d’on‑boarding : scripts d’automatisation à revoir, délais supplémentaires lors des formations utilisateurs, incompatibilités avec les environnements hybrides Active Directory, etc.

Cause et état du service

Microsoft a ouvert l’incident MO897396 (catégorie Service degradation) dans le Health Center. Les messages publiés les 24 et 25 septembre 2024 indiquent :

• Cause racine : une mise à jour de l’interface d’administration a par erreur forcé cette option et verrouillé son statut.
• Plan d’action : restauration de la version précédente du code puis déploiement mondial progressif.
• Résolution estimée : 26/27 septembre 2024.

Pour suivre l’évolution, consultez l’entrée MO897396 dans Health > Service Health du portail.

Portée

Tous les tenants peuvent être touchés :

• Environnements 100 % cloud (sans Azure AD Connect).
• Environnements hybrides (synchronisation Active Directory).

Les observations terrain montrent toutefois qu’un pourcentage non négligeable de nouveaux comptes n’est finalement pas forcé à changer le mot de passe lors de la première connexion, malgré la case figée. Le comportement varie selon les licences attribuées ou la rapidité d’activation des MFA.

Pourquoi ce bug pose problème ?

Dans de nombreuses organisations, le mot de passe initial est communiqué :

1. par un canal hors bande (courrier interne, SMS, appel téléphonique) ;
2. puis immédiatement renouvelé par l’utilisateur lors du premier logon, en présence ou non du service IT.

Lorsque l’option est imposée de manière indésirable, plusieurs scénarios apparaissent :

• Formations / sessions d’intégration perturbées : l’utilisateur ne peut pas suivre les démonstrations si le changement de mot de passe bloque la session Teams d’accueil.
• Synchronisation AD : si la valeur user must change password at next logon est incohérente entre le cloud et le domaine local, des boucles de réinitialisation peuvent survenir.
• Sécurité : certaines organisations préfèrent un premier logon sans renouvellement immédiat pour laisser le temps d’activer les méthodes MFA avant de choisir un mot de passe définitif.

Contournements recommandés (en attendant le correctif)

Méthode	Détails
1. PowerShell / Graph	Créer l’utilisateur puis exécuter : Set-MgUser -UserId <UPN> -PasswordPolicies None ou, avec le module MSOnline : Set-MsolUserPassword -UserPrincipalName <UPN> -NewPassword <Pwd> -ForceChangePassword $false Astuce : pour traiter un lot complet, bouclez sur un CSV d’UPN et journalisez le résultat.
2. Portail Entra ID (Azure AD)	Dans Entra ID → Utilisateurs, la case reste modifiable avant l’enregistrement. Cette approche convient pour quelques comptes manuels mais s’avère fastidieuse au‑delà.
3. Réinitialisation manuelle	Créez le compte, réinitialisez aussitôt le mot de passe, connectez‑vous une première fois. Dans la majorité des tests, l’utilisateur n’est plus invité à le changer ensuite.
4. Patience	Si l’obligation ne contrarie pas vos process, attendez simplement la correction officielle. Profitez‑en pour renforcer vos scripts et documentations internes.

Mise en œuvre détaillée des contournements

PowerShell avec Microsoft Graph SDK

1. Install-Module Microsoft.Graph -Scope AllUsers

2. Connect-MgGraph -Scopes User.ReadWrite.All, Directory.AccessAsUser.All

3. New-MgUser -AccountEnabled $true -DisplayName "Prénom Nom" -MailNickname "pnom" -UserPrincipalName "pnom@contoso.com" -PasswordProfile @{ Password = "PwdTemp!23"; ForceChangePasswordNextSignIn = $true }

4. Set-MgUser -UserId "pnom@contoso.com" -PasswordPolicies None

Le paramètre -PasswordPolicies None supprime l’obligation du premier changement sans affecter les autres stratégies (MFA, expiration globale…).

PowerShell avec MSOnline (legacy)

1. Install-Module MSOnline -AllowClobber

2. Connect-MsolService

3. Set-MsolUserPassword -UserPrincipalName pnom@contoso.com -NewPassword "PwdTemp!23" -ForceChangePassword $false

Le module MSOnline reste pris en charge mais sera déprécié ; planifiez la migration vers Graph.

Portail Entra ID (anciennement Azure AD)

Dans l’expérience d’administration Entra, la case Require password change on first sign‑in n’a pas été « gelée ». Ce chemin graphique est idéal pour les petites équipes RH qui ne souhaitent pas exécuter de scripts.

Réinitialisation manuelle après création

La méthode est paradoxale mais efficace :

1. Créez l’utilisateur sans vous soucier de la case grisée.
2. Ouvrez immédiatement la fiche d’utilisateur » Réinitialiser le mot de passe.
3. Attribuez un nouveau mot de passe temporaire et décochez la case avant de valider.
4. L’utilisateur peut alors se connecter normalement.

Bonnes pratiques supplémentaires

• Surveillance proactive : configurez des alertes automatisées depuis le Health Center afin d’être notifié par mail ou Teams dès qu’un nouvel incident identités apparaît.
• Scripts idempotents : ajoutez toujours une vérification de l’état ForceChangePasswordNextSignIn après création pour garantir la conformité, même quand l’interface graphique fonctionne.
• Sécurité : si votre procédure d’accueil inclut déjà MFA, envoi hors bande du mot de passe et session de renforcement sécurité, laisser l’option cochée n’est pas un problème et peut même éliminer un risque d’ingénierie sociale.
• Documentation interne : archivez la chronologie de l’incident MO897396 pour justifier vos choix à l’audit annuel.

Vérifications post‑correctif

Une fois Microsoft 365 revenu à la normale :

• Ouvrez la page de création d’utilisateur et assurez‑vous que la case est de nouveau activable/désactivable.
• Supprimez les blocs de contournement temporaires de vos playbooks et pipelines CI/CD (GitHub Actions, Azure DevOps, PowerShell Remoting, etc.).
• Contrôlez un échantillon d’utilisateurs créés durant la période d’incident pour vérifier que leur attribut PasswordPolicies correspond bien à votre politique de sécurité.
• Communiquez en interne la fin de l’incident afin d’éviter la persistance de solutions artisanales.

FAQ rapide

Le correctif annulera‑t‑il mes modifications manuelles ?

Non. Les comptes déjà créés conserveront leur paramètre actuel. Le correctif ne fait que rétablir la possibilité de choisir l’option lors de nouvelles créations.
Pourquoi Microsoft a‑t‑il déployé un code non testé ?

Selon le rapport interne, le scénario impliquant la case ForceChangePasswordNextSignIn dans le portail d’administration n’avait pas été ajouté aux tests automatisés. Les équipes CI/CD ont depuis enrichi le jeu de régressions.
Les API Microsoft Graph ont‑elles été affectées ?

Non. Les API REST n’ont jamais forcé l’option ; seule l’interface graphique web était défaillante.

Leçons apprises et prochaines étapes

MO897396 rappelle la nécessité :

1. d’adopter une approche « Cloud first, Script first » pour pouvoir déployer rapidement des contournements ;
2. de compléter la surveillance Service Health par des tests Synthetic Monitoring maison, capables de détecter les anomalies UX en moins de 15 minutes ;
3. de maintenir une documentation vivante sur les attributs sensibles (PasswordPolicies, ForceChangePasswordNextSignIn, cycles MFA) pour que tout administrateur puisse agir en autonomie le jour où un incident surgit.

En appliquant ces principes, votre organisation réduit la surface d’exposition et assure une continuité de service, même face à des régressions inattendues.

Résumé express

• Bug confirmé : case « changer le mot de passe à la première connexion » figée (incident MO897396).
• Cause : régression dans le code du portail d’administration.
• Correctif Microsoft : déploiement terminé au plus tard le 27 septembre 2024.
• Workarounds : PowerShell/Graph, portail Entra ID, réinitialisation manuelle ou attente du correctif.