Rôle Admin Invité Entra Confiance B2B Inter-Tenant : Comment un Compte Externe Atteint Administrateur Général

Rôle Admin Invité Entra Confiance B2B Inter-Tenant : ce que ces paramètres contrôlent réellement

Rôle admin invité Entra confiance B2B inter-tenant : l'expression regroupe deux des couches les moins auditées de la gouvernance des identités externes de Microsoft Entra ID, et leur combinaison forme l'un des chemins d'escalade de privilèges les plus discrets de la plateforme : un compte invité externe détenant directement un rôle d'annuaire, derrière des Cross-Tenant Access Settings qui, par défaut, laissent d'autres organisations Microsoft Entra atteindre votre tenant. Aucune des deux moitiés n'est exotique en soi — la collaboration B2B et l'attribution de rôles d'annuaire sont toutes deux des fonctionnalités Entra fondamentales et documentées — mais la combinaison des deux est rarement auditée comme un contrôle unique.

C'est un angle différent de deux failles connexes qu'il vaut mieux connaître d'abord. Si votre préoccupation porte sur qui peut inviter des invités, s'ils doivent avoir le MFA, ou si des comptes obsolètes s'accumulent, voir Comptes invités Azure : la surface d'attaque oubliée. Si votre préoccupation porte sur un invité qui hérite d'un privilège en atterrissant dans un groupe de sécurité imbriqué dans un groupe attribuable à un rôle, voir Groupes privilégiés imbriqués Entra ID, groupes attribuables à un rôle, et invités dans des groupes de sécurité. Cet article couvre quelque chose d'amont par rapport aux deux : un invité détenant directement un rôle Microsoft Entra — sans groupe, sans imbrication — et la configuration de confiance B2B au niveau du tenant qui décide, en amont, quelles organisations externes peuvent atteindre l'identité d'origine de cet invité.

Cinq contrôles composent cette couche de gouvernance :

Comment un invité se retrouve avec un rôle d'annuaire, et comment les paramètres de confiance élargissent la porte

Attribuer un rôle à un invité n'est pas un cas particulier dans le RBAC Entra

Le modèle d'attribution de rôles de Microsoft Entra ne traite pas un principal invité différemment d'un principal membre lorsqu'il s'agit de détenir un rôle d'annuaire. Le même workflow d'attribution de rôle — New-MgRoleManagementDirectoryRoleAssignment en PowerShell, ou POST /roleManagement/directory/roleAssignments dans Microsoft Graph — qui attribue le rôle Administrateur du service d'assistance à un employé interne attribue tout aussi facilement le rôle Administrateur général à un objet invité externe. La documentation API de Microsoft elle-même pour lister les attributions de rôles le montre explicitement : son exemple travaillé d'expansion du principal sur une réponse d'attribution de rôle inclut des utilisateurs invités ("userType": "Guest") détenant un rôle d'annuaire au même titre que des utilisateurs membres, sans traitement particulier.

Cela compte, car les permissions d'annuaire par défaut d'un invité sont volontairement restreintes. Le niveau de permission invité de Microsoft Entra (le paramètre authorizationPolicy.guestUserRoleId) est par défaut Accès limité (GUID 10dae51f-b6af-4016-8d66-8c2a99b929b3), et peut être resserré en Accès restreint (2af84b1e-32c8-42b7-82bc-daa82404023b), ce qui empêche même un invité d'énumérer l'appartenance à des groupes au-delà des siens. Mais ce paramètre régit la visibilité par défaut des objets d'annuaire pour chaque invité — ce n'est pas un plafond sur ce qu'une attribution de rôle explicite peut accorder à un invité donné. Un invité auquel le rôle Administrateur général a été attribué dispose de la totalité des permissions administratives du tenant, quelle que soit la sévérité du niveau de permission invité par défaut. Les propres recommandations Zero Trust de Microsoft citent Les invités ne se voient pas attribuer de rôles d'annuaire hautement privilégiés comme recommandation nommée, avertissant qu'un compte invité compromis détenant un rôle élevé donne aux attaquants un moyen d'escalader leurs privilèges, de créer des comptes de contournement (backdoor) et de persister dans le tenant — et les outils de posture tiers le suivent comme un constat autonome à part entière : le catalogue d'expositions de Tenable référence explicitement « Guest Account With a Privileged Role », citant une auditabilité réduite et une posture de sécurité affaiblie côté tenant d'origine comme risque central.

Les Cross-Tenant Access Settings décident quelles identités externes peuvent même atteindre cette attribution

Une attribution de rôle d'annuaire à un invité n'est contenue qu'à hauteur de l'identité externe qui se trouve derrière. Les Cross-Tenant Access Settings de Microsoft Entra contrôlent cela dans l'autre sens — ce sont des règles par défaut, à l'échelle du tenant, qui s'appliquent à toute autre organisation Microsoft Entra à moins que vous ne configuriez des exceptions spécifiques par organisation. Selon les valeurs initiales par défaut documentées par Microsoft :

• Collaboration B2B (b2bCollaborationInbound / b2bCollaborationOutbound) : tous vos utilisateurs internes sont activés pour la collaboration B2B par défaut — ils peuvent inviter des invités externes, et être invités ailleurs en tant qu'invités, sans qu'aucune liste d'autorisation par organisation ne soit requise.
• Confiance entrante (inboundTrust) : les revendications MFA et appareil (appareil conforme, jointure hybride Microsoft Entra) provenant d'organisations externes ne sont pas approuvées par défaut. Si un administrateur active ultérieurement « Approuver l'authentification multifacteur des tenants Microsoft Entra » au niveau par défaut plutôt que par partenaire, la revendication MFA de chaque organisation Microsoft Entra externe est acceptée — l'accès conditionnel cesse de revérifier le MFA pour tout invité, de tout tenant, y compris ceux dont vous n'avez jamais entendu parler. C'est B2B_INBOUND_TRUST_ALL.
• Connexion directe B2B (b2bDirectConnectInbound / b2bDirectConnectOutbound) : bloquée dans les deux sens, à l'échelle du tenant, par défaut — Microsoft documente ceci comme le seul paramètre de cette famille livré fermé : « la connexion directe B2B sortante est bloquée pour l'ensemble de votre tenant, et la connexion directe B2B entrante est bloquée pour toutes les organisations Microsoft Entra externes ». B2B_DIRECT_CONNECT_ENABLED se déclenche lorsqu'une modification au niveau par défaut — et non une modification intentionnelle par partenaire — l'ouvre.
• Accès sortant : également ouvert par défaut — vos utilisateurs peuvent être invités dans les ressources de n'importe quelle organisation Microsoft Entra externe, sauf si l'accès sortant est restreint. B2B_OUTBOUND_UNRESTRICTED signale exactement ce défaut sortant non restreint.

Les listes d'autorisation/de blocage et les paramètres d'accès inter-tenant sont tous deux vérifiés au moment de l'invitation, mais si un domaine externe ne figure sur aucune des deux listes, Microsoft Entra retombe sur la valeur par défaut configurée pour l'accès inter-tenant — qui, dès l'installation, est ouverte à la collaboration.

La chaîne d'escalade

Étape 1 — Une organisation externe invite, ou est invitée, sans restriction spécifique par organisation

Comme les paramètres de collaboration B2B par défaut autorisent l'accès entrant et sortant vers toute organisation Microsoft Entra externe, un compte invité provenant à peu près de n'importe quel tenant peut être invité dans le vôtre — ou un compte employé compromis peut en inviter un — sans se heurter à une vérification de liste d'autorisation.

Étape 2 — Les paramètres de confiance entrante suppriment une nouvelle vérification MFA

Si la confiance entrante est configurée pour accepter les revendications MFA d'organisations externes au niveau par défaut, Microsoft Entra vérifie si le jeton de l'invité porte déjà une revendication MFA satisfaite dans son tenant d'origine — un tenant que vous ne contrôlez pas et ne pouvez pas auditer. Aucune nouvelle vérification n'est déclenchée dans votre tenant si cette revendication est présente, indépendamment de la rigueur réelle de l'application du MFA dans le tenant d'origine.

Étape 3 — L'objet invité se voit directement attribuer un rôle d'annuaire

Quelque part dans l'historique du tenant — un engagement ponctuel avec un prestataire, un contournement de type « break-glass », un administrateur ayant utilisé « attribuer temporairement Administrateur général à l'invité » comme raccourci jamais annulé — l'ID d'objet de l'invité a été transmis à un appel d'attribution de rôle. Rien dans le RBAC d'Entra ID ne bloque cela au niveau de l'API, et à moins que quelqu'un n'interroge spécifiquement l'appartenance aux rôles pour les principaux invités, cela ne ressort pas d'une revue de routine « qui sont nos administrateurs » qui liste des noms à l'œil nu.

Étape 4 — La session privilégiée persiste via le tenant d'origine de l'invité

Comme l'authentification de cet invité continue de se dérouler dans son tenant d'origine, vos stratégies d'accès conditionnel, vos détections de risque de connexion et l'application de vos règles de mot de passe/MFA dans votre tenant ne voient que ce que les paramètres de confiance laissent passer. Une compromission des identifiants du tenant d'origine de l'invité devient, par transitivité, une compromission d'une identité privilégiée dans le vôtre.

Détection

# Microsoft Graph — posture par défaut actuelle de l'accès inter-tenant
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/default

# Microsoft Graph — toutes les exceptions spécifiques par partenaire
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners

# Microsoft Graph — toutes les attributions de rôle d'annuaire avec principal étendu ;
# filtrer la réponse côté client sur principal.userType eq 'Guest'
GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$expand=principal

// Journaux d'audit Microsoft Entra — attributions de rôle atterrissant sur un UPN invité
AuditLogs
| where OperationName in ("Add member to role", "Add eligible member to role")
| where TargetResources[0].userPrincipalName contains "#EXT#"
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), Target = tostring(TargetResources[0].userPrincipalName)

// Journaux d'audit Microsoft Entra — changements du paramètre d'accès inter-tenant par défaut
AuditLogs
| where Category == "CrossTenantAccessSettings"
| where OperationName has "default"
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)

Remédiation

1. Inventoriez chaque attribution de rôle d'annuaire détenue par un invité, puis décidez pour chacune : a-t-elle besoin d'un accès permanent, a-t-elle besoin d'un rôle tout court, ou n'a-t-elle jamais été annulée après un engagement de courte durée. Traitez « on ne sait pas pourquoi cet invité a ce rôle » comme un incident, pas comme une note de configuration.
2. Basculez tout accès privilégié légitime d'un invité vers PIM en tant qu'attribution éligible et limitée dans le temps, avec approbation requise, plutôt qu'une attribution directe permanente. Voir Accès privilégié Azure : trop d'administrateurs globaux pour comprendre pourquoi l'accès privilégié permanent est déjà un constat courant, même pour des comptes membres, et Fonctionnalités Azure AD Premium P2 pour ce que PIM nécessite pour être activé.
3. Passez l'accès de collaboration B2B entrant et sortant par défaut à Bloquer, puis ajoutez des paramètres spécifiques par organisation uniquement pour les tenants externes avec lesquels vous collaborez réellement. La recommandation de Microsoft elle-même est d'identifier d'abord les connexions entrantes/sortantes, pour qu'un passage du défaut à Bloquer ne coupe pas un accès métier actif.
4. Sortez la confiance MFA et appareil entrante du niveau par défaut. Si vous devez approuver le MFA d'un partenaire spécifique, configurez-le comme exception propre à ce partenaire uniquement — pas comme un défaut général appliqué à tout tenant Microsoft Entra jamais invité.
5. Laissez la connexion directe B2B bloquée par défaut — la posture initiale de Microsoft elle-même — et ne l'activez, par organisation, que pour les partenaires validés via une configuration mutuelle.
6. Restreignez l'accès sortant aux utilisateurs et groupes qui ont réellement besoin de collaborer en externe, plutôt que de laisser tous les utilisateurs internes éligibles au B2B sortant par défaut.
7. Exécutez des revues d'accès ciblées spécifiquement sur l'appartenance aux rôles privilégiés, pas seulement sur l'appartenance aux groupes — une revue qui ne vérifie que « qui est dans le groupe Administrateurs globaux » passe à côté d'un invité avec une attribution de rôle directe, en dehors de tout groupe. Durcissez plus largement les paramètres par défaut du tenant à l'aide de Durcissement du tenant Azure : corriger les paramètres par défaut non sécurisés comme checklist complémentaire.

Comment EtcSec détecte cela

L'audit Entra ID d'EtcSec vérifie directement cette couche de gouvernance. Guest User with Administrative Role (GUEST_ADMIN_ROLE) signale tout principal invité détenant une attribution de rôle d'annuaire. Cross-Tenant Access Open (B2B_CROSS_TENANT_OPEN) et Outbound B2B Access Unrestricted (B2B_OUTBOUND_UNRESTRICTED) vérifient la posture par défaut de la collaboration B2B entrante/sortante par rapport aux exceptions spécifiques par organisation. Inbound Trust for All Organizations (B2B_INBOUND_TRUST_ALL) signale une confiance MFA/appareil configurée au niveau par défaut plutôt que par partenaire. B2B Direct Connect Enabled (B2B_DIRECT_CONNECT_ENABLED) confirme que la connexion directe n'a pas été ouverte au-delà de la posture bloquée par défaut de Microsoft.

Pour les angles de gouvernance des invités adjacents que cet article ne couvre pas, voir Comptes invités Azure : la surface d'attaque oubliée pour la politique d'invitation, les exigences MFA et le nettoyage des comptes obsolètes, et Groupes privilégiés imbriqués Entra ID, groupes attribuables à un rôle, et invités dans des groupes de sécurité pour les invités qui atteignent un privilège par imbrication de groupes plutôt que par attribution directe. Pour la revue plus large dans laquelle s'inscrivent ces contrôles, voir Comment auditer la sécurité de Microsoft Entra ID.