Teams multi‑tenant: tenant in rosso e accesso negato — guida completa alla diagnosi e al fix

In una POC multi‑tenant con quattro tenant Microsoft 365, Outlook e SharePoint funzionano ma uno dei tenant in Microsoft Teams compare “in rosso” e non è accessibile agli utenti degli altri tenant. Questa guida pratica spiega cause probabili, diagnostica e correzioni passo‑passo.

Indice

Scenario e sintomi

Contesto osservato:

Organizzazione multi‑tenant con quattro tenant Microsoft 365 e circa 12 utenti sincronizzati per la POC.
Outlook e SharePoint funzionano senza anomalie in tutti i tenant.
In Microsoft Teams, uno dei tenant appare contrassegnato in rosso nell’elenco profili; gli utenti provenienti dagli altri tenant non riescono ad accedervi. Gli altri tre tenant sono accessibili regolarmente.

Effetti tipici lato utente:

Errore “impossibile passare al tenant” o mancata visualizzazione di team/canali.
Notifiche e chat cross‑tenant assenti o incomplete.
Presenza e avatar che non si aggiornano quando si tenta lo switch verso il tenant “in rosso”.

Perché accade

Il comportamento è spesso dovuto a una combinazione di identità, policy e cache. Ecco le aree da ispezionare immediatamente.

Area	Che cosa verificare
Sincronizzazione cross‑tenant (Microsoft Entra ID)	Errori nei log di provisioning o mapping attributi non coerenti.
Conditional Access (CA)	Criteri che, di fatto, bloccano utenti esterni o impediscono la selezione del tenant.
Permessi guest in Teams	Utenti invitati come guest ma senza ruoli/canali corretti.
Cross‑tenant access settings	Impostazioni inbound/outbound non abilitate o non simmetriche tra i tenant.
Cache lato client	Dati obsoleti nell’app desktop possono far apparire il tenant come “in rosso”.

Checklist rapida

Se dovete sbloccare l’accesso in tempi rapidi, seguite questa lista compatta prima di approfondire:

Provate il browser InPrivate: se il tenant è accessibile via web, è probabile un problema di cache del client.
Controllate i Provisioning Logs in Entra ID del tenant “problematico”: nessun ciclo fallito? Attributi coerenti (UPN, mail)?
Verificate una policy di Conditional Access che restringa Guest or External o legga il TenantID nel grant/control.
Aprire il Teams Admin Center e verificare che gli utenti guest siano membri reali del team e dei canali coinvolti.
Controllare Cross‑tenant access: consentite inbound/outbound con B2B collaboration e Chat, Teams & Channels per i tenant partner.
Svuotate la cache del client desktop e ripetete il test.
Raccogliete i log (Audit e diagnostica Teams) e l’ID di correlazione che appare nel messaggio di errore.

Runbook di diagnosi e correzione

Confermare la sincronizzazione

Obiettivo: garantire che gli utenti esistano e siano allineati tra tutti i tenant.

In Microsoft Entra ID → Provisioning logs del tenant “in rosso”, verificate che l’ultimo ciclo sia completato e privo di errori per gli utenti della POC.
Confrontate UPN e mail dell’utente guest con l’indirizzo nel tenant di origine. Regola pratica: l’UPN del guest deve corrispondere all’indirizzo con cui è stato invitato; mapping incoerenti generano oggetti “ombra”.
Assicuratevi che non ci siano duplicati (stesso indirizzo con #EXT# e varianti) o ProxyAddresses confliggenti.

Verificare o disattivare in modo mirato i criteri di Conditional Access

Obiettivo: escludere che una policy di CA stia bloccando l’accesso cross‑tenant solo per Teams.

Elencate le policy che si applicano a Cloud apps come “Microsoft Teams” o a “All cloud apps”.
Cercate condizioni su Guest or external users, Device state (richiesta di dispositivo conforme) o Authentication context associato a Teams.
Individuate eventuali controlli Grant che richiedono MFA/Compliant device per utenti esterni: tali requisiti spesso impediscono lo tenant switch.
Test controllato: disabilitate temporaneamente (solo per un gruppo pilota) la policy sospetta e verificate se il tenant diventa accessibile. Re‑abilitate subito dopo il test e documentate l’esito.

Buona pratica: se state usando criteri differenziati per “Guest” e “Membro”, confermate che gli utenti cross‑tenant siano correttamente classificati come B2B guest e non come “membri” locali con attributi incompleti.

Controllare i permessi in Teams

Obiettivo: assicurare che gli utenti invitati come guest siano realmente in grado di accedere alle risorse.

Nel Teams Admin Center del tenant problematico, aprite il team interessato → sezione Membri. Verificate che gli utenti guest figurino nella lista e siano assegnati a canali corretti (standard, privati, condivisi).
Se necessario, rimuovete e reinvitate i guest; inviti obsoleti possono sopravvivere nella cache del client e generare errori di accesso.
Controllate le Policy di Guest Access e le impostazioni dei Shared Channels (Teams Connect). Per i canali condivisi è necessaria la configurazione cross‑tenant appropriata.

Rivedere le impostazioni di Cross‑tenant access

Obiettivo: confermare che i tenant si “fiduccino” reciprocamente per collaborazione e Teams.

In Entra ID → External Identities → Cross‑tenant access settings verificate quanto segue per ciascuna coppia di tenant:
- Inbound: consentite i tenant partner per B2B collaboration e “Chat, Teams & Channels”.
- Outbound: consentite agli utenti locali di uscire verso i tenant partner.
- Verificate la simmetria: una configurazione abilitata da un lato ma restrittiva dall’altro può bloccare lo switch o la visibilità.
Salvate e considerate fino a 15 minuti per la propagazione delle modifiche.

Svuotare la cache di Teams o usare la versione Web

Obiettivo: escludere che l’indicatore “in rosso” sia causato da dati locali obsoleti.

Chiudete completamente Teams.
Eliminate il contenuto della cartella: %appdata%\Microsoft\Teams.
Riaprite Teams e riprovate lo switch; in alternativa, testate via browser in finestra InPrivate.

Nota: una cache corrotta può far apparire il tenant “in rosso” anche se la configurazione lato servizio è corretta.

Consultare i log

Obiettivo: identificare errori oggettivi e correlare i tentativi di accesso con le policy.

Teams Admin Center → Diagnostics → Reports: cercate errori relativi a tentativi di tenant switch o a canali condivisi.
Microsoft 365 Audit Logs: utilizzate query che includono il campo TargetTenantId per tracciare accessi/operazioni cross‑tenant.

Escalation

Se il problema persiste nonostante i passaggi precedenti:

Aprire un ticket a Microsoft Support allegando i log di provisioning, screenshot delle impostazioni di cross‑tenant access e l’ID di correlazione (X‑MS‑CLUSTER‑ID o simili) visualizzato nell’errore.
Coinvolgere un partner Microsoft se sono richieste modifiche complesse a Conditional Access o ai flussi di identità.

Approfondimenti e suggerimenti

Limitazioni note

Prima di insistere su una correzione, verificate che lo scenario rientri nelle limitazioni supportate per organizzazioni multi‑tenant in Entra ID, in particolare quando sono in gioco canali condivisi e B2B direct connect. Disallineamenti tra capacità supportate e configurazione desiderata possono presentarsi come “tenant in rosso”.

Tenant Status e visibilità rapida

Per un controllo veloce dello stato dei tenant nell’organizzazione multi‑tenant potete usare Microsoft Graph, endpoint /beta/tenantRelationships/multiTenantOrganization/tenants per verificare se ciascun tenant risulta active o unavailable. È utile integrare questo controllo in un health‑check schedulato durante la POC.

Strategie di rollback graduale

Quando l’analisi impiega più tempo del previsto:

Create un ambiente di test ridotto con due soli tenant e un set minimo di utenti per riprodurre l’errore.
Disattivate progressivamente gli elementi sospetti (policy CA, trust cross‑tenant, feature di canali condivisi), misurando l’impatto dopo ogni change.
Applicate quanto appreso all’ambiente a quattro tenant solo dopo aver validato il fix nel laboratorio.

Procedura dettagliata, passo‑passo

Verifica della sincronizzazione in Entra ID

Aprite Provisioning logs nel tenant “in rosso” e filtrate per gli utenti POC.
Controllate Object matching: l’attributo chiave (di norma l’UPN) deve collegare correttamente l’utente sorgente all’oggetto guest.
Verificate i risultati parziali: successi con warning su attributi spesso indicano mapping non allineati (es. mail valorizzata in modo diverso da userPrincipalName).
Se necessario, correggete il mapping e forzate un full sync del job di provisioning.

Controllo accurato di Conditional Access

Concentratevi su tre aspetti:

Scope: la policy si applica a “All users” con esclusioni per i gruppi interni ma non per gli ospiti?
Client app: limitazioni al “mobile client and desktop” con eccezioni per il web possono spiegare perché via browser funziona ma il client è “in rosso”.
Grant controls: “Require device to be marked as compliant” per utenti guest tende a bloccare l’uso di Teams cross‑tenant.

Eseguite un A/B test con e senza policy per un piccolo gruppo per confermare la diagnosi.

Team membership e canali

Controllate che:

Gli utenti guest siano membri del team corretto e non solo del tenant.
Nel caso di canali privati, l’utente sia incluso esplicitamente; per i canali condivisi verificate anche la relazione cross‑tenant specifica del canale.
Le Team policies non impediscano la chat/collaborazione con esterni (distinguete Guest access da External access).

Cross‑tenant access: inbound e outbound

Per ciascun tenant “partner”:

In Inbound, abilitate B2B collaboration e Chat, Teams & Channels per il tenant partner.
In Outbound, consentite agli utenti locali di accedere al partner.
Se usate criteri per utente/gruppo (policy granulari), ricordate che una configurazione non simmetrica è una delle cause più comuni di “tenant in rosso”.

Cache del client e test via web

Molti “rossi” spariscono eliminando la cache:

%appdata%\Microsoft\Teams

Chiudete l’app, cancellate i file, riaprite e riprovate. In alternativa, usate il browser in modalità InPrivate per bypassare la cache del client.

Raccolta log e tracciabilità

Teams Diagnostics: esportate report specifici per tentativi di switch.
Microsoft 365 Audit: costruite query sul campo TargetTenantId per seguire i flussi cross‑tenant.
Correlation ID: quando compare un errore in console o nell’interfaccia, copiate l’ID (es. X‑MS‑CLUSTER‑ID) e includetelo nei ticket.

Modello decisionale

Usate l’albero decisionale seguente per accelerare l’analisi:

Browser InPrivate funziona?
- Sì → Svuotate cache del client → Riprovate.
- No → Passate a provisioning/CA.
Provisioning logs puliti?
- Sì → Verificate CA + Cross‑tenant access.
- No → Correggete mapping/UPN → Full sync → Test.
CA disabilitata per gruppo pilota sblocca lo switch?
- Sì → Rifinite la policy (esempi: escludere Guest, togliere “device compliant” per esterni).
- No → Controllate Cross‑tenant access e Team membership.
Cross‑tenant simmetrico?
- Sì → Verificate canali privati/condivisi e policy Teams.
- No → Allineate inbound/outbound e salvate (attendere propagazione).

Convalida del ripristino

Dopo il fix, eseguite questi test di conferma:

Lo switch al tenant prima “in rosso” avviene senza errori dal client desktop e dal browser.
Gli utenti guest vedono team e canali previsti e possono inviare messaggi.
La presenza si aggiorna correttamente tra tenant.
I log di audit non mostrano nuovi eventi di accesso negato sul TargetTenantId coinvolto.

Automazione e controlli con Microsoft Graph

Per monitoraggi ripetibili è utile uno script che interroga lo stato dei tenant e la reperibilità dei team. Spunti utili:

Endpoint /beta/tenantRelationships/multiTenantOrganization/tenants per recuperare l’elenco dei tenant e lo stato.
Verifiche dei service principals e delle policy cross‑tenant tramite le relative risorse Graph.
Esposizione di un health dashboard interno che segnali quando un tenant passa a unavailable.

Esempi di query e comandi

Audit e diagnostica

# Esempio (PowerShell Exchange Online / Unified Audit Log):
Ricerca per attività cross‑tenant con TargetTenantId
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
  -Operations "TeamAccess", "AddedToTeam", "MemberRemoved" `
  -ResultSize 5000 | Where-Object { $_.AuditData -match "TargetTenantId" }

Verifica oggetti guest

# Esempio (PowerShell Graph)
Connettetevi con scope Directory.Read.All
Elenco utenti guest con UPN e mail
(Sintassi indicativa – adattate a moduli/versioni in uso)
Get-MgUser -Filter "userType eq 'Guest'" -All `
  | Select-Object Id, UserPrincipalName, Mail, ExternalUserState

Controllo rapido dei team e membership

# (PowerShell Graph) – elenco team e conteggio membri/guest
Get-MgTeam -All | ForEach-Object {
  $members = Get-MgTeamMember -TeamId $_.Id -All
  [PSCustomObject]@{
    Team            = $_.DisplayName
    MemberCount     = ($members | Where-Object {$_.Roles.Count -eq 0}).Count
    GuestCount      = ($members | Where-Object {$_.Roles -contains "guest"}).Count
  }
}

Domande frequenti

Perché Outlook e SharePoint funzionano ma Teams no?

Teams richiede set di permessi e trust specifici per chat e canali (B2B collaboration e Chat, Teams & Channels). È possibile che la collaborazione a livello SharePoint/Exchange sia consentita mentre il trust per Teams non sia simmetrico o sia limitato da CA.

Il tenant resta in rosso dopo avere aggiornato le impostazioni. È normale?

Sì, la propagazione può richiedere fino a 15 minuti. Pulite la cache e riprovate, quindi controllate i log se l’anomalia persiste.

Serve aggiungere gli utenti guest direttamente ai team?

Sempre. Essere guest del tenant non implica l’accesso ai singoli team/canali. Per i canali privati, l’inclusione è esplicita; per i canali condivisi, verificate anche le relazioni cross‑tenant.

Una singola policy CA può generare l’errore “tenant in rosso”?

Sì. Policy che richiedono dispositivo conforme, blocchi su Guest o restrizioni sulle app possono impedire lo switch verso un tenant specifico.

Template operativo di comunicazione

Azione: stiamo aggiornando le impostazioni di accesso cross‑tenant per il tenant <NomeTenant>.

Impatto: per ~15 minuti potreste non riuscire a passare al tenant o vedere il tenant “in rosso”.

Cosa fare: al termine, chiudete e riaprite Teams o usate il browser InPrivate. Se l’errore persiste, inviate uno screenshot includendo l’ID di correlazione.

Tabella di controllo stampabile

Controllo	Stato	Note
Provisioning logs senza errori	OK / KO	UPN e mail coerenti tra tenant
CA: nessun blocco su Guest/External	OK / KO	Esclusioni gruppo pilota testate
Guest aggiunti ai team/canali corretti	OK / KO	Privati/condivisi verificati
Cross‑tenant access simmetrico	OK / KO	Inbound/Outbound per ogni coppia di tenant
Cache client svuotata / test web	OK / KO	Tenant visibile senza “rosso”
Log e Correlation ID raccolti	OK / KO	Pronti per supporto/escalation

Riepilogo azioni consigliate

Confermare la sincronizzazione in Entra ID e correggere eventuali mismatch di attributi (UPN/mail).
Controllare/Disattivare in via sperimentale le policy CA che coinvolgono utenti esterni o richiedono dispositivi conformi.
Verificare i permessi in Teams: i guest devono essere membri dei team/canali di destinazione.
Allineare le impostazioni Cross‑tenant access (inbound e outbound) tra i tenant partner.
Svuotare cache del client e riprovare in InPrivate.
Consultare i log di Teams e Microsoft 365; se necessario, escalate con i dettagli raccolti.

Errori tipici da evitare

Rendere più permissiva la CA globalmente invece di isolare un gruppo pilota: rischiate di aprire falle di sicurezza.
Invitare guest al tenant ma non ai team: gli utenti entreranno nel tenant, ma non vedranno nulla.
Configurare Cross‑tenant access solo in una direzione: lo switch può fallire in modo intermittente.
Dimenticare la propagazione: cambiare impostazioni e testare dopo pochi secondi può produrre falsi negativi.

Conclusioni

Il “tenant in rosso” in Teams con Outlook e SharePoint funzionanti indica quasi sempre un disallineamento tra identità, policy e trust specifico di Teams. Seguendo il runbook proposto—sincronizzazione, CA, permessi, cross‑tenant, cache e log—potete ripristinare l’accesso in modo ripetibile e sicuro, trasformando l’esperienza multi‑tenant da fragile a affidabile.

Appendice: riferimento sintetico delle azioni

Confermare la sincronizzazione
- Entra ID → Provisioning logs: controllate errori e completamento dei cicli.
- UPN guest in linea con l’indirizzo nel tenant di origine.
Verificare o disattivare temporaneamente la Conditional Access
- Cercare policy che limitano l’accesso in base a TenantID o Guest‑or‑ExternalUser.
- Disabilitare la CA solo per un gruppo pilota e verificare se il tenant diventa accessibile.
Controllare i permessi in Teams
- Teams Admin Center → Team → Membri: utenti guest effettivamente presenti.
- Se necessario, rimuoverli e reinvitarli.
Rivedere le impostazioni di cross‑tenant access
- Entra ID → External Identities → Cross‑tenant access settings.
- Inbound: consentire i tenant partner come B2B collaboration + Chat, Teams & Channels.
- Outbound: consentire l’uscita verso i tenant partner.
- Salvare e attendere la propagazione (fino a 15 minuti).
Svuotare la cache di Teams o usare la versione Web
- %appdata%\Microsoft\Teams → eliminare il contenuto (con Teams chiuso).
- Oppure testare dal browser InPrivate per escludere il client desktop.
Consultare i log
- Teams Admin Center → Diagnostics → Reports per errori di tenant switch.
- Microsoft 365 Audit Logs con query su TargetTenantId.
Escalation
- Fornire a Microsoft Support i log di provisioning e l’ID di correlazione di errore (X‑MS‑CLUSTER‑ID).
- Coinvolgere un partner Microsoft se servono modifiche complesse a CA o politica di identità.

Con i suggerimenti supplementari, potete inoltre:

Verificare le limitazioni supportate per le organizzazioni multi‑tenant in Entra ID.
Interrogare con Graph l’elenco dei tenant (/beta/tenantRelationships/multiTenantOrganization/tenants) per uno status check rapido.
Eseguire un gradual rollback su un ambiente a due tenant per isolare la causa senza impatti sulla produzione.

Se applicate questa guida in maniera disciplinata—prima la convalida dell’identità, poi i controlli di accesso e infine la pulizia del client—ottenete una traiettoria chiara: dal sintomo (“tenant in rosso”) alla soluzione stabile e documentata.