Acesso a Tenant em ambiente Multi‑Tenant no Microsoft Teams: guia completo de diagnóstico e correção no Entra ID

Um tenant aparece a vermelho no seletor de perfis do Microsoft Teams e fica inacessível, apesar de Outlook, SharePoint e a pesquisa de diretório funcionarem bem. Este guia prático mostra como diagnosticar e corrigir o problema em organizações Multi‑Tenant com Microsoft Entra ID e Teams.

Índice

Cenário e sintomas

Uma organização criou um ambiente Multi‑Tenant com quatro tenants Microsoft 365/Entra ID e sincronizou 12 utilizadores para um piloto. Em três tenants, tudo flui; no quarto, o tenant surge a vermelho no seletor de perfis do Teams e não abre. O grupo/Team existe, os convites foram enviados e os membros aparecem, mas o acesso falha para utilizadores externos.

Sintoma típico: ao alternar para a organização afetada no Teams, o perfil fica marcado a vermelho, surge mensagem de erro de acesso ou o cliente entra em loop de autenticação.
Em outros workloads: Outlook e SharePoint funcionam, reforçando que o problema está ligado a políticas ou relações de confiança específicas do Teams/B2B.
Escopo: o erro afeta apenas um tenant parceiro, o que aponta para Cross‑Tenant Access Settings ou Acesso Condicional inconsistentes nesse par.

Por que isto acontece

O Microsoft Teams depende de tokens emitidos pelo Microsoft Entra ID. Em cenários Multi‑Tenant, esses tokens atravessam fronteiras de diretórios via B2B (colaboração convidado) ou B2B Direct Connect (canais partilhados). Se Cross‑Tenant Access ou políticas de Acesso Condicional estiverem desalinhadas entre os tenants, o token pode ser bloqueado ou exigir sinais (MFA/dispositivo) que o tenant remoto não confia. O resultado: o Teams marca a organização como indisponível.

As causas dominantes são:

Cross‑Tenant Access Settings com bloqueio inbound/outbound, apps excluídas ou falha em confiar no MFA/dispositivo do parceiro.
Acesso Condicional exigindo MFA, dispositivo compatível ou localização confiável, sem aceitar os sinais de segurança oriundos do tenant de origem.
Permissões de convidado ou associação a Teams/canais inconsistentes (utilizador consta no Azure AD mas não está efetivamente no Team ou no Canal).
Sincronização entre tenants (Cross‑Tenant Synchronization) incompleta: atributos obrigatórios não provisionados, escopos incorretos ou erros no motor de provisionamento.
Cache/cliente do Teams corrompido, mascarando uma correção já aplicada no back‑end.

Fluxo de diagnóstico em cinco minutos

Se precisa de uma visão rápida antes do mergulho profundo, siga este caminho:

Validar se o utilizador existe e está ativo no tenant de destino (Guest ou Member) e se consta no Team/Canal certo.
No Entra ID do tenant de destino, abrir External Identities → Cross‑Tenant Access Settings e confirmar que o tenant parceiro está permitido inbound/outbound e que Trust settings (MFA/Dispositivo) estão de acordo com as políticas.
Comparar políticas de Acesso Condicional entre os quatro tenants. Se necessário, excluir temporariamente o grupo piloto de políticas agressivas para testar.
Limpar o cache do Teams ou testar em teams.microsoft.com com janela anónima/perfil limpo.
Se ainda falhar, consultar Sign‑in logs (Entra ID) filtrando pelo tenant problemático e pela app Teams para encontrar o error code e a política que bloqueou.

Tabela de ações recomendadas

Etapa	Objetivo	Pontos‑chave
Rever sincronização entre tenants	Garantir que a Cross‑Tenant Synchronization está correta no Entra ID.	Verificar logs de provisionamento; confirmar atributos exigidos; conferir escopos/filtros de grupos.
Auditar Acesso Condicional	Identificar regras que bloqueiam utilizadores de tenants externos.	Comparar políticas dos quatro tenants; testar com exclusão temporária do grupo piloto; validar apps alvo.
Confirmar permissões de convidados	Assegurar que utilizadores externos têm as funções corretas.	Verificar se estão no Team/Canal; validar função “Membro”/“Guest” no Teams Admin Center.
Configurar Cross‑Tenant Access	Controlar tráfego inbound/outbound entre tenants.	Permitir autenticação/partilha para os três tenants parceiros; checar bloqueios por domínio ou app.
Limpar cache e testar no Web	Eliminar problemas locais do cliente.	Apagar cache do Teams Desktop; validar em teams.microsoft.com; testar com outro perfil de navegador.
Analisar logs detalhados	Encontrar erros de autenticação/políticas.	Teams Admin Center (Diagnostics & Logs); Entra ID Sign‑in logs, filtrando por tenant/app.
Escalar suporte	Obter suporte avançado se for erro de plataforma.	Consolidar tickets; pedir escalation engineer com back‑end traces.

Passo a passo detalhado

Rever a sincronização entre tenants (Cross‑Tenant Synchronization)

Se usa Cross‑Tenant Synchronization para criar “representações” de utilizadores noutros tenants, confirme:

O conector/parceiro certo está configurado e ativo (inbound/outbound conforme desenho).
Nos logs de provisionamento do Entra ID, não há falhas para os 12 utilizadores do piloto (erros de atributo, escopo, mapeamento ou consentimento).
Os atributos mínimos (DisplayName, UserPrincipalName, ExternalUserState) foram criados nas contas de destino.
Existe grupo de segurança para isolar o piloto, evitando que políticas “agressivas” atinjam os testers enquanto valida.

Resultado esperado: as contas aparecem no tenant de destino e podem ser adicionadas como Guest/Membro ao Team. Se o provisioning reporta sucesso mas o Teams não abre, prossiga para políticas.

Auditar políticas de Acesso Condicional

O Acesso Condicional é o maior causador de “tenant a vermelho” no Teams. Procure:

Políticas aplicadas a All cloud apps ou ao Office 365/Microsoft Teams que exijam MFA, dispositivo compatível ou localização específica.
Conflitos entre “Grant controls” (ex.: exigir MFA e dispositivo compatível simultaneamente para convidados).
Uso de filtros por user risk ou sign‑in risk que marcam convidados como alto risco.
Regras que não confiam no MFA realizado no tenant de origem (ver “Trust settings” na seção Cross‑Tenant).

Como testar com segurança: crie um exclusion group só com os 12 utilizadores do piloto e exclua‑o temporariamente das políticas mais restritivas. Se o acesso funcionar, a causa está no Acesso Condicional; refine a política adicionando session controls ou confiando nos sinais do parceiro.

Confirmar permissões de convidados e associação a Teams

Confirme os seguintes pontos:

O utilizador aceitou o convite (estado “Redeemed”).
O utilizador aparece como Guest/Membro no Team correto e, se necessário, no Canal específico (canais partilhados requerem B2B Direct Connect ativo entre os tenants).
As políticas de Guest access e de External access no Teams Admin Center permitem colaboração com o domínio do parceiro.

Armadilha comum: o utilizador está no Azure AD do destino, mas não foi adicionado ao Team (ou foi removido de um canal privado/partilhado). O acesso ao Team falhará, mesmo que o “tenant switch” pareça possível.

Configurar Cross‑Tenant Access Settings (Entra ID → External Identities)

Verifique, em ambos os tenants da relação, os seguintes aspetos:

Inbound/Outbound access: o parceiro está permitido (não apenas “Default”). Se usa padrões restritivos, crie partner overrides explícitos para cada tenant.
Aplicações: garanta que o Microsoft Teams (e “Office 365”) não está excluído por lista de apps permitidas/bloqueadas.
Trust settings: quando a política exigir MFA ou dispositivo, ative a opção de confiar no MFA e no estado de dispositivo do tenant de origem; isso evita duplicar desafios ou bloquear o token.
B2B Collaboration vs B2B Direct Connect: para canais partilhados, B2B Direct Connect deve estar permitido bilateralmente; para acesso convidado, foque em B2B Collaboration e permissões de convidado.

Boa prática: configure uma política por parceiro (um override por tenant) com descrição, contacto e janela de manutenção. Isto reduz erros quando há mais de dois tenants.

Limpar cache do Teams e testar no Teams Web

Depois de alterar políticas, limpe o cliente para evitar tokens antigos:

Windows (Teams clássico): sair do Teams → apagar conteúdo de %appdata%\Microsoft\Teams (pastas Cache, Code Cache, databases, GPUCache, IndexedDB).
Windows (novo Teams): sair do Teams → limpar %LocalAppData%\Microsoft\Teams ou %LocalAppData%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache.
macOS: sair do Teams → apagar ~/Library/Application Support/Microsoft/Teams (pastas de cache principais).
Teste cruzado: abrir teams.microsoft.com em janela anónima ou perfil de navegador novo.

Analisar logs detalhados (Teams Admin Center e Sign‑in logs)

Nos logs de início de sessão do Entra ID, filtre por:

Aplicação: Microsoft Teams (ou Office 365).
Resource Tenant ID: o ID do tenant que aparece a vermelho.
Conditional Access: observe se o estado é “Failure” e qual política foi aplicada.

Erros frequentes e leituras úteis:

Código	Indica	Ação
53003	Bloqueio por Acesso Condicional	Revisar política, escopo e confiar sinais do parceiro
50076	MFA requerido	Ativar confiança no MFA do parceiro ou ajustar a política
53000	Dispositivo não compatível	Confiar no estado de conformidade do dispositivo externo ou dispensar para convidados
700016	Aplicação não encontrada/permitida	Checar lista de apps permitidas/bloqueadas no Cross‑Tenant

Se o log mostrar sucesso em Exchange/SharePoint mas falha em Teams, trate como exceção específica da aplicação (app bloqueada ou sessão não confiável para o Teams).

Quando escalar para suporte

Se, após aplicar as correções, o Teams continuar a marcar o tenant a vermelho, centralize evidências para escalamento:

IDs de correlação e timestamps das falhas no Sign‑in logs.
Capturas do Cross‑Tenant Access Settings inbound/outbound para o parceiro.
Resumo das políticas de Acesso Condicional que se aplicam ao grupo piloto.
Tickets já abertos e período de ocorrência.

Validações rápidas por área

Microsoft Entra ID

External Identities → Cross‑Tenant Access Settings → Partner tenants: o tenant problemático está ativo? As trust settings de MFA/dispositivo estão coerentes?
Cross‑Tenant Synchronization: logs sem erro, mapeamentos corretos, escopo restrito ao grupo piloto.

Teams Admin Center

External access: domínios permitidos e política em modo “Allow” para o parceiro.
Guest access: convidado pode criar, ler, partilhar conforme esperado? Se canais partilhados, B2B Direct Connect ativo.
Team membership: utilizadores efetivamente listados como Membro/Guest no Team e, se aplicável, no canal privado/partilhado.

Cliente/Dispositivo

Cache limpo e sessão renovada.
Navegador sem extensões de controlo que injetem cabeçalhos de tenant restrictions.
Hora e fuso do dispositivo corretos (evita anomalias de token).

Scripts úteis (PowerShell/Graph)

Listar acessos aplicados ao parceiro (Graph PowerShell):

# Conectar com permissões de leitura de políticas e auditoria
Connect-MgGraph -Scopes "Policy.Read.All","AuditLog.Read.All","Directory.Read.All"

IDs

\$partnerTenantId = "\"

Ver o override do parceiro (inbound/outbound + trust)

Get-MgPolicyCrossTenantAccessPolicyPartner -CrossTenantAccessPolicyConfigurationPartnerTenantId \$partnerTenantId |
Select-Object PartnerId, DisplayName, `    @{N="InboundDefault";E={$_.Inbound.Default}},`
@{N="OutboundDefault";E={$\_.Outbound.Default}}

Sign-ins recentes do Teams contra o tenant de destino

Get-MgAuditLogSignIn -All |
Where-Object { \$.ResourceTenantId -eq \$partnerTenantId -and \$.AppDisplayName -match "Teams" } |
Select-Object CreatedDateTime, UserDisplayName, ConditionalAccessStatus, `                @{N="Policy";E={$_.AppliedConditionalAccessPolicies.DisplayName -join "; "}},`
Status |
Format-Table -AutoSize

Validar se o utilizador consta no Team (Teams PowerShell):

# Requer MicrosoftTeams module
Connect-MicrosoftTeams

\$groupId = "\"
Get-TeamUser -GroupId \$groupId | Where-Object {$\.User -match "\"}

Dica: mantenha estes comandos como “runbooks” para pilotos multi‑tenant. Automatizar verificações reduz tempo de diagnóstico em novas ondas de migração.

Cenários comuns e correções

Cenário	Sinal	Causa provável	Correção
Convidado cumpre MFA no tenant de origem, mas continua bloqueado no destino	Loop de MFA ou falha 50076	Destino não confia no MFA do parceiro	Em Cross‑Tenant → Trust settings → aceitar MFA do parceiro; ajustar a política de CA
Exige dispositivo compatível para convidados	Falha 53000	CA solicita device compliance que não é confiado	Confiar no estado de dispositivo do parceiro ou aplicar política menos restritiva ao grupo piloto
Tenant aparece a vermelho apenas para canais partilhados	Teams abre, mas canal partilhado não	B2B Direct Connect desativado ou bloqueado	Permitir B2B Direct Connect bilateralmente no Cross‑Tenant
Teams bloqueado, mas SharePoint/Outlook funcionam	Erro somente na app Teams	App Teams excluída/negada em Cross‑Tenant ou política específica	Permitir a app Teams nas listas de apps; revisar política por aplicação
Utilizador existe como convidado mas não vê o conteúdo	Sem canais/ficheiros	Não está no Team/Canal correto	Adicionar ao Team e ao canal privado/partilhado certo; sincronizar permissões

Boas práticas para organizações Multi‑Tenant

Grupos piloto dedicados: agrupe testers e aplique políticas de CA mais brandas durante a validação.
Overrides por parceiro: não dependa apenas do “Default”. Crie e documente um override por tenant, com trust de MFA/dispositivo alinhado.
Modelo de governança: defina quem cria Teams, quem convida externos e como revisar membros periodicamente.
Observabilidade: dashboards de falhas por app/tenant, com alarmes para códigos 53003/50076.
Gestão de mudanças: janelas de alteração e rollback pré‑definidos para CA/Cross‑Tenant, com check de cliente (cache) após cada ajuste.

Limitações conhecidas em ambientes Multi‑Tenant

A funcionalidade multi‑tenant no Teams evolui continuamente, mas há áreas com restrições adicionais. Entre as mais comuns:

Apps de terceiros podem não funcionar de forma idêntica entre tenants parceiros, dependendo das políticas.
PSTN/Telefonia e gravações podem ter comportamentos diferentes por conta de licenças e armazenamento.
Nem todos os recursos são replicados automaticamente pelo MTO/Cross‑Tenant; confirme suporte por workload antes do piloto.

Checklist final de resolução

✅ Cross‑Tenant Synchronization sem erros e com atributos exigidos.
✅ Convidados adicionados aos Teams/canais corretos e convites aceites.
✅ Cross‑Tenant Access: parceiro permitido, trust de MFA/dispositivo configurado e Teams não bloqueado por listas de apps.
✅ Acesso Condicional: políticas comparadas entre tenants, exclusão temporária aplicada ao grupo piloto e regras ajustadas.
✅ Cache do cliente limpo e teste em teams.microsoft.com concluído.
✅ Sign‑in logs revistos; códigos de erro e políticas identificados.

Conclusão

A causa mais provável para um tenant “a vermelho” no Teams é a combinação de Acesso Condicional e Cross‑Tenant Access descoordenados, bloqueando o token de sessão para aquele parceiro específico. Ao seguir o roteiro deste artigo — validar sincronização, confirmar permissões, alinhar trust de MFA/dispositivo e testar com cache limpo — é normalmente possível restaurar o acesso. Se, ainda assim, o problema persistir, reúna os logs e escale para o suporte da Microsoft, solicitando análise de back‑end traces para encurtar o tempo até à correção.