Vous ne parvenez plus à ouvrir une session sur le portail Azure / Microsoft Entra ID ? Ce guide explique le message « may be incorrect », liste les causes probables (MFA, locataire, compte, CA, synchronisation), et propose un plan d’action rapide, des commandes et une check‑list pour rétablir l’accès en toute sécurité.
Sommaire
Impossibilité de se connecter au portail Azure : vue d’ensemble
Le message d’erreur indiquant que l’adresse e‑mail « may be incorrect » (« peut être incorrecte ») prête souvent à confusion, surtout lorsqu’on est soi‑même administrateur. En réalité, il s’agit d’une formulation volontairement prudente : les pages d’authentification évitent de révéler si un compte existe, si un mot de passe est juste, ou si le locataire est valide, afin d’empêcher l’énumération de comptes par des acteurs malveillants. Cette prudence masque donc des causes très différentes que nous allons démêler ci‑dessous.
Symptômes typiques
- Boucle de connexion ou renvoi systématique vers l’écran de saisie de l’e‑mail.
- Message « Votre compte peut être incorrect » ou « contacter votre administrateur ».
- MFA impossible à valider (appareil perdu, application non appairée, SMS non reçu).
- Connexion possible sur d’autres services, mais pas sur le
portal.azure.com. - Compte administrateur qui n’apparaît plus dans l’annuaire du locataire.
Tableau de diagnostic : problèmes fréquents et correctifs
| Problème potentiel | Explications | Mesures correctives recommandées |
|---|---|---|
| Compte désactivé, expiré ou supprimé | Licence retirée, suspension, suppression manuelle, ou fin d’essai (produits/abonnements). Les comptes supprimés restent récupérables pendant 30 jours. | Vérifier l’état du compte dans Azure AD / Microsoft Entra ID > Utilisateurs. Restaurer depuis la corbeille si possible, puis réattribuer les rôles/licences. |
| Compte verrouillé pour raisons de sécurité | Trop d’essais infructueux, signaux de risque, ou stratégie automatique de blocage. | Attendre la fin du verrouillage (environ 30 minutes) ou demander un déverrouillage via le support. Examiner les Sign‑in logs et Identity Protection. |
| Identifiants non reconnus / caches | Un cache MSAL/SSO ou un cookie erroné peut injecter de mauvaises informations. Confusion entre UPN (identifiant) et alias d’e‑mail. | Vider les cookies/sessions, essayer en navigation privée, tester un autre navigateur/poste. Saisir l’UPN complet, par ex. user@tenant.onmicrosoft.com ou prenom.nom@domaine-verifie.com. |
| Synchronisation de mot de passe | Mot de passe modifié côté local (AD) ou alias/UPN changé, mais non propagé dans le cloud (latence ou erreur de synchronisation). | Forcer la synchro (Azure AD Connect), contrôler les alertes de synchronisation, ou réinitialiser le mot de passe côté cloud selon la stratégie. |
| MFA mal configurée | L’authentification multifacteur est requise mais l’enregistrement est incomplet (nouveau téléphone), ou la méthode (app, SMS, FIDO2) est indisponible. | Vérifier/mettre à jour les Authentication methods dans Entra ID > Security. Ré‑enregistrer l’appareil/app, ou utiliser un bypass temporaire selon la gouvernance. |
| Mauvais locataire (tenant) | Le navigateur pointe vers un autre annuaire (multi‑tenant, comptes invités, contextes professionnels/perso). | Sélectionner le locataire correct dans le menu de profil du portail. Accès direct possible via https://portal.azure.com/#@<tenant>.onmicrosoft.com. |
| Stratégie Conditional Access (CA) | Une règle peut bloquer l’accès au « Management » (Azure Portal) ou exiger un appareil conforme/lieu approuvé. | Auditer les stratégies CA : session bloqueuse, Require device compliance, Sign‑in risk, Authentication strength. Adapter l’étendue/les exclus. |
| Security Defaults / durcissement MFA | Les Security Defaults imposent la MFA. Si l’enregistrement MFA n’est pas fait, la connexion échoue. | Finaliser l’enregistrement MFA (My Sign‑Ins / Additional security verification) ou remplacer par une stratégie CA correctement cadrée. |
| Domaine fédéré / ADFS / IdP externe | Pour les domaines fédérés, une panne ADFS/IdP ou un certificat expiré coupe l’authentification. | Vérifier la fédération, l’état ADFS/IdP, les certificats, et le basculement temporaire vers managed si prévu par le plan de continuité. |
| Restriction d’accès par réseau/IP | CA par emplacements nommés, proxy d’entreprise, pare‑feu filtrant certaines URL d’authentification. | Tester depuis un autre réseau (4G), autoriser les endpoints requis, valider que le proxy ne modifie pas les requêtes. |
| Suspension liée à la facturation | Abonnement suspendu ou quotas dépassés ; certains accès administratifs peuvent être limités. | Régulariser la facturation et réactiver l’abonnement, puis réessayer. |
Plan d’action rapide
- Confirmer l’existence et l’état du compte
Dans Azure AD / Entra ID > Utilisateurs, rechercher l’UPN : statut Actif, Désactivé ou Supprimé (corbeille 30 jours). - Forcer un essai hors cache
Se déconnecter de tous les comptes Microsoft dans le navigateur, vider les cookies, ouvrir une fenêtre privée, puis retenter avec l’UPN complet. - Tester côté CLI
az login(sans extension) et sélectionner le locataire ; ou cibler l’utilisateur :az login --username <UPN>
Observer le message retourné : compte introuvable, MFA requise, etc. - Réinitialiser le mot de passe
Si la politique le permet, lancer une réinitialisation (self‑service ou admin) et retenter la connexion. - Vérifier/relier la MFA
Dans Security > Authentication methods, supprimer l’appareil obsolète et ré‑enregistrer (App Authenticator, SMS, clé FIDO2). - Si blocage persiste
Contrôler les Sign‑in logs et les politiques Conditional Access. Au besoin, ouvrir un ticket support pour un déverrouillage/admin de secours.
Pourquoi « may be incorrect » ? Les messages restent intentionnellement ambigus pour ne pas confirmer l’existence d’un compte ni la validité d’un mot de passe. Ils couvrent plusieurs hypothèses : mauvais locataire, UPN inconnu, compte supprimé, MFA inachevée ou accès bloqué par une règle.
Diagnostic approfondi : méthode pas à pas
Vérifier le bon locataire
- Si vous appartenez à plusieurs organisations, ouvrez le portail avec un suffixe :
https://portal.azure.com/#@<tenant>.onmicrosoft.com. - Dans le portail, cliquez sur l’avatar en haut à droite : confirmez Nom du locataire et Tenant ID. Basculer si nécessaire.
- Cas B2B invité : un compte invité peut être supprimé dans un tenant tout en existant encore dans un autre. Réinviter si besoin.
Confirmer l’utilisateur et ses attributs
- Différencier UPN (identifiant de connexion) et alias e‑mail. Un changement d’alias n’implique pas automatiquement un changement d’UPN.
- Vérifier accountEnabled, les rôles, et la licence assignée (certaines fonctionnalités peuvent être conditionnées).
- Si supprimé, restaurer depuis la corbeille (Users > Deleted users) puis réassigner les rôles.
Analyser les journaux de connexion
- Ouvrir Sign‑in logs et filtrer par User. Regarder Result, Conditional Access, Authentication requirement, Location.
- Si CA applique « Block » ou « Require compliant device », vérifier l’étendue (Assignments) et les Exclusions pour les comptes de secours.
- Consulter Audit logs (suppression/disable d’utilisateur) et Identity Protection (risques, blocages automatiques).
Valider la MFA et les méthodes d’authentification
- Supprimer les enregistrements obsolètes (ancien téléphone), ré‑enregistrer l’application d’authentification, ajouter une méthode de secours (SMS, e‑mail d’urgence, clé FIDO2).
- Si Security Defaults est activé, finaliser l’inscription MFA avant toute autre action.
Contrôler la synchronisation et la fédération
- Azure AD Connect : surveiller les erreurs de synchronisation, vérifier que la Password Hash Sync fonctionne (ou que l’authentification PTA/ADFS est opérationnelle).
- Domaines fédérés : certifs ADFS, reachabilité de l’IdP, horloge, et claims nécessaires.
Vérifier le réseau et l’environnement
- Tester hors proxy/filtrage (4G). Certains proxys rompent les flux d’auth (device auth, WS-Trust, OAUTH2).
- Contrôler l’heure et le fuseau de la machine (échec possible de TLS/jetons si dérive importante).
- Essayer un autre navigateur (Edge/Chrome/Firefox) en navigation privée pour neutraliser les sessions MSAL.
Interpréter les codes d’erreur AADSTS courants
Les codes AADSTS aident à cibler la cause. Voici un mémo utile :
| Code | Signal | Piste de résolution |
|---|---|---|
AADSTS50034 | Utilisateur introuvable | UPN erroné, mauvais locataire, compte supprimé. Vérifier l’existence et le tenant. |
AADSTS50126 | Identifiants invalides | Réinitialiser le mot de passe, vérifier la synchro et l’UPN. |
AADSTS50079 / AADSTS50076 | MFA/forte authentification requise | Compléter l’enregistrement MFA, vérifier les méthodes et les stratégies CA. |
AADSTS53000 | Condition d’accès non satisfaite | Appareil non conforme, emplacement non approuvé, session bloquée. Ajuster CA. |
AADSTS50158 | IdP externe requis/injoignable | Vérifier la fédération/ADFS, le routage et les certifs. |
AADSTS90072 | Utilisateur hors locataire | Basculer de tenant ou inviter le compte dans le bon locataire. |
Commandes utiles pour gagner du temps
Azure CLI
# Connexion interactive puis sélection du locataire
az login
az account tenant list
az account tenant set --tenant <TenantID>
# Test ciblé d’un UPN
az login --username <[user@domaine.com](mailto:user@domaine.com)>
# Lister les abonnements visibles
az account list --output table PowerShell Microsoft Graph
# Installer le module si besoin
Install-Module Microsoft.Graph -Scope CurrentUser
# Connexion avec le bon scope
Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"
# Rechercher l’utilisateur
Get-MgUser -UserId [user@domaine.com](mailto:user@domaine.com)
# Lister les utilisateurs supprimés (corbeille)
Get-MgDirectoryDeletedItem -DirectoryObjectClass user
# Restaurer un utilisateur supprimé
Restore-MgDirectoryDeletedItem -DirectoryObjectId PowerShell Azure
# Connexion et vérification du contexte
Connect-AzAccount
Get-AzContext
# Basculer de locataire
Set-AzContext -Tenant
# Vérifier les rôles d’un utilisateur
Get-AzRoleAssignment -SignInName [user@domaine.com](mailto:user@domaine.com) Études de cas rapides
Compte admin supprimé par erreur
Symptôme : « may be incorrect », aucun résultat dans Users. Solution : restaurer depuis Deleted users (dans les 30 jours), réattribuer les rôles (Owner/Global Administrator), forcer la réinitialisation du mot de passe, et valider la MFA.
MFA perdue après changement de téléphone
Symptôme : demande MFA impossible. Solution : utiliser une méthode de secours (SMS/clé FIDO2), sinon un administrateur réinitialise les méthodes MFA et déclenche un nouvel enregistrement.
Blocage par Conditional Access
Symptôme : connexions depuis le portail bloquées mais accès à d’autres apps possible. Solution : identifier la stratégie ciblant « Microsoft Azure Management », valider les conditions (emplacement, appareil conforme), prévoir des exclusions pour comptes de secours et sessions de break‑glass.
Confusion de locataire
Symptôme : l’utilisateur a le même e‑mail dans plusieurs organisations. Solution : ouvrir le portail avec le suffixe #@<tenant>.onmicrosoft.com, puis vérifier que l’abonnement et les rôles existent dans ce tenant.
Check‑list prête à l’emploi
- Le bon locataire est‑il sélectionné ? (Tenant ID/nom affiché dans le portail)
- Le compte existe‑t‑il et est‑il actif ? (sinon, restauration corbeille)
- Le mot de passe est‑il correct et synchronisé ? (self‑service reset ou admin)
- La MFA est‑elle enregistrée et disponible ? (méthode de secours)
- Une stratégie CA bloque‑t‑elle l’accès ? (logs & What If)
- Un réseau/proxy empêche‑t‑il l’auth ? (test 4G, endpoints ouverts)
- Le rôle de l’utilisateur est‑il suffisant ? (Global Admin/Owner si nécessaire)
Bonnes pratiques pour éviter la perte d’accès
- Comptes de secours « break‑glass » : 2 comptes cloud‑only, mots de passe longs, MFA maîtrisée (ou contrôles compensatoires), exclus des stratégies CA critiques, stockés en lieu sûr et testés périodiquement.
- Gouvernance MFA : toujours au moins deux méthodes par compte (app + FIDO2/SMS). Procédure formalisée de réenregistrement.
- Supervision : alertes Identity Protection, rapports de Sign‑in et d’audit, journaux intégrés à un SIEM.
- CA par paliers : commencer en Report‑only, mesurer l’impact, puis appliquer. Conserver des exclusions d’urgence documentées.
- Hygiène des identités : révision périodique des rôles, des comptes inactifs, et des licences. Nettoyage des UPN/alias incohérents.
- Plan de continuité : procédure ADFS/IdP de secours (si fédération), renouvellement automatisé des certificats, tests réguliers.
- Sauvegarde logique : exporter la liste des groupes/attributions de rôles (PowerShell/Graph) pour accélérer une restauration.
FAQ express
Je suis administrateur, pourquoi le portail me dit de contacter un admin ? Parce que le message est générique : il ne distingue pas compte supprimé, blocage CA, MFA manquante ou mauvais locataire. Les étapes ci‑dessus permettent d’identifier le véritable blocage.
<dt>Le message « may be incorrect » signifie‑t‑il que mon e‑mail est faux ?</dt>
<dd>Pas nécessairement. Il peut aussi indiquer que l’UPN n’existe pas dans ce locataire, que le compte est supprimé, ou qu’une stratégie empêche l’authentification.</dd>
<dt>Combien de temps ai‑je pour restaurer un utilisateur supprimé ?</dt>
<dd>Généralement 30 jours depuis la corbeille. Passé ce délai, une restauration peut nécessiter une intervention du support et n’est pas toujours possible.</dd>
<dt>Comment cibler explicitement un locataire donné ?</dt>
<dd>En ajoutant le suffixe tenant à l’URL du portail : <code>https://portal.azure.com/#@<tenant>.onmicrosoft.com</code>, ou via <code>az account tenant set --tenant <TenantID></code> en CLI.</dd>
<dt>J’ai changé d’alias e‑mail et depuis je ne peux plus me connecter</dt>
<dd>Vérifiez l’UPN : il peut être resté à l’ancienne valeur. Demandez la mise à jour de l’UPN ou utilisez l’UPN actuel pour vous connecter.</dd>Annexes : procédures ciblées
Restaurer un compte supprimé
- Ouvrir Users > Deleted users.
- Sélectionner l’utilisateur > Restore user.
- Réaffecter les rôles et licences, puis réinitialiser le mot de passe.
- Valider les méthodes MFA et retester la connexion.
Contour d’urgence si le portail est bloqué
- Utiliser un compte break‑glass pour signer et corriger la politique fautive.
- Recourir à la CLI ou à PowerShell pour changer de locataire, réinitialiser un mot de passe, ou restaurer un utilisateur.
- Si les comptes de secours sont indisponibles, ouvrir un ticket support pour un déblocage administrateur (contrôles d’identité requis).
Résumé opérationnel
En présence du message « may be incorrect », procédez dans cet ordre : (1) confirmer le locataire, (2) valider l’existence/état du compte, (3) tester sans cache et via CLI, (4) réinitialiser le mot de passe et réparer la MFA, (5) auditer les stratégies Conditional Access, (6) rétablir via compte de secours et, si besoin, support. Cette démarche couvre 95 % des cas rencontrés et limite le temps d’indisponibilité.
Ressources internes et pense‑bête
- URL portail ciblé tenant :
https://portal.azure.com/#@<tenant>.onmicrosoft.com - Portails utiles (texte non cliquable) :
entra.microsoft.com,myaccount.microsoft.com,shell.azure.com - Modules :
Microsoft.Graph,Az.Accounts
Crédits de sécurité et terminologie
« Azure AD » est désormais renommé Microsoft Entra ID. Les noms des menus peuvent varier légèrement, mais les principes restent identiques : Users, Sign‑in logs, Audit logs, Security, Authentication methods, et Conditional Access.