Le cross-tenant access settings sono il pannello di controllo centrale, in Microsoft Entra ID, con cui un’organizzazione governa in modo granulare come collabora con altri tenant Entra. Sostituiscono l’approccio “tutto o niente” delle vecchie impostazioni B2B, permettendo di decidere per ogni tenant partner cosa è consentito in ingresso e in uscita. Chi amministra le identità deve capire quando basta la policy di default e quando serve una configurazione dedicata.

Default settings vs organization-specific settings

Esistono due livelli, ed è cruciale distinguerli:

  • Default settings: la baseline applicata a tutti i tenant esterni per i quali non hai definito una regola specifica. Definisce il comportamento generale della collaborazione B2B.
  • Organization-specific settings: policy per un singolo tenant partner, identificato dal suo tenant ID o dominio. Sovrascrivono la default solo per quel partner.

La logica è quella dell’eccezione mirata: mantieni una default restrittiva e apri deroghe puntuali per i partner di cui ti fidi. Se un tenant non ha una regola dedicata, eredita la default.

Controllo inbound e outbound

Ogni policy si articola su due direzioni indipendenti:

  • Inbound access: chi arriva dall’esterno verso le tue risorse. Decidi quali users and groups del tenant esterno possono essere invitati/accedere e a quali applications interne.
  • Outbound access: i tuoi utenti che accedono a risorse di un tenant esterno. Controlli quali tuoi users/groups possono uscire e verso quali app del partner.

In entrambe le direzioni puoi scegliere Allow all oppure Block all / Allow specific limitando a gruppi e app precisi. Questo consente scenari come: “consenti solo al gruppo Progetto-X di accedere all’app SharePoint del partner Contoso, e blocca tutto il resto”.

Trust settings: fidarsi di MFA e device del tenant esterno

I trust settings (nella sezione inbound) sono l’elemento più insidioso e più valutato all’esame. Per default, quando un guest user accede alle tue risorse, il tuo resource tenant non si fida delle credenziali multifactor o dello stato del device provenienti dal tenant di origine (home tenant). Risultato: se una tua Conditional Access policy richiede MFA, il guest deve rifare l’MFA nel tuo tenant, con esperienza degradata.

Attivando gli inbound trust settings puoi far accettare al resource tenant:

  • Trust multifactor authentication from Microsoft Entra tenants — l’MFA già soddisfatta nel home tenant vale anche da te.
  • Trust compliant devices — device marcati compliant da Intune nel tenant esterno.
  • Trust Microsoft Entra hybrid joined devices.

Senza questi trust, le tue Conditional Access policy che richiedono device compliant non saranno mai soddisfatte dai guest, perché la registrazione del device vive nel home tenant.

B2B direct connect e Teams shared channels

B2B collaboration classica invita un utente esterno come guest object nella tua directory. B2B direct connect è diverso: non crea un guest object. Stabilisce un trust bidirezionale tra tenant e l’utente esterno accede rimanendo autenticato con la propria identità. Oggi lo scenario supportato principale sono gli shared channels di Microsoft Teams: l’utente partecipa al canale condiviso senza cambiare tenant né comparire come guest. Va abilitato esplicitamente in inbound e outbound su entrambi i lati.

Self-service sign-up via user flow

Per scenari in cui non conosci in anticipo gli utenti esterni (portali, community), configuri un self-service sign-up user flow: gli utenti si registrano autonomamente creando un account guest, con identity provider come Microsoft account, Google o email one-time passcode. Puoi arricchire il flusso con API connectors e user attributes per raccogliere dati o applicare logiche di approvazione.

Trappole tipiche d’esame

  • I guest devono rifare l’MFA nel tuo tenant nonostante l’abbiano già fatta a casa loro → non hai configurato gli inbound trust settings: abilita Trust multifactor authentication nella organization-specific setting del partner.
  • Serve collaborazione su un canale Teams senza aggiungere guest alla directory → B2B direct connect con shared channels, non B2B collaboration.
  • Vuoi consentire l’accesso solo a un gruppo specifico di un partner, bloccando gli altri → organization-specific inbound settings con Allow specific users and groups, lasciando la default su blocco.
  • Una Conditional Access policy “require compliant device” non passa mai per i guest → attiva Trust compliant devices negli inbound trust; lo stato compliant vive nel home tenant.
  • Utenti esterni sconosciuti devono registrarsi da soli su un portale → self-service sign-up user flow, non inviti B2B manuali.