Localiser le refus avant de changer les paramètres
Un utilisateur entre son mot de passe, approuve sa MFA, puis reçoit un refus. Cela ne signifie pas automatiquement que son mot de passe est incorrect. Il faut distinguer la preuve d’identité, les conditions d’accès à la ressource et les permissions propres à l’application.
Ce guide propose une démarche ciblée pour Microsoft Entra ID et Microsoft 365. Les exemples sont fictifs. Les commandes consultent les données; aucune ne désactive un compte, une stratégie ou une protection. Une connexion réussie dans Entra ne garantit pas que l’application autorisera ensuite toutes les opérations.
Recueillir un incident reproductible
Noter le compte et le tenant attendus, l’application, la ressource demandée, le client utilisé, le système, le réseau et l’heure exacte avec fuseau. Dans les détails de l’erreur, conserver le code AADSTS, Request ID et Correlation ID lorsqu’ils sont présents. Ne jamais demander le mot de passe, un code MFA ou un jeton.
Déterminer si le problème touche une personne, un appareil, une application ou plusieurs utilisateurs. Consulter l’état des services Microsoft 365 si le périmètre est large. Faire un seul essai contrôlé après avoir recueilli les détails; des tentatives répétées peuvent compliquer les journaux et les mécanismes de verrouillage.
Comparer avec une combinaison autorisée connue : même utilisateur sur un poste géré fonctionnel, ou même application avec un compte de test prévu. Un navigateur privé modifie le contexte de session; ce résultat ne prouve pas à lui seul un problème de cache.
Accéder aux journaux avec les bons droits
Dans Entra ID > Monitoring & health > Sign-in logs, utiliser un rôle de lecture adapté, comme Reports Reader. Les détails Conditional Access peuvent nécessiter des droits supplémentaires. Ne pas attribuer Global Administrator uniquement pour lire un échec.
La rétention native des journaux de connexion est de 7 jours en Free et de 30 jours en P1/P2. Chercher un historique plus ancien dans les destinations d’export déjà configurées. Activer un export maintenant ne recrée pas les événements expirés.
L’extraction des connexions par Microsoft Graph nécessite Entra ID P1 ou P2. Les stratégies Conditional Access nécessitent les licences appropriées, généralement P1; les fonctionnalités fondées sur le risque peuvent exiger P2. Vérifier les droits des utilisateurs concernés, pas seulement ceux de l’administrateur.
Retrouver la bonne tentative
Filtrer par utilisateur et petite fenêtre horaire, puis examiner application et ressource. Vérifier le fuseau présenté par l’interface; utiliser UTC dans les exports et commandes. Corréler les identifiants avec l’heure au lieu de choisir simplement la dernière ligne rouge.
Examiner les connexions interactives et non interactives dans leurs vues respectives. Les actualisations de jetons en arrière-plan peuvent échouer alors qu’une connexion interactive fonctionne. Pour une automatisation, consulter aussi les vues de principaux de service ou d’identités managées pertinentes.
Ouvrir les détails de base, Authentication Details, Device Info et Conditional Access. Conserver le résultat final et les étapes intermédiaires : une interruption demandant une action ne se lit pas comme une panne définitive. L’ingestion peut être différée; répéter la recherche après un délai raisonnable et noter l’heure de collecte.
Lire les codes comme des pistes
50057 : compte désactivé. 50126 : validation des identifiants échouée. 50076 : authentification multifacteur requise. 53000 : appareil non conforme. 53003 : blocage Conditional Access. Lire aussi Failure reason et Additional details; ne pas transformer cette liste en correction automatique.
Un 53003 ne désigne pas nécessairement une stratégie mal configurée : le blocage peut être celui attendu. Un 50076 peut représenter une étape d’interaction à compléter. Vérifier la description actuelle du code chez Microsoft et la séquence complète avant de modifier quoi que ce soit.
MFA réussie, mais accès refusé
Examiner chaque stratégie appliquée, sa portée et le contrôle non satisfait : conformité, type d’appareil, force d’authentification ou application cliente. Le succès MFA ne satisfait pas automatiquement les autres exigences.
Une stratégie en Report-only ne bloque pas elle-même l’accès. Distinguer ses résultats de ceux des stratégies activées. Utiliser What If pour comprendre les affectations, puis valider avec une tentative réelle : une simulation ne remplace pas le contexte effectivement transmis par le client.
Exemple fictif : Alice accède à SharePoint sur son portable géré, mais échoue sur un navigateur qui ne transmet pas l’identité attendue de l’appareil. Comparer les deux événements et les Device ID avant d’exclure Alice de la stratégie.
Vérifier le compte, la méthode et l’application
Confirmer le bon tenant et le bon type de compte, notamment pour un invité. Vérifier l’état activé, l’affectation à l’application, les groupes pertinents et les licences de la charge concernée. Une licence absente peut expliquer le refus du service après authentification.
Pour une identité hybride, identifier la méthode réellement utilisée : synchronisation du hachage, authentification directe ou fédération. Consulter la santé du composant impliqué. Une réinitialisation cloud n’est pas une réponse universelle à un problème provenant de l’annuaire local.
Pour la MFA, examiner la méthode demandée et celle réellement satisfaite. Une nouvelle inscription doit suivre la procédure de vérification d’identité de l’organisation. Ne pas supprimer toutes les méthodes à la demande d’une personne non vérifiée.
Inspecter l’état du poste Windows
Exécuter dsregcmd /status dans la session de l’utilisateur affecté. Examiner AzureAdJoined, DomainJoined, DeviceId et AzureAdPrt selon l’architecture attendue. Comparer DeviceId avec celui du journal de connexion.
Un appareil joint n’est pas nécessairement conforme. Contrôler séparément son état dans Entra et Intune, la dernière synchronisation et les motifs de non-conformité. Un champ vide dans le journal peut aussi refléter un client qui ne fournit pas cette information.
Ne pas lancer dsregcmd /leave, supprimer le compte machine ou réinscrire le poste comme premier essai. Ces changements peuvent affecter l’accès, les certificats et la récupération. Protéger les sorties de diagnostic qui contiennent des identifiants internes.
dsregcmd /statusCollecter une fenêtre avec Graph PowerShell
Utiliser Microsoft.Graph.Reports avec un consentement approuvé pour AuditLog.Read.All et un rôle compatible comme Reports Reader. Le bloc utilise un identifiant utilisateur fictif et une fenêtre UTC; -All parcourt les pages. Ce relevé v1.0 ne remplace pas toutes les vues de connexions du portail.
Les détails appliedConditionalAccessPolicies peuvent être omis sans les droits de lecture Conditional Access requis. Leur absence ne prouve pas qu’aucune stratégie ne s’applique. Pour une analyse approfondie, faire consulter ces détails par un rôle autorisé plutôt qu’ajouter des droits d’écriture.
Conserver les résultats bruts dans un dossier d’incident à accès limité si un export est nécessaire. Consigner les filtres et les erreurs. Ne pas publier les journaux, adresses IP ou identifiants dans un billet public.
# Microsoft.Graph.Reports; read-only, fictional identifiers
Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome
$uid = '11111111-2222-3333-4444-555555555555'
$filter = "userId eq '$uid' and createdDateTime ge 2026-10-20T12:00:00Z and createdDateTime le 2026-10-20T14:00:00Z"
$events = @(Get-MgAuditLogSignIn -Filter $filter -All -ErrorAction Stop)
$events | Select-Object CreatedDateTime, Id, CorrelationId,
AppDisplayName, ResourceDisplayName, ClientAppUsed,
ConditionalAccessStatus, @{n='ErrorCode';e={$_.Status.ErrorCode}},
@{n='FailureReason';e={$_.Status.FailureReason}},
@{n='DeviceId';e={$_.DeviceDetail.DeviceId}} |
Format-ListCorriger une cause précise et valider
Séparer diagnostic et changement. Décrire la cause étayée, l’état initial, le propriétaire, le périmètre pilote, le résultat attendu et le retour arrière. Corriger une affectation erronée, une conformité défaillante ou un paramètre applicatif identifié; ne pas désactiver globalement MFA ou Conditional Access.
Après la correction, refaire le scénario autorisé et contrôler le nouvel événement. Tester aussi un scénario qui doit rester refusé, avec un compte de test et sans compromettre les données. Vérifier que le service attendu fonctionne réellement, pas seulement que le portail affiche Success.
Si une exception temporaire est indispensable et approuvée, la limiter au strict périmètre, lui attribuer une échéance et un responsable, et surveiller son utilisation. Préserver un accès administratif de récupération conforme à la procédure existante. Revenir à l’état documenté si le pilote ne donne pas le résultat attendu.
Quand escalader et quoi transmettre
Escalader si plusieurs utilisateurs sont touchés, si la cause reste indéterminée ou si des indices de compromission apparaissent. Fournir heure UTC, identifiants de requête/corrélation, tenant, application, ressource, client, code, résultat des stratégies et comparaison avant/après, par un canal approuvé.
Un dossier utile distingue faits observés et hypothèses. Exemple : « MFA satisfaite, accès refusé par exigence de conformité, appareil absent du contexte de cette tentative » est plus exploitable que « la MFA ne fonctionne pas ». Mentionner les limites de rétention ou de permissions.
Un accompagnement Microsoft 365/Entra peut aider à analyser les stratégies et les dépendances sans interrompre les utilisateurs. Ce guide de dépannage complète les guides Conditional Access et comptes compromis; il ne remplace pas un audit complet ni une réponse à incident.
À propos de l’auteur
Marc-Antoine Lambert
Consultant TI senior et Team Lead basé à Montréal, spécialisé en architecture, cybersécurité, infrastructures Microsoft, réseaux et continuité des opérations.
Discuter de votre environnement →