02 · Gérer les identités des utilisateurs externes et des autres tenants

Version : 1.1 · Date : 2026-10-22 · Domaine 1 de l'examen : Implement and manage user identities (20 à 25 %)

En une phrase : un partenaire entre chez vous par B2B collaboration (un objet invité dans votre annuaire), par B2B direct connect (une confiance mutuelle, sans objet, pour les Teams shared channels) ou par cross-tenant synchronization (vos propres tenants poussent leurs utilisateurs) ; quatre réglages d'External Identities décident qui peut entrer, avec quel IdP et ce qu'il voit.

Ce que l'examen demande#

Bloc Implement and manage identities for external users and tenants du guide d'étude SC-300 (compétences du 28/10/2026) :

Déjà vu dans SC-500 : la vue d'ensemble B2B, les cross-tenant access settings et External ID pour les clients sont résumés dans SC-500 · 11.5 Les identités externes. Ici, on passe au niveau administrateur : chaque réglage, chaque écran, chaque piège. Le cycle de vie des invités (Manage the lifecycle of external users : access reviews, entitlement management) est traité au chapitre 09.

1. Les bases#

1.1 Trois façons de faire entrer un externe#

B2B direct connect ne sert aujourd'hui qu'aux Teams Connect shared channels, et Microsoft n'a pas prévu de l'étendre à d'autres usages. Pour tout le reste (applications Microsoft, SaaS, applications métier), on utilise B2B collaboration.

1.2 Guest ou Member, external ou internal : deux axes indépendants#

• UserType décrit la relation avec votre organisation (et les permissions par défaut). Il ne dit rien de la façon de s'authentifier.
• La propriété Identities dit qui authentifie l'utilisateur (voir 4.1).

1.3 Les rôles à connaître#

2. External collaboration settings#

Chemin : Entra ID > External Identities > External collaboration settings. Ces réglages valent surtout pour la B2B collaboration avec des identités non Entra (comptes sociaux, comptes non gérés) ; pour les autres tenants Entra, les cross-tenant access settings prennent le relais.

2.1 Guest user access : ce que voit un invité#

Sous Graph, ce réglage et le suivant vivent dans la ressource authorizationPolicy.

2.2 Guest invite settings : qui peut inviter#

Le rôle Guest Inviter donne le droit d'inviter sans autre privilège d'administration, même si l'option « Only users assigned to specific admin roles » est choisie :

# Donner le rôle Guest Inviter à un utilisateur (Microsoft Graph PowerShell)
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"
$role = Get-MgDirectoryRole | Where-Object { $_.DisplayName -eq "Guest Inviter" }
$userId = "<objectId ou UPN de l'utilisateur>"
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter @{
  "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userId"
}

2.3 Collaboration restrictions : allow list ou deny list#

Règles à connaître :

• Une seule liste : allow ou deny, jamais les deux. Passer de l'une à l'autre efface la configuration existante.
• Une seule stratégie par organisation, 25 Ko au maximum (environ 1 600 domaines de 15 caractères).
• La liste est vérifiée au moment de l'invitation et n'affecte pas les invités qui ont déjà accepté. Une invitation encore en attente vers un domaine bloqué échoue à la redemption.
• Elle est indépendante des listes de partage de SharePoint Online et OneDrive, à régler séparément.
• La liste et les cross-tenant access settings sont tous deux vérifiés à l'invitation.

2.4 Self-service sign-up et départ des invités#

• Enable guest self-service sign up via user flows : autorise la création de user flows pour vos applications (l'externe s'inscrit lui-même et devient invité). Les user flows ne s'appliquent pas aux applications Microsoft (SharePoint, Teams). Ressource Graph : authenticationFlowsPolicy.
• External user leave settings : Yes, l'invité peut quitter votre organisation seul ; No, il doit contacter votre administrateur ou votre contact de confidentialité. Ce réglage n'est disponible que si vous avez renseigné les informations de confidentialité du tenant (Entra ID > Properties). Ressource Graph : externalIdentitiesPolicy.
• L'email one-time passcode se règle désormais dans All identity providers (voir 7.1).

Depuis fin 2025 : à la connexion, un invité est d'abord redirigé vers la page de connexion de son propre tenant (avec l'image de marque de son organisation), puis revient chez vous.

3. Inviter des utilisateurs externes#

3.1 Une invitation à la fois#

• Portail : Entra ID > Users > New user > Invite external user. L'objet invité est créé tout de suite, à l'état PendingAcceptance, et l'utilisateur qui invite devient le Sponsor par défaut.
• Microsoft Graph PowerShell :

Connect-MgGraph -Scopes "User.Invite.All"
New-MgInvitation -InvitedUserDisplayName "John Doe" `
  -InvitedUserEmailAddress "[email protected]" `
  -InviteRedirectUrl "https://myapplications.microsoft.com" `
  -SendInvitationMessage:$true          # sans ce paramètre, aucun e-mail n'est envoyé
# -InvitedUserType Member              # inviter directement en Member (organisation multi-tenant)

• API : POST https://graph.microsoft.com/v1.0/invitations (même logique, permission User.Invite.All).

Piège : avec New-MgInvitation, l'e-mail d'invitation n'est pas envoyé si -SendInvitationMessage est absent. On peut alors transmettre un lien direct à l'invité.

3.2 Invitation en masse (Bulk invite)#

1. Entra ID > Users > Bulk operations > Bulk invite (au moins User Administrator).
2. Télécharger le modèle CSV (ne pas modifier les deux premières lignes : version et en-têtes).
3. Colonnes obligatoires : Email address to invite et Redirection url (par exemple https://myapps.microsoft.com). Pas de virgule dans le message personnalisé.
4. Charger le fichier (validation), Submit, puis suivre le job dans Bulk operation results.

3.3 Les chemins de redemption#

flowchart TD
    A["Accept invitation"] --> B{"Compte dans un tenant Entra géré ?"}
    B -- Oui --> OK["Authentification chez le bon IdP"]
    B -- Non --> C{"Domaine fédéré en SAML/WS-Fed ?"}
    C -- Oui --> OK
    C -- Non --> D{"gmail.com et Google configuré ?"}
    D -- Oui --> OK
    D -- Non --> E{"Microsoft account existant ?"}
    E -- Oui --> OK
    E -- Non --> F{"Email one-time passcode activé ?"}
    F -- Oui --> G["Code envoyé par e-mail"] --> OK
    F -- Non --> H["Création d'un Microsoft account"] --> OK
    OK --> I["Consentement : privacy statement, Terms of use"] --> J["My Apps ou URL de redirection"]

Le consentement (première connexion seulement) :

1. Review permissions : l'invité accepte le privacy statement de votre organisation (nom, photo, e-mail et identifiants d'annuaire sont partagés).
2. Terms of use, si vous en avez configuré (External Identities > Terms of use, voir chapitre 05).
3. Redirection vers My Apps ou l'URL prévue. Dans l'annuaire, Invitation accepted passe à Yes.

Les invitations envoyées depuis le domaine onmicrosoft.com sont soumises aux limites d'envoi d'Exchange Online : un domaine personnalisé est conseillé pour de gros volumes.

4. Gérer les comptes externes#

4.1 Les propriétés d'un compte invité#

# Invités dont l'invitation est en attente
Get-MgBetaUser -Filter "externalUserState eq 'PendingAcceptance'" |
  Format-List DisplayName,UserPrincipalName,externalUserState,externalUserStateChangeDateTime
# Tous les invités
Get-MgUser -Filter "UserType eq 'Guest'"

L'authentification par téléphone n'est pas prise en charge pour les externes.

4.2 Reset redemption status#

Cas d'usage : l'invité veut changer d'e-mail ou d'IdP, son compte d'origine a été supprimé puis recréé, il a changé d'entreprise, ou ses responsabilités passent à quelqu'un d'autre.

• On garde l'objet, son objectId, ses groupes et ses affectations d'applications. L'UPN ne change pas, seul le nom de connexion change.
• Portail : profil de l'utilisateur > Overview > tuile B2B collaboration > Reset redemption status > Reset. Pour une nouvelle adresse, la mettre d'abord dans Email et Other emails.
• Rôle : Helpdesk Administrator (moindre privilège) ou User Administrator.

Connect-MgGraph -Scopes "User.Invite.All","User.ReadWrite.All"
$user = Get-MgUser -Filter "startsWith(mail, '[email protected]')"
New-MgInvitation -InvitedUserEmailAddress $user.Mail `
  -InviteRedirectUrl "https://myapps.microsoft.com" `
  -ResetRedemption -SendInvitationMessage -InvitedUser $user

Piège : en appel app-only, le reset est impossible si l'utilisateur a des rôles attribués.

4.3 Convert to internal user#

Pour une fusion, une acquisition, un prestataire embauché : le compte externe devient interne sans être recréé (historique et accès conservés).

Portail : Entra ID > Users > l'utilisateur externe > Convert to internal user (au moins User Administrator). Seuls les utilisateurs qui s'authentifient hors de votre organisation sont éligibles.

À ne pas confondre : passer UserType de Guest à Member ne rend pas l'utilisateur interne. Il continue de s'authentifier chez lui ; seules ses permissions par défaut changent.

4.4 Autres opérations utiles#

• Changer UserType (portail ou PowerShell) : seulement si la relation change vraiment (faut-il un nouvel UPN, une boîte aux lettres, les mêmes accès ?).
• Donner plus de droits à un invité : l'ajouter à un rôle, ou assouplir le Guest user access (section 2.1).
• E-mail : si l'invité change d'adresse chez lui, la propriété mail n'est pas mise à jour automatiquement (Graph, Exchange admin center ou Set-MailUser).
• Global Address List : les invités n'y sont pas visibles par défaut (Microsoft Graph PowerShell pour les afficher).
• Journaux : une connexion B2B crée un sign-in log dans le tenant d'origine et dans le tenant de ressources.
• Microsoft Teams shared channels : pas accessibles aux invités B2B collaboration, il faut B2B direct connect.

5. Cross-tenant access settings#

Chemin : Entra ID > External Identities > Cross-tenant access settings. Ils gouvernent la B2B collaboration et le B2B direct connect avec les autres tenants Microsoft Entra (y compris d'autres clouds Microsoft). Aucune limite au nombre d'organisations ajoutées.

5.1 Default settings et organizational settings#

Inbound : ce que les utilisateurs d'un tenant externe peuvent atteindre chez vous. Outbound : ce que vos utilisateurs peuvent atteindre chez eux. Les deux se règlent pour tous ou pour des users, groupes et applications précis : il faut demander au partenaire les object IDs de ses utilisateurs et groupes, et les application IDs (les sign-in logs aident à les trouver).

Règles de cohérence : les réglages d'utilisateurs et d'applications doivent concorder. Si vous bloquez l'entrée à tous les externes, toutes les applications doivent être bloquées ; si vous autorisez la sortie, au moins une application externe doit rester autorisée.

5.2 Trust settings (inbound)#

• Trust multifactor authentication from Microsoft Entra tenants : votre Conditional Access s'applique toujours, mais un utilisateur qui a déjà fait la MFA chez lui ne la refait pas.
• Trust compliant devices et Trust Microsoft Entra hybrid joined devices : vos stratégies « appareil conforme » acceptent la revendication du tenant d'origine.
• Si vous faites confiance à la MFA externe, pensez à exclure les externes de la stratégie d'inscription MFA d'ID Protection (sinon ils ne peuvent pas satisfaire les deux exigences).

5.3 Automatic redemption#

Case Automatically redeem invitations with the tenant {tenant} : elle supprime l'e-mail d'invitation et le consentement seulement si elle est cochée dans le tenant d'origine (outbound) ET dans le tenant de ressources (inbound).

Elle ne touche pas au consentement des applications.

5.4 Redemption order#

Onglet Redemption order (inbound, B2B collaboration) : on réordonne les primary identity providers (Microsoft Entra ID, SAML/WS-Fed) et les fallback identity providers (Microsoft account, email one-time passcode).

• Au moins un fallback reste actif. Couper Microsoft account impose donc l'email OTP.
• Les invités qui utilisent déjà un MSA continuent ; pour les faire changer, reset redemption status.
• Pour un domaine vérifié dans un autre tenant Entra et fédéré en SAML/WS-Fed, on remonte SAML/WS-Fed identity providers en tête pour que la fédération passe avant Entra ID.

5.5 B2B direct connect#

• Confiance mutuelle : Contoso autorise l'inbound de Fabrikam et Fabrikam autorise l'outbound vers Contoso (et inversement pour un partage dans les deux sens).
• Aucun objet invité : l'utilisateur est géré dans Teams par le propriétaire du shared channel ; il a accès à My Apps mais pas au portail Azure.
• Si votre Conditional Access exige la MFA, vous devez activer trust MFA pour ce partenaire.
• Licence P1 dans les deux tenants. Pas de B2B direct connect entre clouds Microsoft différents.
• Les access reviews des groupes Teams détectent les utilisateurs B2B direct connect des shared channels.

5.6 Licences, rôles et précautions#

• Security Administrator au minimum (ou un rôle personnalisé dédié).
• Microsoft Entra ID P1 dans le tenant configuré pour : les trust settings, le redemption order, le ciblage d'users, groupes ou applications. B2B direct connect : P1 des deux côtés.
• Bloquer toutes les applications par défaut empêche la lecture des e-mails chiffrés OME : autoriser l'application 00000012-0000-0000-c000-000000000000 en sortie.
• Une Conditional Access qui exige la MFA ou des Terms of use peut bloquer l'inscription : autoriser Microsoft App Access Panel (0000000c-0000-0000-c000-000000000000) et Microsoft Entra Terms of Use (d52792f4-ba38-424d-8140-ada5b883f293). En entrée, à cause d'une limite du portail, cela passe par Microsoft Graph.
• Toute modification des cross-tenant access settings est une protected action (Conditional Access peut exiger une authentification renforcée, voir chapitre 05).
• Audit : journaux d'audit, catégorie CrossTenantAccessSettings. Avant de restreindre, mesurer l'existant : workbook Cross-tenant access activity, script Get-MSIDCrossTenantAccessActivity (module MSIdentityTools), Get-MgAuditLogSignIn.

# Ajouter Fabrikam en organizational settings et lui faire confiance (MFA, appareils), avec auto-redeem en entrée
# (corps construit avec les propriétés de la référence Graph crossTenantAccessPolicyConfigurationPartner)
POST https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners
Content-Type: application/json

{
  "tenantId": "<tenant ID de Fabrikam>",
  "inboundTrust": { "isMfaAccepted": true, "isCompliantDeviceAccepted": true, "isHybridAzureADJoinedDeviceAccepted": false },
  "automaticUserConsentSettings": { "inboundAllowed": true }
}

5.7 Tenant restrictions v2 et Microsoft cloud settings#

• Tenant restrictions v2 : sur vos appareils et votre réseau, empêcher vos utilisateurs d'utiliser des comptes émis par d'autres tenants ou créés dans des tenants inconnus (risque d'exfiltration). Indépendant des réglages inbound / outbound.
• Microsoft cloud settings : B2B collaboration entre le cloud commercial et Azure Government (dont GCC High et DoD) ou Azure operated by 21Vianet. B2B direct connect n'est pas possible entre clouds.

6. Cross-tenant synchronization#

Pour une organisation qui possède plusieurs tenants : créer, mettre à jour et supprimer automatiquement des utilisateurs B2B (et des groupes de sécurité) d'un tenant à l'autre, sans invitation ni consentement.

6.1 Les propriétés à retenir#

• Basée sur le moteur de provisioning de Microsoft Entra (comme le provisioning vers une application SaaS), mais pas sur SCIM.
• Push depuis la source, jamais un pull de la cible.
• Ne pousse que les internal members de la source : ni ses invités, ni ses utilisateurs externes. Pas de boucle possible.
• Le scope (users et groupes assignés, scoping filters) et les attribute mappings se configurent dans la source.
• Les utilisateurs arrivent par défaut en external member (userType = Member), modifiable dans les mappings.
• Un seul job entre une source et une cible ; plusieurs jobs pour une source vers plusieurs cibles (ou l'inverse). Topologies : tenant central, satellites, maillage.
• Cycle toutes les 40 minutes (le premier est plus long). Provisioning à la demande possible pour un utilisateur.
• L'administrateur de la cible peut arrêter la synchronisation à tout moment.

6.2 La mise en place#

sequenceDiagram
    participant T as Target tenant
    participant S as Source tenant
    Note over T: Security Administrator
    T->>T: Cross-tenant access settings, ajouter la source
    T->>T: Inbound, onglet Cross-tenant sync : Allow user synchronization
    T->>T: Trust settings : Automatically redeem invitations
    Note over S: Security Administrator puis Hybrid Identity Administrator
    S->>S: Cross-tenant access settings, ajouter la cible
    S->>S: Outbound : Automatically redeem invitations
    S->>S: Cross-tenant synchronization, New configuration
    S->>T: Test connection avec le tenant ID de la cible
    S->>S: Scope, scoping filters, attribute mappings
    S->>T: Provision on demand d'un utilisateur de test
    S->>T: Start provisioning, cycle de 40 min

En Microsoft Graph, la cible autorise la synchronisation avec :

PUT https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners/{sourceTenantId}/identitySynchronization
Content-Type: application/json

{ "displayName": "Fabrikam", "userSyncInbound": { "isSyncAllowed": true } }

6.3 Ce qui est synchronisé, et ce qui ne l'est pas#

• Les utilisateurs B2B déjà existants sont rapprochés (attribut interne alternativeSecurityIdentifier) ; leur userType n'est pas changé de Guest à Member sauf si on le mappe.
• Une modification faite dans la cible persiste jusqu'au prochain changement dans la source, qui l'écrase (y compris un blocage de connexion).
• Avec la synchronisation de groupes, le scope doit être Sync only assigned users and groups.

6.4 Déprovisioning et restauration#

• Soft delete dans la cible quand l'utilisateur est supprimé dans la source, retiré de la configuration ou du groupe assigné, ou ne respecte plus les scoping filters. Restauration automatique s'il revient dans le scope sous 30 jours.
• accountEnabled = false dans la source bloque la connexion dans la cible (ce n'est pas une suppression).
• Supprimer la configuration ne supprime pas les utilisateurs déjà créés.
• Ce n'est pas un outil de migration : l'utilisateur continue de s'authentifier dans la source.

6.5 Licences#

6.6 Multitenant organization#

Une multitenant organization déclare la frontière de vos tenants (un owner tenant crée l'organisation et ajoute les autres, qui rejoignent en member ; jusqu'à 2 heures de traitement). Elle améliore la collaboration dans le nouveau Teams et Viva Engage, et suppose des utilisateurs B2B member provisionnés, d'où l'usage de la cross-tenant synchronization. Licence : P1, une par employé et par organisation multi-tenant, et au moins une par tenant.

Pour inviter des partenaires hors de votre organisation, Microsoft recommande l'entitlement management (chapitre 09) plutôt que la cross-tenant synchronization, pour des raisons de confidentialité.

7. External identity providers : SAML, WS-Fed, Google, Facebook#

Chemin : Entra ID > External Identities > All identity providers (onglets Built-in et Custom). Rôle : External Identity Provider Administrator.

7.1 Les fournisseurs intégrés#

Email OTP en détail :

• Il sert quand l'invité n'a ni compte Entra, ni MSA, ni IdP fédéré.
• Le couper bloque les invités qui l'utilisent déjà, jusqu'à un reset redemption status. Les nouveaux invités devront créer un MSA.
• L'activer ne change rien aux invités déjà acceptés.
• On ne peut pas appliquer d'authentication strength aux comptes OTP : utiliser le contrôle Require multifactor authentication.
• Il reste utile pour les partenaires dont le tenant n'est que partiellement synchronisé (la fédération SAML ne règle pas ce cas).

7.2 Google et Facebook#

Connect-MgGraph -Scopes "IdentityProvider.ReadWrite.All"
New-MgIdentityProvider -BodyParameter @{
  "@odata.type"        = "microsoft.graph.socialIdentityProvider"
  displayName          = "Login with Google"
  identityProviderType = "Google"
  clientId             = "<client ID>"
  clientSecret         = "<client secret>"   # à lire dans un coffre, jamais en dur dans un script
}

Supprimer Google bloque les invités Google déjà acceptés : reset redemption pour les rebasculer.

7.3 SAML/WS-Fed identity provider federation#

Pour un partenaire qui a son propre IdP (AD FS, Shibboleth, autre IdP SAML 2.0 ou WS-Fed) sans présence Microsoft Entra. Les utilisateurs gardent leurs comptes, et un objet invité est quand même créé chez vous.

Étape 1, DNS : si l'URL d'authentification passive du partenaire n'est pas dans le domaine fédéré (par exemple https://fabrikamconglomerate.com/adfs pour fabrikam.com), le partenaire ajoute un enregistrement TXT : fabrikam.com. IN TXT DirectFedAuthUrl=https://fabrikamconglomerate.com/adfs.

Étape 2, côté partenaire : relying party trust et claims.

Étape 3, chez vous : All identity providers > Custom > Add new > SAML/WS-Fed. On saisit le display name, le protocole, le domaine du partenaire (d'autres domaines s'ajoutent ensuite), puis les métadonnées (fichier ou saisie) : Issuer URI (ou Entity ID), passive authentication endpoint (HTTPS uniquement), certificat de signature et metadata URL. La stratégie prend effet en 5 à 10 minutes. Graph : ressource samlOrWsFedExternalDomainFederation.

Étape 4 : pour un domaine vérifié dans un autre tenant Entra, remonter SAML/WS-Fed en tête du redemption order.

Règles à connaître :

• Metadata URL fortement recommandée : Entra renouvelle seul le certificat à expiration. Sans elle, ou si le certificat change avant l'expiration, il faut le mettre à jour à la main.
• L'Issuer doit être une URI valide (RFC 3986).
• Domaines : non vérifiés, tenants non gérés (« viral ») ou vérifiés dans Entra. Pour un domaine vérifié, Entra ID reste l'IdP principal à la redemption sauf si on change le redemption order. Un domaine ne doit pas être vérifié dans votre propre tenant.
• Pas de fédération SAML/WS-Fed entre deux tenants Entra : Entra utilise alors le B2B natif.
• Domainless : pas de contrôle du domaine de l'e-mail, routage par Issuer URI (et domain_hint dans l'URL de redirection de l'invitation) ; une seule IdP domainless par tenant. Erreur typique sans lui : AADSTS5000819.
• La fédération ne change pas les invités déjà acceptés (ils gardent leur méthode, OTP par exemple) : reset redemption pour les basculer. Supprimer la fédération bloque les invités fédérés jusqu'au reset.
• Pour supprimer : retirer tous les domaines sauf un, puis Delete Configuration.
• Microsoft Entra n'envoie pas de jeton d'authentification signé à l'IdP SAML.

8. Labs conseillés#

Il faut deux tenants de test (par exemple deux tenants de développement) ; certaines étapes demandent Microsoft Entra ID P1 (trust settings, redemption order, cross-tenant sync). Aucun coût Azure, mais des licences d'essai.

1. Collaboration encadrée
   1. Choisir Guest user access « most restrictive » et une deny list avec gmail.com.
   2. Inviter une adresse Gmail : l'invitation est refusée avec un message de domaine bloqué.
   3. Inviter une autre adresse, se connecter en invité : il ne voit que son profil.
   • Nettoyage : remettre les réglages par défaut.
2. Invitations et cycle de vie
   1. Inviter un utilisateur avec New-MgInvitation sans -SendInvitationMessage : pas d'e-mail ; partager un lien direct.
   2. Vérifier externalUserState avant et après l'acceptation, et la propriété Identities.
   3. Faire un Bulk invite de 3 adresses avec le modèle CSV, suivre le job.
   4. Reset redemption status sur l'un d'eux : l'objectId et les groupes sont conservés.
3. Trust MFA entre deux tenants
   1. Dans le tenant A, une stratégie Conditional Access en Report-only qui exige la MFA pour les invités.
   2. Ajouter B en organizational settings avec Trust multifactor authentication.
   3. Un utilisateur de B déjà passé par la MFA chez lui se connecte : le sign-in log de A montre la MFA satisfaite par la revendication du tenant d'origine.
4. Cross-tenant synchronization
   1. Dans la cible : ajouter la source, Allow user synchronization, automatic redemption.
   2. Dans la source : automatic redemption en outbound, nouvelle configuration, Test connection, assigner un groupe de 2 utilisateurs.
   3. Provision on demand : l'utilisateur apparaît en Member dans la cible, sans e-mail.
   4. Retirer un utilisateur du groupe : soft delete au cycle suivant.
5. Email OTP et redemption order
   1. Désactiver Microsoft account dans les fallback identity providers : l'OTP reste obligatoirement actif.
   2. Inviter une adresse sans compte Microsoft : code reçu par e-mail, Identities = mail.

9. Pièges d'examen#

10. Scénarios d'entraînement#

1. Contoso veut que seuls les membres du service Achats puissent inviter des fournisseurs, sans leur donner de rôle d'administration large. Que configurer ?

Guest invite settings = Only users assigned to specific admin roles can invite guest users, puis le rôle Guest Inviter pour les acheteurs (idéalement via un groupe attribuable à des rôles ou PIM, voir chapitre 09).

2. Les utilisateurs de Fabrikam (tenant Entra) accèdent à des applications de Contoso. La stratégie Conditional Access de Contoso exige la MFA et ils se plaignent de la faire deux fois. Que faire, et avec quelle licence ?

Dans Contoso, Cross-tenant access settings > Organizational settings > Fabrikam > Inbound > Trust settings > Trust MFA. Il faut Microsoft Entra ID P1 dans Contoso, et le rôle Security Administrator.

3. Contoso et Fabrikam veulent partager des Teams shared channels. Contoso a tout configuré en inbound, mais rien ne fonctionne. Pourquoi ?

B2B direct connect est mutuel : Fabrikam doit aussi autoriser l'outbound vers Contoso (et réciproquement pour l'autre sens), avec une licence P1 des deux côtés. Si la CA de Contoso exige la MFA, trust MFA est obligatoire.

4. Un groupe possède 4 tenants. Il veut que les utilisateurs du tenant RH apparaissent automatiquement dans les 3 autres, en member, et disparaissent à leur départ. Quelle solution, quelle licence ?

Cross-tenant synchronization : dans chaque cible, Allow user synchronization et automatic redemption ; dans la source, 3 configurations (une par cible), automatic redemption en outbound, scope et mappings. P1 par utilisateur synchronisé dans la source, rien dans les cibles.

5. Une prestataire invitée (compte Gmail) change d'entreprise et doit garder ses accès avec sa nouvelle adresse professionnelle. Que faire ?

Mettre la nouvelle adresse dans Email et Other emails, puis Reset redemption status. L'objet, l'objectId, les groupes et les affectations sont conservés. Rôle minimal : Helpdesk Administrator.

6. Un partenaire utilise AD FS sur sts.fabrikamgroup.com pour le domaine fabrikam.com. La fédération SAML échoue à la configuration. Pourquoi ?

Le passive endpoint n'est pas dans le domaine fédéré : Fabrikam doit publier un TXT DirectFedAuthUrl= sur fabrikam.com. Ajouter aussi la metadata URL pour le renouvellement automatique du certificat.

7. Après avoir désactivé l'email one-time passcode, des invités ne peuvent plus se connecter. Pourquoi, et comment corriger ?

Ils avaient accepté par OTP : couper l'OTP les bloque. Les nouveaux invités créeront un MSA. Pour les anciens : reset redemption status (ou réactiver l'OTP).

8. La direction veut interdire les comptes Microsoft personnels pour les invités. Comment ?

Cross-tenant access settings > Redemption order : désactiver Microsoft account dans les fallback identity providers (l'email OTP reste actif). Les invités MSA existants doivent passer par un reset redemption status.

9. Un consultant invité, recruté en CDI, doit devenir un compte interne sans perdre son historique. L'équipe propose de passer son UserType à Member. Est-ce suffisant ?

Non : il continuerait à s'authentifier chez son ancien IdP. Utiliser Convert to internal user (nouvel UPN et mot de passe pour un compte cloud), rôle User Administrator.

11. Pour aller plus loin#

• External ID pour vos clients : un external tenant distinct du workforce tenant, avec user flows, comptes sociaux (Google, Facebook, Apple, OIDC personnalisé) et image de marque. Azure AD B2C n'est plus vendu aux nouveaux clients depuis le 1er mai 2025 (voir SC-500 · 11.5).
• Facturation au MAU : External ID facture les utilisateurs actifs mensuels (invités UserType = Guest, internal guests, et tous les utilisateurs d'un external tenant), avec une tranche gratuite. Les Member synchronisés entre vos tenants ne sont pas comptés. Le tenant doit être lié à un abonnement Azure (External Identities > Overview > Linked subscriptions, rôle Contributor sur l'abonnement). Add-ons : ID Governance pour les invités, GSA for Guests, SMS, Go-Local (Australie, Japon).
• Conditional Access pour les externes : cibler Guest or external users par type (B2B collaboration guest, B2B direct connect, service provider…) et par tenant, voir chapitre 05.
• Gouvernance des invités : access reviews, entitlement management avec connected organizations, sponsors, au chapitre 09.
• Journaux : connexions B2B visibles dans les deux tenants, workbook Cross-tenant access activity, au chapitre 10.

12. Fiche à retenir#

• Trois mécanismes : B2B collaboration (objet Guest), B2B direct connect (aucun objet, Teams shared channels, mutuel), cross-tenant synchronization (vos tenants, objet Member).
• UserType = relation ; Identities = qui authentifie. Changer UserType ne rend pas interne : Convert to internal user.
• External collaboration settings : Guest user access (défaut : limited), Guest invite settings (défaut : anyone), collaboration restrictions (allow ou deny, 25 Ko, à l'invitation seulement), self-service sign-up, leave settings.
• Guest Inviter invite même quand seuls les rôles d'admin le peuvent.
• Invitation : portail, Bulk invite CSV, New-MgInvitation (-SendInvitationMessage sinon pas d'e-mail).
• Ordre de redemption : Entra ID, SAML/WS-Fed, Google, MSA, email OTP (défaut, 30 min / 24 h), création d'un MSA.
• Reset redemption status : garde l'objet ; Helpdesk Administrator.
• Cross-tenant access settings : Security Administrator ; défaut = B2B collaboration ouverte, direct connect bloqué, pas de trust ; organizational settings l'emportent ; P1 pour trust, redemption order et ciblage.
• Automatic redemption : outbound chez l'origine et inbound chez la ressource ; obligatoire pour la cross-tenant sync.
• Cross-tenant sync : push depuis la source (Hybrid Identity Administrator), cible = Allow user synchronization ; 40 min ; internal members seulement ; Member par défaut ; soft delete ; P1 dans la source (groupes : ID Governance ou Entra Suite).
• Google : invitations + self-service ; Facebook : self-service uniquement ; Google Workspace → SAML.
• SAML/WS-Fed : DNS TXT si l'URL passive sort du domaine, metadata URL, External Identity Provider Administrator, pas entre deux tenants Entra, sans effet sur les invités déjà acceptés.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Study guide for Exam SC-300
• Configure external collaboration settings
• Allow or block B2B collaboration with organizations
• Tutorial: Bulk invite B2B collaboration users
• New-MgInvitation (Microsoft Graph PowerShell)
• B2B collaboration invitation redemption
• Understand and manage the properties of B2B guest users
• Reset the redemption status for a guest user
• Convert external users to internal users
• Overview: Cross-tenant access with Microsoft Entra External ID
• crossTenantAccessPolicyConfigurationPartner resource type
• B2B direct connect overview
• What is cross-tenant synchronization?
• Configure cross-tenant synchronization
• Configure cross-tenant synchronization using PowerShell or Microsoft Graph API
• What is a multitenant organization in Microsoft Entra ID?
• Identity providers for External ID in workforce tenants
• Email one-time passcode authentication for B2B guest users
• Add Google as an identity provider for B2B guest users
• Add Facebook as an identity provider for External ID
• SAML/WS-Fed identity provider federation
• Add federation with SAML/WS-Fed identity providers
• Microsoft Entra External ID pricing and billing overview