Retour au tableau de bord
10
MODULE 10 · COURS

Collaboration B2B

Invités B2B, accès inter-locataires, Entra External ID CIAM (aperçu).

3hdurée
12sections
10questions
OBJECTIFS

Ce que vous saurez faire

5 objectifs · ~5 min

  • Distinguer la collaboration B2B (invités partenaires) de l'External ID pour les clients (CIAM), et choisir le bon modèle selon le public.
  • Inviter un utilisateur externe, comprendre son cycle de vie (invitation, rédemption, objet Guest) et l'état d'acceptation.
  • Configurer les paramètres d'accès inter-locataires (cross-tenant access settings) entrants et sortants pour cadrer la confiance avec un partenaire.
  • Gouverner les accès invités avec les revues d'accès et les packages d'accès (entitlement management), déployables en Entra ID P2.
  • Situer les fonctions premium d'Entra External ID (CIAM) comme à connaître, non déployables en E3+P2, et connaître l'alternative B2B.

Compétences transférées depuis l'AD classique

L'admin AD réutiliseL'admin AD doit désapprendre
Relations d'approbation (trusts) inter-forêts« Un trust est un tunnel réseau permanent entre domaines » — le B2B fédère des identités, pas des réseaux
Gestion du cycle de vie des comptes« Un partenaire = un compte que je crée et dont je gère le mot de passe » — l'invité s'authentifie chez lui
Délégation d'accès à des tiersAucun équivalent AD : la confiance se règle par locataire via les cross-tenant access settings
COURS

Fédérer les identités, pas dupliquer les comptes

5 sections · lecture ~35 min

1. Les deux visages d'Entra External ID

Contexte Un cabinet partenaire démarre demain. Le premier réflexe transposé de l'AD : « je crée un compte à chaque consultant ». C'est une erreur. Le B2B fédère des identités existantes — le consultant s'authentifie chez lui, vous ne gérez ni son mot de passe ni sa MFA.

« Entra External ID » recouvre deux scénarios opposés qu'il ne faut jamais confondre :

ScénarioPublicLe partenaire s'authentifie…Facturation
Collaboration B2B (workforce)Partenaires, prestataires, fournisseursdans son propre tenant (ou via OTP e-mail)Inclus (Free / P1 / P2)
External ID pour les clients (CIAM)Clients, grand public, utilisateurs d'une appdans un tenant external dédié que vous exposezÀ l'usage (MAU)

Ce module traite la collaboration B2B en profondeur (déployable en E3+P2) et situe le CIAM comme non déployable en l'état (section 5).

AD CLASSIQUE

Un partenaire = un compte dans votre annuaire, ou un trust inter-forêts.

ENTRA / B2B

Un partenaire = une identité invitée (Guest) qui reste gérée et authentifiée dans son organisation.

PIÈGE

Créer un compte membre « maison » au prestataire, avec mot de passe transmis. On multiplie les identités et les secrets à gérer.

2. Cycle de vie d'un invité B2B

Inviter un externe crée dans votre tenant un objet utilisateur de type Guest, distinct d'un Member :

  • UPN caractéristique : alice_contoso.com#EXT#@votretenant.onmicrosoft.com. Le #EXT# signale un objet externe dont l'identité source vit ailleurs.
  • userType = Guest : l'attribut qui pilote les restrictions d'accès invité et sert de filtre partout (Conditional Access, revues d'accès).
  • État d'invitation : PendingAcceptance tant que l'invité n'a pas redéemé le lien, puis Accepted après consentement. Un invité non redéemé existe déjà comme objet mais n'a pas encore d'accès effectif.

Comment l'externe prouve son identité (par ordre de préférence) :

  1. Compte Entra existant : il se connecte dans son tenant d'origine (home realm), fédération Entra-à-Entra native.
  2. Fédération directe / Google : SAML / WS-Fed avec l'IdP du partenaire, ou fournisseur Google.
  3. Code à usage unique par e-mail (Email OTP) : repli pour un externe sans identité fédérable.
Chargement du schéma…
Cycle de vie B2B : invitation → rédemption → accès. L'authentification reste chez le partenaire, à vie.

L'authentification d'un compte local se fait chez vous, contre votre DC. Aucun équivalent au principe « l'invité s'authentifie chez lui » — c'est la vraie rupture conceptuelle.

Paramètres de collaboration externe

Sous External Identities > External collaboration settings, deux réglages structurants :

  • Qui peut inviter : par défaut, tout utilisateur (voire les invités eux-mêmes) peut inviter. Restreindre aux admins ou à un rôle dédié est une bonne pratique de gouvernance.
  • Restrictions d'accès invité : limiter ce qu'un Guest peut lire de l'annuaire (le réglage le plus restrictif empêche l'énumération des autres objets).

3. Paramètres d'accès inter-locataires

Les cross-tenant access settings (CTAS) remplacent la logique de trust AD par un réglage de confiance par organisation partenaire, orienté identité et non réseau.

  • Paramètres par défaut : la posture appliquée à tous les tenants non listés explicitement.
  • Paramètres organisationnels : une entrée par tenant partenaire (identifié par son Tenant ID ou son domaine), qui surcharge les défauts.

Pour chaque partenaire, on règle trois axes :

AxeCe qu'il contrôle
Inbound accessLes utilisateurs du partenaire autorisés à entrer chez vous en B2B, et sur quelles apps
Outbound accessVos utilisateurs autorisés à être invités chez le partenaire
Trust settingsAccepter la MFA, l'appareil conforme ou hybrid joined déjà prouvés dans le tenant d'origine de l'invité

Les trust settings sont la vraie nouveauté : sans eux, un invité déjà MFA chez lui devrait refaire une MFA chez vous (friction, parfois impossible). En faisant confiance à la MFA du tenant d'origine, votre Conditional Access considère l'exigence MFA satisfaite.

Question rapide

Un consultant se plaint de devoir refaire une MFA chez vous alors qu'il en a déjà fait une chez lui. Que réglez-vous — et où ?

Activer Trust MFA dans les trust settings inbound du partenaire, pas dans les défauts globaux.

Ajouter le tenant du partenaire en organisation dans les cross-tenant access settings, puis dans les trust settings inbound, cocher Trust MFA claims from external tenants. Ne jamais activer ça dans les défauts globaux : ce serait faire confiance à la MFA de n'importe quel tenant, y compris ceux que vous ne connaissez pas.

4. Gouverner les accès invités (P2)

Inviter est facile ; le risque réel est le guest sprawl — des invités qui s'accumulent, gardent des accès après la fin d'un projet, et que personne ne revoit. La licence Entra ID P2 apporte les outils de gouvernance :

  • Revues d'accès (Access Reviews) — campagne récurrente qui demande à un relecteur (le sponsor, le manager, ou l'invité lui-même) de confirmer si l'accès est encore justifié. Les accès non confirmés peuvent être retirés automatiquement. Cible privilégiée : « tous les invités d'un groupe / d'une app ».
  • Entitlement management (packages d'accès) — on empaquette des ressources (groupes, apps, sites) et on ouvre une demande en self-service aux externes d'organisations connectées, avec approbation, expiration automatique et politique de séparation des tâches. L'invité est provisionné à l'octroi et déprovisionné à l'expiration, cycle de vie compris.

5. Entra External ID pour les clients (CIAM) — À CONNAÎTRE, NON DÉPLOYABLE EN L'ÉTAT

Microsoft Entra External ID pour les clients (le nouveau CIAM, successeur d'Azure AD B2C) sert à exposer une application à ses clients / au grand public : inscription en self-service, pages de connexion personnalisées à la marque, user flows, fournisseurs d'identité sociaux (Google, Facebook, Apple), attributs personnalisés collectés à l'inscription.

Sources Microsoft Learn

Rappel : en cas d'écart entre ce support et le portail, le portail fait foi.

LAB

Inviter, cadrer, gouverner

3 parties · TP guidé ~1h30 · Portail : entra.microsoft.com

Partie A — Inviter un consultant en B2B (30 min)

Portail : Entra admin center > Users > New user > Invite external user.

  1. Renseigner l'e-mail (ex : consultant@partenaire.com) et un message d'invitation.
  2. Vérifier dans la liste des utilisateurs : l'objet apparaît avec userType = Guest, UPN consultant_partenaire.com#EXT#@votretenant.onmicrosoft.com, état PendingAcceptance.
  3. Le consultant clique le lien d'invitation → authentification chez lui → consentement → état passe à Accepted.
  4. Assigner le Guest à un groupe M365 lié à un canal Teams projet.

Partie B — Cadrer la confiance avec le tenant partenaire (30 min)

Portail : External Identities > Cross-tenant access settings > Organizational settings > Add organization.

  1. Saisir le domaine ou Tenant ID du partenaire (ex : partenaire.com).
  2. Inbound access > B2B collaboration : restreindre aux utilisateurs / apps nécessaires (pas All users / All applications par défaut).
  3. Trust settings : cocher Trust MFA from Microsoft Entra tenants (et éventuellement Trust compliant devices si le partenaire est de confiance élevée).
  4. Ne pas activer Trust MFA dans les Default settings — uniquement par organisation.

Partie C — Provisionner via un package d'accès (30 min · P2)

Portail : Identity governance > Entitlement management > Access packages > New access package.

  1. Catalog : créer un catalogue « Consultants externes ».
  2. Resource roles : ajouter un groupe M365 (accès Teams / SharePoint projet) + une app si nécessaire.
  3. Requests : autoriser Users from other organizations, cibler le tenant du partenaire (organisation connectée).
  4. Approvers : un sponsor interne + un manager du partenaire (facultatif).
  5. Lifecycle : expiration à 6 mois ; requêtes de renouvellement possibles.
  6. Access reviews : revue tous les 3 mois, auto-apply ON.
PIÈGES CLASSIQUES

5 pièges de collaboration externe

Lecture ~10 min

ÉVALUATION

Testez vos acquis

10 questions QCM · cas pratique · ~30 min

Une évaluation interactive qui vous donne le badge Acquis (≥60%) ou Maîtrisé (≥80%).

Évaluation non tentée.

Cas pratique — Cabinet partenaire + boutique en ligne

Contexte : la PME (E3 + Entra ID P2) démarre un projet de 6 mois avec un cabinet partenaire. Un collègue propose :

« Je crée un compte à chaque consultant du cabinet dans notre tenant, avec un mot de passe qu'on leur envoie. Et pour notre future boutique en ligne grand public, on réutilisera ces mêmes comptes invités. »

Questions :

  1. Quel modèle utiliser pour les consultants du cabinet, et pourquoi les comptes « maison » sont-ils une mauvaise idée ?
  2. Comment cadrer la confiance avec le tenant du cabinet, et comment éviter une double MFA au consultant ?
  3. Comment garantir que les accès des consultants disparaissent à la fin des 6 mois ?
  4. La « boutique en ligne grand public » relève-t-elle du même mécanisme ? Que répondez-vous sur la licence ?

Démarche attendue

  1. Collaboration B2B : inviter chaque consultant comme Guest. Les comptes « maison » sont une mauvaise idée car ils dupliquent des identités, imposent de gérer des mots de passe et leur rotation, et ne se coupent pas automatiquement quand le cabinet désactive le consultant chez lui.
  2. Cross-tenant access settings : ajouter le tenant du cabinet en organisation partenaire, régler l'inbound sur les apps nécessaires, et activer Trust MFA (et éventuellement Trust compliant devices) dans les trust settings pour accepter la MFA déjà faite chez le cabinet, sans double challenge. Ne pas l'activer dans les défauts globaux.
  3. Gouvernance P2 : provisionner l'accès via un package d'accès (entitlement management) porteur d'une expiration à 6 mois, ou à défaut une revue d'accès récurrente ciblant les invités avec retrait automatique. L'accès disparaît sans geste manuel oublié.
  4. Non : la boutique grand public relève du CIAM (External ID for customers), un tenant external distinct facturé au MAU — pas du B2B et pas couvert par E3 + P2. C'est un projet séparé avec son propre budget ; on ne réutilise pas les objets Guest pour du grand public.

Grille d'auto-évaluation