Microsoft Entra ID : le plan d'identité

Épistémologie DFIR : la frontière d'identité

Dans le cloud, l’identité constitue le seul et unique périmètre. Il n’existe aucun pare-feu réseau isolant vos données SaaS du monde extérieur. Si un acteur malveillant dérobe un jeton ou un identifiant Entra ID, l’ensemble des ressources accessibles par cette identité est directement exposé sur l’Internet public.

Concept

Microsoft Entra ID (anciennement Azure Active Directory) est le plan centralisé de gestion des identités et des accès (IAM) régissant Microsoft 365, Microsoft Azure et des milliers d’applications SaaS d’entreprise fédérées.

Contrairement aux services de domaine Active Directory on-premises (AD DS) — qui reposent sur une hiérarchie LDAP, des tickets Kerberos et des appels RPC propriétaires (Fiche 38 : pont AD vers entra) — Entra ID est un annuaire cloud plat, multi-tenant et piloté par des API REST. Il met en œuvre les standards d’authentification moderne :

• OAuth 2.0 : cadre d’autorisation émettant des jetons d’accès (Access Tokens) aux étendues (scopes) limitées.
• OpenID Connect (OIDC) : couche d’identité sur OAuth 2.0 émettant des jetons d’identité (ID Tokens) signés cryptographiquement.
• SAML 2.0 & WS-federation : protocoles de fédération d’entreprise pour l’authentification unique (SSO).

Chaque frontière de sécurité, tentative d’accès, politique d’accès conditionnel et attribution de rôle dans Microsoft 365 est arbitrée au sein de ce plan d’identité.

+---------------------------------------------------------------------------------------------------+
|                                MOTEUR D'IDENTITÉ MICROSOFT ENTRA ID                               |
|                                                                                                   |
|   +-------------------------------------------------------------------------------------------+   |
|   |                                SCHÉMA D'OBJETS D'ANNUAIRE                                 |   |
|   |   Utilisateurs membres | Invités (B2B) | Identités de charge (Apps & Service Principals)       |   |
|   |   Groupes de sécurité | Groupes unifiés M365 | Appareils (Inscrits, Joints, Hybrides)         |   |
|   +---------------------------------------------+---------------------------------------------+   |
|                                                 |                                                 |
|                                                 v                                                 |
|   +-------------------------------------------------------------------------------------------+   |
|   |                       MOTEUR DE POLITIQUES D'ACCÈS CONDITIONNEL                           |   |
|   |   SIGNAUX : Identité | IP / Emplacement nommé | Conformité appareil | Contexte | Risque   |   |
|   |   DÉCISION : Bloquer | Accorder (MFA, Appareil conforme, Jointure hybride, Réinit MDP)    |   |
|   +---------------------------------------------+---------------------------------------------+   |
|                                                 |                                                 |
|                                                 v                                                 |
|   +-------------------------------------------------------------------------------------------+   |
|   |                            ÉMISSION DES JETONS & PREUVES FORENSIQUES                      |   |
|   |   Primary Refresh Tokens (PRT) | Jetons d'Accès OAuth 2.0 (JWT) | Cookies ESTSAUTH        |   |
|   +---------------------------------------------+---------------------------------------------+   |
|                                                 |                                                 |
|                                                 v                                                 |
|   +-------------------------------------------------------------------------------------------+   |
|   |                            CONSOMMATION PAR LES WORKLOADS                                 |   |
|   |   Exchange Online | SharePoint Online / OneDrive | Microsoft Teams | API Microsoft Graph  |   |
|   +-------------------------------------------------------------------------------------------+   |
+---------------------------------------------------------------------------------------------------+

---

Pourquoi c’est important en DFIR

Pour l’analyste forensique, Entra ID représente la source de vérité première pour :

1. Reconstituer l’accès initial : déterminer si l’attaquant a opéré par password spraying, rejeu de mot de passe, hameçonnage ou vol de session (Fiche 19 : Kill Chain).
2. Identifier et suivre les sessions : lier des adresses IP, des User-Agents et des identifiants d’appareils (DeviceId) à la durée de vie des jetons.
3. Analyser le contournement des politiques : comprendre pourquoi le MFA s’est ou ne s’est pas déclenché lors d’une connexion suspecte.
4. Exploiter la télémétrie de risque : analyser les détections d’anomalies levées par Entra ID Protection (ex. Adresse IP anonyme, Voyage atypique, Navigateur suspect).
5. Débusquer les portes dérobées : identifier les applications d’entreprise malveillantes, les certificats applicatifs clandestins ou les méthodes MFA secondaires ajoutées par l’attaquant (Fiche 29 : Persistance OAuth et Fiche 30 : Méthodes d’Auth).

---

Comment ça fonctionne

1. Objets clés et hiérarchie d’annuaire

• Le tenant (TenantId) : conteneur racine représenté par un GUID immuable.
• Objets utilisateurs : identifiés par leur ObjectId (GUID immuable) et leur UserPrincipalName (UPN de connexion, ex. victime@entreprise.fr).
• Objets appareils :
  • Entra Registered : terminaux personnels (BYOD) enregistrés pour l’accès aux ressources.
  • Entra Joined : postes professionnels joints exclusivement à l’annuaire cloud Entra ID.
  • Microsoft Entra Hybrid Joined : postes joints au domaine Active Directory on-premises et synchronisés dans le cloud.
• Identités de charge de travail (workload identities) :
  • Inscriptions d’applications (App Registrations) : définition globale et configuration de l’application.
  • Applications d’Entreprise (Service Principals) : instance locale et principal de sécurité de l’application au sein du tenant (Fiche 03 : comptes & rôles).

2. Le moteur d’accès conditionnel

L’accès conditionnel fonctionne comme un filtre en temps réel lors de l’authentification :

• Signaux d’entrée :
  • Identité : utilisateur, groupes, rôles d’administration assignés.
  • Emplacement Réseau : adresses IP publiques, emplacements nommés de confiance, pays.
  • État de l’Appareil : plateforme OS, conformité Intune, jointure hybride.
  • Application Ciblée : application SaaS sollicitée (Office 365, portail Azure).
  • Niveau de Risque : risque utilisateur et risque de connexion calculés par Entra ID Protection.
• Contrôles appliqués : bloquer l’accès, ou accorder sous réserve d’un contrôle (exiger le MFA, exiger un appareil conforme, exiger la réinitialisation du mot de passe).

3. Jetons et durée de vie des sessions

• Primary refresh token (PRT) : jeton émis sur les postes joints à Entra, sécurisé dans le module TPM du matériel. Il assure le SSO sans sollicitation MFA répétée.
• Refresh token : jeton OAuth permettant de renouveler silencieusement les jetons d’accès.
• Access token : jeton JSON Web Token (JWT) de courte durée (60 à 90 minutes) contenant les revendications (upn, oid, roles, scp, ipaddr) présenté aux workloads dans l’en-tête HTTP Authorization: Bearer.

---

Ce qui est possible

Grâce à l’investigation du plan d’identité Entra ID, l’analyste peut :

• Distinguer les flux d’authentification : différencier les connexions interactives via navigateur, les rafraîchissements non-interactifs en arrière-plan et les appels des service principals (Fiche 09 : Sign-in Logs).
• Détecter les vols de session : identifier le rejeu d’une session depuis une adresse IP inconnue sans déclenchement de challenge MFA.
• Auditer l’évaluation des politiques : vérifier exactement quelles règles d’accès conditionnel ont été appliquées, contournées ou ignorées lors de chaque connexion.
• Traquer les actions administratives : savoir qui a créé, modifié ou supprimé un compte, un rôle ou un secret d’application (Fiche 10 : Audit Logs).

---

Ce qui n’est pas possible

• Aucun suivi applicatif interne : entra ID indique qu’un jeton d’accès pour Exchange a été émis ; il ne dit pas quels messages ont été consultés.
• Aucune récupération de mots de passe : les mots de passe ne sont pas stockés en clair ; l’analyste ne peut pas reconstituer le mot de passe saisi.
• Aucune rétroactivité sans archivage : les journaux de connexion disparaissent au bout de 7 jours (Free) ou 30 jours (P1/P2) sans export externe configuré.

---

Conditions nécessaires

• Niveau de licence :
  • Entra ID Free : journaux conservés 7 jours, pas d’accès conditionnel basé sur le risque.
  • Entra ID P1 : journaux conservés 30 jours, Accès Conditionnel standard.
  • Entra ID P2 : identity Protection complet (Risque utilisateur et de connexion en temps réel), PIM.
• Rôles requis : Global Reader ou Security Reader + Reports Reader (Fiche 05 : Global Reader).

---

Artefacts et journaux

Flux de Journalisation	Ressource Graph / Portail	Contenu Forensique	Champs Clés
Connexions interactives	/auditLogs/signIns	Authentification directe de l’utilisateur.	ipAddress, location, clientAppUsed, conditionalAccessStatus, mfaDetail
Connexions non-interactives	/auditLogs/signIns	Renouvellement silencieux de jetons.	originalRequestId, resourceDisplayName, appId, correlationId
Connexions service principals	/auditLogs/signIns	Authentification d’applications et de daemons.	servicePrincipalId, servicePrincipalName, resourceDisplayName
Journaux d’audit d’annuaire	/auditLogs/directoryAudits	Altération d’objets, rôles et paramètres.	activityDisplayName, initiatedBy, targetResources, additionalDetails
Détections de risque	/identityProtection/riskDetections	Alertes heuristiques et algorithmiques de menace.	riskType, riskLevel, riskState, detectionTimingType

---

Méthodologie d’investigation

1. Résolution de l’identité cible : Récupérer l’identifiant immuable ObjectId correspondant à l’adresse de l’utilisateur :

   Get-MgUser -UserId "victime@entreprise.fr" | Select-Object Id, UserPrincipalName, AccountEnabled

2. Extraction des connexions de la période suspecte : Interroger les connexions interactives et non interactives :

   Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'victime@entreprise.fr' and createdDateTime ge 2026-09-01T00:00:00Z" `
     -All | Select-Object CreatedDateTime, IpAddress, Location, AppDisplayName, Status, ConditionalAccessStatus

3. Analyse du détail de l’authentification : Vérifier le tableau AuthenticationDetails pour confirmer si un second facteur a été réellement validé ou si la session découle d’un jeton préexistant.

4. Vérification de l’accès conditionnel : Examiner AppliedConditionalAccessPolicies pour identifier si une règle a dispensé l’attaquant du MFA (ex. réseau de confiance mal configuré).

5. Recherche de modifications d’annuaire : Vérifier si des méthodes d’authentification ou des rôles ont été ajoutés sur le compte :

   Get-MgAuditLogDirectoryAudit -Filter "targetResources/any(t:t/userPrincipalName eq 'victime@entreprise.fr')" -All

---

Exemple concret / cas d’école

Scénario : la connexion étrangère réputée “conforme”

Le SOC détecte une connexion inhabituelle sur le compte d’un directeur technique depuis une IP résidentielle située en Europe de l’Est. Les journaux Entra indiquent pourtant :

• ResultType: 0 (Succès)
• ConditionalAccessStatus: success
• MFA: Satisfait

Analyse forensique :

1. Examen des détails d’authentification : L’inspection du champ AuthenticationDetails révèle :

   {
     "authenticationMethod": "Previously satisfied",
     "authenticationStepRequirement": "MultiFactorAuthentication",
     "status": "success"
   }

   Constat : l’utilisateur n’a pas validé de notification MFA lors de cette connexion. La condition a été satisfaite par la réutilisation d’une session ou d’un cookie précédemment émis (Fiche 23 : vol de cookies & jetons).
2. Corrélation de l’empreinte logicielle : L’adresse IP appartient à un service commercial de proxy résidentiel. Le User-Agent est une copie rigoureusement identique au navigateur de l’ordinateur de la victime.
3. Conclusion de l’investigation : L’attaquant a déployé un proxy inverse de phishing AiTM (Evilginx) deux heures plus tôt (Fiche 21 : AiTM). La victime s’est authentifiée sur le proxy adverse en validant son MFA ; l’attaquant a intercepté le cookie ESTSAUTH et l’a rejoué depuis ses infrastructures.

---

Pièges et confusions fréquentes

Piège Fréquent	Réalité	Conséquence
Ignorer les connexions non interactives	Les applications clientes renouvellent leurs jetons en arrière-plan sans invite interactive.	Omettre l’activité automatisée de l’attaquant menée via des scripts PowerShell ou Graph.
Prendre “MFA satisfait” pour une preuve d’action	La mention “Previously satisfied” traduit un rejeu de jeton et non une validation en direct.	Supposer à tort que l’utilisateur a accepté une notification MFA malveillante par fatigue.
Se fier aveuglément au pays géolocalisé	Les adversaires utilisent des réseaux de proxys résidentiels géolocalisés dans le pays de la cible.	Écarter une connexion malveillante sous prétexte que l’IP se situe dans la même ville que le siège.

---

Points clés à retenir

1. Entra ID est l’autorité d’authentification centrale : toute authentification M365 transite par Entra et aboutit à l’émission de jetons OAuth 2.0 / OIDC.
2. L’accès conditionnel est un filtre dynamique : il statue en temps réel selon les signaux d’identité, d’appareil, de réseau et de risque.
3. Le vol de session neutralise le MFA : un cookie ou un jeton dérobé permet d’accéder aux données sans déclencher de nouvelle vérification MFA.
4. La rétention par défaut est très brève : sans archivage vers un SIEM ou un Log Analytics, les journaux expirent en 7 ou 30 jours.

---

État de la fonctionnalité en 2026

Changements récents

• Évaluation continue de l’accès (CAE) : généralisée sur Exchange, SharePoint et Teams. La révocation de session ou la réinitialisation de mot de passe prend effet quasi-instantanément (quelques minutes).
• Généralisation du MFA résistant au phishing : déploiement massif des clés FIDO2, de Windows Hello for Business et du Number Matching dans Microsoft Authenticator pour contrer l’AiTM.

Fonctionnalités dépréciées

• Le portail legacy MFA par utilisateur (per-user MFA) est déprécié au profit des stratégies d’accès conditionnel unifiées.
• L’authentification basique est éradiquée.

Limitations actuelles

• Précision géographique aléatoire : la géolocalisation des adresses IP mobiles dépend des passerelles opérateurs et peut être décalée de plusieurs centaines de kilomètres.

---

Références

• Microsoft Learn : qu’est-ce que Microsoft Entra ID ?
• Microsoft Learn : présentation de l’accès conditionnel
• Microsoft Learn : rapports d’activité de connexion dans Microsoft Entra ID
• Hermes Codex : pont d’architecture Active Directory vers Microsoft Entra ID