Comptes, utilisateurs, groupes et rôles Microsoft 365

Principe d'identité forensique

Ne présumez jamais que tous les comptes représentent des utilisateurs humains. Dans les intrusions cloud actuelles, les acteurs malveillants ciblent activement les service principals, les boîtes partagées et les invitations externes. Identifier précisément l’archétype d’un principal de sécurité est impératif pour évaluer ses capacités d’authentification et son périmètre d’action.

Concept

Au sein de Microsoft 365 et de Microsoft Entra ID, la sécurité et les autorisations sont articulées autour d’une taxonomie complexe de principaux de sécurité, de conteneurs et de modèles d’attribution de privilèges.

L’investigateur en réponse à incident doit impérativement distinguer :

• Les identités humaines : comptes membres internes, utilisateurs invités (B2B), comptes synchronisés depuis l’AD on-premises et comptes d’urgence (Break-Glass).
• Les identités de charge de travail (workload identities) : comptes de service applicatifs, Inscriptions d’applications (App Registrations), Applications d’entreprise (Service Principals) et Identités gérées (Managed Identities).
• Les conteneurs de groupes : groupes de sécurité, Groupes Microsoft 365 unifiés, Groupes avec messagerie activée et Groupes à appartenance dynamique.
• Les modèles d’autorisation : rôles d’annuaire Entra ID, modèles RBAC propres aux charges applicatives (Exchange RBAC, Purview RBAC) et activations Privileged Identity Management (PIM).

+---------------------------------------------------------------------------------------------------+
|                               TAXONOMIE DES IDENTITÉS MICROSOFT 365                               |
|                                                                                                   |
|   +------------------------------------+             +------------------------------------+       |
|   |         IDENTITÉS HUMAINES         |             |        IDENTITÉS APPLICATIVES      |       |
|   |   Membre (Salarié, Droits pleins)  |             |   App Registration (Définition)    |       |
|   |   Invité (Guest B2B externe #EXT#) |             |   Service Principal (Instance loc.)|       |
|   |   Boîte partagée (Logon désactivé) |             |   Identité Gérée (Ressource Azure) |       |
|   +-----------------+------------------+             +-----------------+------------------+       |
|                     |                                                  |                          |
|                     +------------------------+-------------------------+                          |
|                                              |                                                    |
|                                              v                                                    |
|   +-------------------------------------------------------------------------------------------+   |
|   |                                   CONTENEURS (GROUPES)                                    |   |
|   |   Groupes de sécurité (Accès/CA) | Groupes M365 (Boîte mail + SharePoint + Teams)         |   |
|   |   Appartenance statique (Assignée)| Appartenance dynamique (Règles : département, rôle)   |   |
|   +------------------------------------------+------------------------------------------------+   |
|                                              |                                                    |
|                                              v                                                    |
|   +-------------------------------------------------------------------------------------------+   |
|   |                                  MODÈLES D'AUTORISATION                                   |   |
|   |   Rôles d'Annuaire Entra (Global Administrator, Security Reader, Application Admin)       |   |
|   |   Privileged Identity Management (PIM : Éligibilité vs Rôle actif temporaire)             |   |
|   |   RBAC Spécifique (Exchange Organization Management, Purview Compliance Administrator)    |   |
|   +-------------------------------------------------------------------------------------------+   |
+---------------------------------------------------------------------------------------------------+

---

Pourquoi c’est important en DFIR

Confondre les archétypes d’identité dans M365 mène directement à des angles morts critiques :

• Dévoyage des boîtes partagées (shared mailboxes) : les boîtes partagées ne requièrent aucune licence payante et doivent obligatoirement avoir leur compte d’ouverture de session directe désactivé (AccountEnabled: False). Si un attaquant réactive ce compte et définit un mot de passe, il dispose d’une boîte mail furtive et non surveillée pour commettre des fraudes BEC (Fiche 49 : BEC).
• Furtivité des identités applicatives : les attaquants maintiennent souvent leur persistance en créant ou en compromettant une application d’entreprise (Service Principal). Les service principals ne sont pas soumis au MFA interactif, échappent aux politiques d’accès conditionnel ciblant les utilisateurs et sont totalement invisibles pour les EDR de postes (Fiche 29 : Persistance OAuth).
• Escalade silencieuse par groupes dynamiques : lorsqu’une organisation utilise des groupes dynamiques pour octroyer des accès d’administration ou ouvrir des dossiers SharePoint sensibles, un attaquant modifiant un simple attribut utilisateur (ex. department = "DSI") hérite automatiquement des privilèges sans déclencher d’alerte d’ajout manuel de membre.
• Contournement des audits par PIM : se contenter d’auditer les administrateurs permanents est une erreur majeure. Les adversaires compromettant des comptes avec éligibilité PIM activent le rôle administrateur pendant 1 heure pour agir, puis redeviennent des utilisateurs apparemment anodins.

---

Comment ça fonctionne

1. Typologie utilisateurs : membre vs invité

• Membre (UserType: Member) : compte employé classique. Par défaut, les membres disposent d’un droit de lecture étendu sur l’annuaire : ils peuvent énumérer tous les autres utilisateurs, les groupes de sécurité, la liste des applications et les paramètres globaux.
• Invité (UserType: Guest) : partenaire ou prestataire externe invité via Entra B2B. Son UPN contient le marqueur #EXT# (ex. prestataire_externe.com#EXT#@entreprise.onmicrosoft.com). Ses droits de lecture sur l’annuaire sont restreints par défaut à son propre profil.

2. Identités applicatives : app registrations vs service principals

• Inscription d’application (app registration) : modèle architectural abstrait de l’application. Elle définit les étendues d’API demandées (Déléguées vs Applicatives) et les URL de redirection.
• Application d’entreprise (service principal) : l’instance concrète et le principal de sécurité résidant dans le tenant. C’est elle qui détient les secrets clients, certificats et autorisations effectives.
• Identité gérée (managed identity) : service principal administré automatiquement par Azure pour les VM ou fonctions serverless, éliminant la manipulation humaine de secrets.

3. Typologie des groupes

• Groupes de sécurité : utilisés pour attribuer des accès aux ressources et appliquer des stratégies d’accès conditionnel.
• Groupes Microsoft 365 (anciens groupes unifiés) : espaces collaboratifs créant simultanément :
  • Une boîte mail et un calendrier partagés Exchange.
  • Une collection de sites d’équipe SharePoint.
  • Une équipe Teams (si activée).
• Groupes dynamiques : l’appartenance n’est pas gérée manuellement, mais calculée en continu par le moteur Entra selon des requêtes logiques (ex. (user.department -eq "Finance") and (user.accountEnabled -eq true)).

4. Rôles d’annuaire entra vs modèles RBAC dédiés

• Rôles d’annuaire (globaux) : privilèges au niveau du tenant (ex. Global Administrator, Application Administrator, Privileged Role Administrator).
• Modèles RBAC locaux :
  • RBAC Exchange Online : rôles tels que Organization Management, Compliance Management, View-Only Recipients, gérés au sein d’Exchange indépendamment d’Entra ID.
  • Rôles Purview : permissions de conformité (Audit Reader, eDiscovery Manager) administrées dans le portail Purview.
• Privileged identity management (PIM) :
  • Attribution Permanente : l’utilisateur détient le rôle en continu.
  • Attribution Éligible : l’utilisateur est autorisé à demander l’activation temporaire du rôle (ex. 2 à 8 heures), soumise à validation MFA, justification et éventuelle approbation humaine.

---

Ce qui est possible

L’investigation des structures d’identité permet de :

• Reconstituer les trajectoires d’élévation de privilèges : identifier les rôles d’annuaire activés de manière permanente ou temporaire via PIM (Fiche 31 : Rôles Entra).
• Déceler les certificats et secrets clandestins : identifier les secrets clients ou certificats ajoutés à des applications d’entreprise pour créer des portes dérobées.
• Auditer les mouvements de groupes : reconstruire avec précision quand un compte a été intégré à un groupe d’administration et par qui.
• Détecter les invitations externes frauduleuses : identifier les comptes invités créés depuis des identités compromises pour exfiltrer des fichiers SharePoint (Fiche 34 : SharePoint).

---

Ce qui n’est pas possible

• Rétention des objets supprimés limitée à 30 jours : un compte ou une application supprimée bascule dans la corbeille pendant 30 jours (soft-delete), après quoi la purge définitive empêche toute récupération de ses attributs directs.
• Dissociation automatique des actions applicatives déléguées : lorsqu’une application agit sous le mandat d’un utilisateur (permissions déléguées), les événements dans les journaux applicatifs portent le nom de l’utilisateur. Seule l’analyse de l’AppId dans le journal d’audit permet d’imputer l’action à l’application.

---

Conditions nécessaires

• Rôles requis pour l’analyse : Global Reader ou Security Reader + Directory Readers (Fiche 05 : Global Reader).
• Outillage d’analyse : powerShell 7 avec le SDK Microsoft.Graph (notamment Microsoft.Graph.Users, Microsoft.Graph.Groups, Microsoft.Graph.Identity.Governance).

---

Artefacts et journaux

Événement Forensique	Source de Journalisation	Attributs Clés de Preuve
Création d’utilisateur	Entra Directory Audit (Add user)	InitiatedBy, TargetResources.UserPrincipalName, TargetResources.Id
Attribution de rôle	Entra Directory Audit (Add member to role)	RoleDefinitionId, TargetResources, InitiatedBy
Activation PIM	Entra Directory Audit (Add member to role completed (PIM activation))	Justification, TicketNumber, Duration, InitiatedBy
Ajout de secret applicatif	Entra Directory Audit (Update application - Certificates and secrets management)	AppId, KeyDescription, KeyType, KeyIdentifier
Modification de groupe	Entra Directory Audit (Add member to group)	TargetResources.Group, TargetResources.Member, InitiatedBy
Connexion service principal	Entra Sign-In Logs (servicePrincipalSignIns)	ServicePrincipalId, AppId, IpAddress, ResourceDisplayName

---

Méthodologie d’investigation

1. Énumération des administrateurs permanents et éligibles : Lister tous les comptes disposant de rôles d’annuaire à haut privilège :

   Get-MgDirectoryRole | ForEach-Object {
     $role = $_
     Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id | Select-Object @{N="Role";E={$role.DisplayName}}, Id, AdditionalProperties
   }

2. Audit des activations PIM sur la période de crise : Extraire les journaux d’élévation temporaire de privilèges :

   Get-MgAuditLogDirectoryAudit -Filter "category eq 'RoleManagement' and activityDisplayName eq 'Add member to role completed (PIM activation)'" `
     -All | Select-Object ActivityDateTime, InitiatedBy, TargetResources, AdditionalDetails

3. Inspection des applications et de leurs identifiants cryptographiques : Détecter les ajouts récents de secrets ou de certificats sur des applications :

   Get-MgAuditLogDirectoryAudit -Filter "category eq 'ApplicationManagement' and activityDisplayName eq 'Update application - Certificates and secrets management'" `
     -All | Select-Object ActivityDateTime, InitiatedBy, TargetResources

4. Vérification de l’étanchéité des boîtes partagées : S’assurer qu’aucune boîte partagée ne possède de compte d’ouverture de session actif :

   Get-MgUser -Filter "assignedLicenses/$count eq 0" -ConsistencyLevel eventual `
     | Select-Object UserPrincipalName, AccountEnabled, SignInActivity

5. Examen des comptes invités (B2B) : Lister les comptes externes créés ou modifiés pendant la fenêtre suspecte :

   Get-MgUser -Filter "userType eq 'Guest'" -All | Select-Object UserPrincipalName, Mail, ExternalUserState, CreatedDateTime

---

Exemple concret / cas d’école

Scénario : la persistance clandestine par service principal

Après avoir contenu un compte Administrateur Général compromis, le client a réinitialisé tous les mots de passe et révoqué l’ensemble des sessions. Deux semaines plus tard, des boîtes de messagerie de direction sont de nouveau exfiltrées sans aucune trace de connexion utilisateur dans les journaux interactifs.

Déroulement de l’investigation forensique :

1. Analyse des flux non-humains : L’analyste inspecte les journaux de connexion des Service Principals et découvre des requêtes massives quotidiennes émises par une application nommée "Backup_Utility".
2. Reconstitution historique dans l’audit d’annuaire : L’audit des événements ApplicationManagement révèle que lors de l’intrusion initiale, le compte administrateur compromis a exécuté :
   • Add service principal : création de l’application locale.
   • Add app role assignment to service principal : octroi du droit applicatif Mail.ReadWrite (Application Permission, et non Delegated).
   • Update application - Certificates and secrets : injection d’un certificat RSA valide 2 ans détenu par l’attaquant.
3. Conclusion : La réinitialisation des mots de passe des utilisateurs humains n’avait aucun impact sur ce Service Principal autonome. L’attaquant interrogeait directement l’API Microsoft Graph par flux client-credentials sans aucune interaction humaine ni déclenchement MFA (Fiche 51 : compromission OAuth).

---

Pièges et confusions fréquentes

Piège Fréquent	Réalité Opérationnelle	Conséquence Forensique
”Le MFA protège les service principals”	Les service principals s’authentifient par certificat ou secret ; ils sont incapables de passer un challenge MFA interactif.	Ignorer des accès adverses majeurs sous prétexte que “le MFA est imposé à 100 % sur le tenant”.
Confondre app registration et enterprise app	L’App Registration n’est qu’un modèle ; supprimer l’App Registration ne révoque pas toujours les jetons du Service Principal existant.	Laisser une porte dérobée active dans le tenant en croyant l’avoir neutralisée.
Négliger les règles de groupes dynamiques	Un attaquant altère les attributs de son compte (title, department) pour intégrer mécaniquement des groupes d’accès privilégiés.	Ne pas comprendre comment un attaquant a obtenu des accès sans trace d’ajout explicite dans le groupe.

---

Points clés à retenir

1. La diversité des identités est une réalité opérationnelle : salariés membres, invités B2B, boîtes partagées et applications partagent le même annuaire.
2. Les identités applicatives sont des cibles d’ancrage idéales : les service principals échappent au MFA interactif et peuvent détenir des permissions applicatives transversales sur tout le tenant.
3. L’audit PIM est impératif : l’analyse des journaux d’activation PIM (Add member to role completed (PIM)) prévaut sur la simple lecture de la liste statique des administrateurs.
4. Les boîtes partagées doivent rester verrouillées : tout compte associé à une boîte partagée doit avoir son authentification interactive formellement désactivée.

---

État de la fonctionnalité en 2026

Changements récents

• Protection des identités de charge de travail (workload ID protection) : déploiement de stratégies d’accès conditionnel et de détection de risque dédiées spécifiquement aux Service Principals et Managed Identities.
• PIM for groups : privileged Identity Management permet désormais d’assujettir l’appartenance à des groupes de sécurité sensibles à des demandes d’éligibilité temporaires.

Fonctionnalités dépréciées

• Les anciens modules PowerShell AzureAD (Get-AzureADUser, Add-AzureADDirectoryRoleMember) sont totalement obsolètes.
• Utiliser rigoureusement les cmdlets Get-MgUser, New-MgDirectoryRoleMember du SDK Microsoft.Graph.

---

Références

• Microsoft Learn : types de comptes d’utilisateurs et d’invités dans Microsoft Entra ID
• Microsoft Learn : applications et principaux de service dans Microsoft Entra ID
• Microsoft Learn : rôles intégrés Microsoft Entra et principe du moindre privilège
• Microsoft Learn : journaux d’audit dans Microsoft Entra ID