Fundamentação Teórica: Manage external users

---

1. Intuição Inicial

Imagine que sua empresa está desenvolvendo um projeto com uma consultoria externa. Os consultores precisam acessar alguns documentos no SharePoint, abrir chamados no sistema de ITSM e talvez até visualizar dashboards no Power BI. Mas eles não são funcionários da sua empresa. Você não quer criar contas internas para eles, porque quando o projeto terminar você precisará lembrar de removê-las, e enquanto existirem, elas aparecem no seu diretório como se fossem funcionários.

O Microsoft Entra ID resolve isso com o conceito de usuário externo (ou guest user): uma identidade que existe no seu diretório, pode receber permissões para acessar recursos, mas cuja autenticação é gerenciada pelo provedor de identidade original do usuário, seja outro tenant do Azure, uma conta Microsoft pessoal, Google, Facebook ou qualquer provedor compatível com federação.

O consultor usa a senha que já tem na empresa dele. Você só controla o que ele pode acessar no seu tenant, não como ele prova quem é.

---

2. Contexto

O gerenciamento de usuários externos faz parte de um conjunto mais amplo de funcionalidades do Entra ID chamado Microsoft Entra External ID (anteriormente conhecido como Azure AD B2B, de Business-to-Business). É a camada que permite colaboração segura entre organizações distintas.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Para o AZ-104, o foco é o B2B Collaboration: convidar usuários externos para o seu tenant como guests, gerenciar o que podem acessar e controlar o ciclo de vida desses acessos.

O B2B Direct Connect e o External ID for Customers (B2C) estão fora do escopo do AZ-104 e são mencionados apenas para contextualizar o panorama completo.

---

3. Construção dos Conceitos

3.1 O que é um Guest User

Um guest user é um objeto de usuário no seu tenant com userType igual a "Guest". Diferente de um usuário membro (userType: "Member"), o guest não tem uma senha gerenciada pelo seu tenant. Quando ele tenta acessar um recurso, o seu tenant (chamado de resource tenant ou tenant convidante) redireciona a autenticação para o provedor de identidade original do usuário (chamado de home tenant ou tenant de origem).

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Esse modelo é fundamental: o resource tenant controla a autorização (o que o guest pode fazer), mas o home tenant controla a autenticação (quem o usuário é e como ele prova isso).

3.2 Provedores de Identidade Suportados

O usuário externo não precisa ter uma conta em outro tenant Azure. Os provedores aceitos são:

Provedor	Exemplo de conta	Observação
Microsoft Entra ID (outro tenant)	joao@empresa-parceira.com	Fluxo mais limpo para colaboração corporativa
Conta Microsoft pessoal	joao@hotmail.com, joao@outlook.com	Suportado, mas menos recomendado para ambientes corporativos
Google	joao@gmail.com	Requer configuração de federação com Google no tenant
Facebook	Conta do Facebook	Possível, mas raramente usado em contexto corporativo
Email OTP (One-Time Password)	Qualquer endereço de e-mail	Para contas sem provedor de identidade federated; o Azure envia um código por e-mail a cada login
SAML/WS-Fed	Qualquer IdP corporativo compatível	Para parceiros com seu próprio provedor de identidade que não é Azure

O Email OTP é o mecanismo de fallback: se o usuário convidado não tem nenhum provedor de identidade configurado, o Azure envia um código de uso único para o e-mail. Isso garante que qualquer pessoa com um e-mail pode ser convidada, independentemente do seu provedor.

3.3 O Processo de Convite (Invitation)

O convite é o mecanismo pelo qual um usuário externo é adicionado ao tenant. O fluxo tem etapas bem definidas:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Estado "PendenteAceite": enquanto o convite não for resgatado, o usuário existe no diretório com o status invitationState: PendingAcceptance. Ele ainda não pode acessar recursos. O link de convite pode ser reenviado pelo administrador se o usuário não o recebeu ou o perdeu.

O resgate do convite envolve o guest:

1. Clicar no link do e-mail
2. Ser redirecionado ao seu provedor de identidade para autenticar
3. Revisar e aceitar as permissões de acesso
4. Ser redirecionado ao recurso original

Após o resgate, o objeto do usuário no tenant convidante fica marcado como ativo e o usuário pode acessar os recursos para os quais recebeu permissão.

3.4 Permissões Padrão de Guests

Por padrão, guests têm permissões muito mais restritas no diretório do que usuários membros. Isso é uma medida de segurança para evitar que um parceiro externo explore informações do seu diretório.

Capacidade	Usuário Membro	Guest (padrão)
Ler perfis de outros usuários	Sim	Limitado (não pode navegar o diretório)
Ler membros de grupos	Sim (grupos públicos)	Não (a menos que membro do grupo)
Registrar aplicações	Sim	Não (configurável)
Convidar outros guests	Sim (configurável)	Não (configurável)
Ler propriedades do tenant	Sim	Não
Criar grupos de segurança	Sim (configurável)	Não

As permissões padrão de guests podem ser ajustadas em Microsoft Entra ID > External Identities > External collaboration settings.

3.5 Configurações de Colaboração Externa

O tenant possui configurações globais que controlam quem pode convidar guests e de quais domínios:

Quem pode convidar guests (Guest invite settings):

Configuração	Quem pode convidar
Anyone in the organization can invite	Todos os usuários membros
Member users and users assigned to specific admin roles can invite	Membros + admins com papel de Guest Inviter
Only users assigned to specific admin roles can invite	Apenas admins (mais restritivo)
No one can invite (disable guest access)	Ninguém

Restrições de domínio (Allow/Deny list):

Você pode configurar uma lista de domínios permitidos (allowlist) ou bloqueados (denylist) para convites:

• Allowlist: apenas usuários de domínios listados podem ser convidados. Exemplo: só aceitar guests de empresa-parceira.com e consultoria.com.
• Denylist: qualquer domínio exceto os listados pode ser convidado. Exemplo: bloquear convites de concorrente.com.

As duas listas são mutuamente exclusivas: você usa uma ou outra, nunca as duas simultaneamente.

---

4. Visão Estrutural

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Um ponto importante desta estrutura: guests são sujeitos ao Acesso Condicional do tenant convidante, não apenas do tenant de origem. Você pode criar políticas de Acesso Condicional que se aplicam especificamente a guests, exigindo, por exemplo, que todos os acessos de externos passem por MFA gerenciado pelo seu tenant, independentemente do que o tenant de origem exige.

---

5. Funcionamento na Prática

Fluxo de Convite e Acesso

O ciclo completo de um usuário externo, do convite ao acesso:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Comportamentos Importantes e Não Óbvios

O guest já existe em outro tenant: quando você convida joao@empresa-parceira.com, se esse endereço já tem um objeto guest em outro tenant Azure, o Entra ID cria um objeto separado no seu tenant. Cada tenant tem sua própria representação do guest, com seus próprios acessos e configurações.

Acesso Condicional do home tenant pode bloquear: se o home tenant do guest tem uma política de Acesso Condicional que bloqueia logins de fora de certas redes, o guest pode não conseguir autenticar mesmo que o seu tenant (resource tenant) permita o acesso. O guest está sujeito às políticas dos dois tenants.

MFA: quem exige e quem executa: se o seu tenant tem uma política de Acesso Condicional que exige MFA para todos os guests, o Azure solicita o MFA no momento do acesso. O guest pode satisfazer esse MFA usando o MFA configurado no home tenant (se o home tenant for outro tenant Azure com MFA ativo) ou o Azure pode solicitar um MFA adicional. Esse comportamento é configurável via trust settings nas configurações de colaboração externa.

Trust settings: você pode configurar o seu tenant para confiar nas afirmações de MFA e de dispositivos conformes do home tenant. Se habilitado, um guest que já completou MFA no home tenant não precisará refazer MFA no seu tenant. Se desabilitado, o seu tenant exigirá MFA independentemente.

Representação do Guest no Diretório

O UPN de um guest no tenant convidante tem um formato especial:

joao_empresa-parceira.com#EXT#@contoso.onmicrosoft.com

O #EXT# é um marcador que indica que é um usuário externo. O endereço real do usuário (joao@empresa-parceira.com) fica armazenado na propriedade mail do objeto. Isso é importante porque scripts e filtros precisam lidar com esse formato especial ao trabalhar com guests.

---

6. Formas de Implementação

6.1 Portal do Azure

Quando usar: convidar usuários pontuais, revisar acessos, verificar status de convites pendentes.

Caminho: Microsoft Entra ID > Users > New user > Invite external user

Campos a preencher:

• Email: o endereço de e-mail do usuário externo
• Display Name: como o nome aparecerá no seu diretório
• Invitation message: mensagem personalizada incluída no e-mail de convite (opcional, mas recomendada para dar contexto ao guest)
• Groups: você pode já adicionar o guest a grupos no momento do convite
• Roles: você pode já atribuir papéis de diretório (raramente necessário para guests)

6.2 PowerShell (Microsoft Graph PowerShell SDK)

Quando usar: convidar múltiplos guests, automação, integração com fluxos de onboarding.

Convidar um usuário externo:

New-MgInvitation `
  -InvitedUserEmailAddress "joao@empresa-parceira.com" `
  -InvitedUserDisplayName "João Silva (Empresa Parceira)" `
  -InviteRedirectUrl "https://myapps.microsoft.com" `
  -SendInvitationMessage:$true

O parâmetro InviteRedirectUrl define para onde o usuário é redirecionado após resgatar o convite. Usar https://myapps.microsoft.com é comum pois leva o guest ao portal de aplicações onde ele pode ver o que tem acesso.

Convidar múltiplos guests a partir de CSV:

Import-Csv -Path "guests.csv" | ForEach-Object {
    New-MgInvitation `
      -InvitedUserEmailAddress $_.Email `
      -InvitedUserDisplayName $_.Nome `
      -InviteRedirectUrl "https://myapps.microsoft.com" `
      -SendInvitationMessage:$true
}

Verificar guests com convite pendente:

Get-MgUser -Filter "userType eq 'Guest'" -All `
  -Property "displayName,mail,externalUserState,externalUserStateChangeDateTime" |
  Where-Object { $_.externalUserState -eq "PendingAcceptance" }

Reenviar convite para um guest pendente:

# Reenvio requer excluir e recriar o objeto, ou usar a API de convite novamente
New-MgInvitation `
  -InvitedUserEmailAddress "joao@empresa-parceira.com" `
  -InviteRedirectUrl "https://myapps.microsoft.com" `
  -SendInvitationMessage:$true `
  -ResetRedemption:$true

O parâmetro ResetRedemption é importante: ele reseta o estado do convite para um guest que já foi convidado antes, permitindo que o link seja reenviado sem precisar excluir e recriar o objeto.

6.3 Azure CLI

# Convidar um guest
az ad invitation create \
  --invited-user-email-address joao@empresa-parceira.com \
  --invite-redirect-url "https://myapps.microsoft.com" \
  --send-invitation-message true

# Listar todos os guests
az ad user list --filter "userType eq 'Guest'" \
  --query "[].{Nome:displayName, Email:mail, Estado:externalUserState}"

Limitação: a CLI tem cobertura menor para gerenciamento de guests comparada ao PowerShell com Graph SDK. O reset de redemption e configurações avançadas de convite são mais acessíveis via PowerShell ou Graph API diretamente.

6.4 Microsoft Graph API

Enviar convite:

POST https://graph.microsoft.com/v1.0/invitations
Content-Type: application/json

{
  "invitedUserEmailAddress": "joao@empresa-parceira.com",
  "invitedUserDisplayName": "João Silva (Empresa Parceira)",
  "inviteRedirectUrl": "https://myapps.microsoft.com",
  "sendInvitationMessage": true,
  "invitedUserMessageInfo": {
    "customizedMessageBody": "Você foi convidado para colaborar no Projeto Alpha. Clique no link para aceitar."
  }
}

Listar todos os guests com convite pendente:

GET https://graph.microsoft.com/v1.0/users?$filter=userType eq 'Guest' and externalUserState eq 'PendingAcceptance'&$select=displayName,mail,externalUserState

---

7. Controle e Segurança

Políticas de Acesso Condicional para Guests

Políticas de Acesso Condicional podem ser aplicadas especificamente a usuários externos. Isso permite criar regras diferentes para guests sem afetar usuários internos.

Exemplo de política útil para guests:

• Condição: userType is Guest
• Controle: Require MFA + Require compliant device (ou apenas MFA se dispositivo não for gerenciado)
• Resultado: todo acesso de external users exige MFA no seu tenant

Ponto crítico: ao criar políticas de Acesso Condicional para guests, tome cuidado para não bloquear inadvertidamente todos os guests antes de configurar os métodos de MFA aceitos. Uma política que exige MFA sem configurar os trust settings pode bloquear guests que não conseguem registrar métodos de MFA no seu tenant.

Cross-Tenant Access Settings

O Entra ID tem um recurso chamado Cross-Tenant Access Settings que permite configurar relações de confiança específicas por tenant de origem. É diferente das configurações globais de colaboração externa.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Com as Organizational Settings, você pode configurar para um tenant parceiro específico:

• Confiar no MFA que eles já executaram (evitando double-MFA)
• Confiar em dispositivos conformes registrados no tenant deles
• Bloquear completamente colaboração de entrada ou saída com aquele tenant

Entra ID Identity Governance: Access Reviews para Guests

Uma das maiores preocupações com guests é o acúmulo ao longo do tempo: consultores que terminaram projetos, parceiros de contratos encerrados, ex-fornecedores. O Access Reviews (com licença Entra ID P2) permite criar revisões periódicas específicas para guests:

• Frequência configurável (mensal, trimestral, anual)
• Revisor: o owner do grupo, o patrocinador do guest, ou o próprio guest
• Ação automática se sem resposta: remover acesso ou manter (configurável)

---

8. Tomada de Decisão

Como configurar as permissões de guests?

Situação	Configuração recomendada	Motivo
Colaboração com poucos parceiros conhecidos	Allowlist com domínios específicos	Minimiza superfície de ataque, garante controle
Ambiente aberto para muitos parceiros	Denylist com domínios proibidos	Flexibilidade mantendo bloqueio a concorrentes ou domínios suspeitos
Alta segurança, sem colaboração externa	Desabilitar convites por completo	Zero risco de acesso externo inadvertido
Parceiro com relação profunda e longa duração	Cross-tenant trust settings configurado	Experiência mais fluida (sem double-MFA), mais produtividade

Como controlar o MFA para guests?

Situação	Abordagem	Consideração
Guests de outro tenant Azure com MFA ativo	Configurar trust para aceitar MFA do home tenant	Evita double-MFA, boa experiência
Guests com conta pessoal (Gmail, Hotmail)	Exigir MFA via Acesso Condicional no seu tenant	Home tenant não tem controles corporativos
Guests via Email OTP	MFA implícito no próprio OTP	O código enviado por e-mail já funciona como fator adicional
Ambiente de alta segurança	Exigir MFA sempre, sem trust settings	Máxima segurança, experiência mais atritosa

Como encerrar acesso de um guest?

Situação	Ação	Impacto
Projeto encerrado, acesso não é mais necessário	Excluir o objeto do guest	Remove acesso imediatamente, objeto vai para lixeira por 30 dias
Projeto pausado, acesso temporariamente desnecessário	Desabilitar a conta	Bloqueia login, preserva configurações e associações
Múltiplos guests de um projeto encerrado	Script PowerShell para desabilitar/excluir em lote	Eficiente para limpeza em massa

---

9. Boas Práticas

Defina um patrocinador (sponsor) para cada guest: o patrocinador é o usuário interno responsável por aquela relação externa. Ele é notificado em Access Reviews e é o ponto de contato para qualquer questão sobre o acesso. O Entra ID tem um campo sponsors no objeto do guest para registrar isso formalmente.

Use grupos para gerenciar acesso de guests, não atribuições diretas: adicionar um guest a um grupo de acesso é muito mais escalável do que atribuir papéis RBAC diretamente. Quando o acesso precisar ser revogado, basta remover o guest do grupo.

Implemente Access Reviews periódicos para grupos com guests: especialmente para grupos que controlam acesso a recursos sensíveis. Trimestralmente é uma frequência razoável para a maioria dos ambientes.

Nomeie guests de forma identificável: use o formato Nome Sobrenome (Empresa) no Display Name, como "João Silva (Consultoria XYZ)". Em um diretório com centenas de usuários, identificar quem é externo e de qual empresa facilita muito a gestão.

Registre o propósito e a data de criação: use campos como Department ou extensionAttribute1 no objeto do guest para registrar o projeto ou contexto do acesso e quando foi criado. Isso facilita revisões futuras.

Configure redirect URL para myapps.microsoft.com: ao convidar, use https://myapps.microsoft.com como URL de redirecionamento. Isso dá ao guest uma visão clara de tudo que pode acessar no seu tenant, melhorando a experiência e reduzindo chamados de suporte.

---

10. Erros Comuns

Convidar guests sem definir o escopo de acesso previamente

O convite é enviado, o guest resgata, e então ninguém sabe ao certo o que ele deve poder acessar. Resultado: o guest fica no diretório sem acesso real a nada, ou recebe acesso excessivo "para facilitar". Sempre defina previamente a quais grupos o guest será adicionado antes de enviar o convite.

Não remover guests após o término da necessidade

Guests se acumulam ao longo dos anos. Um tenant sem limpeza periódica pode ter centenas de guests de projetos encerrados anos atrás, alguns com acesso a recursos que ainda existem. Implemente Access Reviews ou um processo manual de revisão semestral.

Confundir o domínio de autenticação com o domínio do e-mail

Um usuário joao@empresa-parceira.com pode ter sua autenticação gerenciada por um tenant Azure diferente de empresa-parceira.com se a empresa parceira usa um tenant com domínio customizado. Na maioria dos casos isso funciona transparentemente, mas em diagnósticos de problemas de login, é importante entender que o endereço de e-mail e o tenant de autenticação nem sempre correspondem exatamente.

Aplicar políticas de Acesso Condicional sem exceção para contas de emergência

Se você cria uma política que bloqueia todos os guests sem MFA e não testa antes de ativar, você pode inadvertidamente bloquear todos os guests de uma vez. Sempre teste políticas de Acesso Condicional em modo "Report-only" antes de ativar, e tenha uma conta de acesso de emergência excluída das políticas.

Esquecer que o guest está sujeito a políticas de dois tenants

Quando um guest reclama que não consegue acessar, o problema pode estar no home tenant dele (política de acesso condicional, MFA não configurado, conta bloqueada) ou no resource tenant (política mal configurada, acesso não atribuído). O diagnóstico precisa considerar os dois lados, mas o administrador do resource tenant só tem visibilidade do seu próprio lado.

Assumir que excluir um guest do diretório encerra todos os acessos imediatamente

Quando um guest é excluído, ele vai para a lixeira por 30 dias. Durante esse período, o objeto ainda existe e tecnicamente poderia ser restaurado com todos os acessos. Para encerramento imediato e definitivo, exclua E confirme que o objeto foi removido da lixeira, ou simplesmente desabilite a conta se quiser preservar o histórico.

---

11. Operação e Manutenção

Auditar Guests Acumulados

Listar todos os guests e quando foram criados:

Get-MgUser -Filter "userType eq 'Guest'" -All `
  -Property "displayName,mail,createdDateTime,externalUserState,signInActivity" |
  Sort-Object createdDateTime |
  Select-Object displayName, mail, createdDateTime, externalUserState

A propriedade signInActivity (requer licença P1 ou P2) mostra o último login. Guests que nunca fizeram login ou não fazem login há mais de 90 dias são candidatos para revisão e possível remoção.

Listar guests sem login nos últimos 90 dias:

$cutoff = (Get-Date).AddDays(-90)
Get-MgUser -Filter "userType eq 'Guest'" -All `
  -Property "displayName,mail,signInActivity" |
  Where-Object { 
    $_.SignInActivity.LastSignInDateTime -lt $cutoff -or 
    $null -eq $_.SignInActivity.LastSignInDateTime 
  }

Monitoramento de Convites Pendentes

Convites que ficam pendentes por muito tempo podem indicar que o e-mail não chegou ou que o usuário não tem mais interesse/necessidade:

$diasLimite = 14
$cutoff = (Get-Date).AddDays(-$diasLimite)

Get-MgUser -Filter "userType eq 'Guest' and externalUserState eq 'PendingAcceptance'" -All `
  -Property "displayName,mail,externalUserStateChangeDateTime" |
  Where-Object { $_.ExternalUserStateChangeDateTime -lt $cutoff }

Isso lista guests cujo convite foi enviado há mais de 14 dias e ainda não foi resgatado.

Limites Importantes

Item	Limite
Guests por tenant	Até 50.000 por padrão (ajustável via suporte)
Ratio guests/membros	Originalmente 5:1; esse limite foi removido pela Microsoft. Não há mais ratio obrigatório
Expiração de link de convite	30 dias para resgatar o convite inicial
Objetos na lixeira após exclusão	30 dias para restauração

---

12. Integração e Automação

Entitlement Management: Pacotes de Acesso para Externos

O Entra ID Entitlement Management (com licença Governance ou P2) permite criar Access Packages (pacotes de acesso) que externos podem solicitar por conta própria, sem precisar de um administrador para cada convite individual.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Isso é ideal para cenários onde externos precisam solicitar acesso a recursos de forma self-service, como em portais de parceiros ou programas de colaboração aberta.

Automação via Graph API com Aprovação

Para cenários de convite automatizado com validação (por exemplo, integrado ao sistema de gestão de contratos da empresa):

1. Sistema de contratos detecta novo fornecedor aprovado
2. Chama Graph API para criar convite
3. Adiciona o guest ao grupo de acesso do fornecedor
4. Agenda revisão de acesso para a data de término do contrato

Esse fluxo pode ser implementado com Azure Logic Apps, Azure Functions ou Power Automate, conectando o ciclo de vida do contrato com o ciclo de vida do acesso no Entra ID.

Lifecycle Workflows para Guests

O Lifecycle Workflows (com licença Governance) permite criar fluxos automatizados disparados por eventos do ciclo de vida. Para guests, os eventos relevantes incluem:

• Guest criado (trigger onboarding)
• Guest inativo por X dias (trigger revisão ou remoção automática)
• Data de expiração definida no objeto atingida (trigger offboarding)

---

13. Resumo Final

Pontos essenciais:

• Um guest user tem userType: Guest e sua autenticação é gerenciada pelo home tenant (provedor de identidade original), não pelo resource tenant.
• O resource tenant controla o que o guest pode acessar; o home tenant controla como o guest prova sua identidade.
• O processo de convite cria o objeto no diretório apenas após o resgate do link pelo guest. Antes do resgate, o estado é PendingAcceptance e o acesso não funciona.
• O UPN de um guest no tenant convidante tem o formato email_dominio#EXT#@tenant.onmicrosoft.com.
• Guests têm permissões de diretório muito mais restritas que membros por padrão. Eles não podem navegar o diretório nem ver membros de grupos dos quais não fazem parte.

Diferenças críticas:

• Allowlist vs. Denylist: são mutuamente exclusivas. Allowlist define os únicos domínios aceitos; Denylist define os domínios bloqueados, aceitando todos os demais.
• Desabilitar vs. Excluir guest: desabilitar bloqueia login, preserva o objeto e associações. Excluir remove o acesso e coloca o objeto na lixeira por 30 dias.
• Trust settings por tenant específico (Cross-Tenant Access Settings) vs. configurações globais (External Collaboration Settings): as configurações por tenant específico têm precedência sobre as globais.
• MFA pelo home tenant vs. MFA pelo resource tenant: se trust settings estão configurados para aceitar claims de MFA do home tenant, o guest não precisa fazer MFA novamente. Sem trust settings, o resource tenant pode exigir MFA adicional.

O que precisa ser lembrado:

• Implemente Access Reviews periódicos para limpar guests inativos ou de projetos encerrados.
• Defina sempre um patrocinador interno para cada guest, tornando clara a responsabilidade pelo acesso.
• Use grupos para conceder acesso a guests, nunca atribuições RBAC diretas quando possível.
• A propriedade signInActivity (requer P1/P2) é o indicador mais confiável para identificar guests inativos.
• O parâmetro ResetRedemption na API de convite permite reenviar o convite sem excluir e recriar o objeto do guest.
• Políticas de Acesso Condicional no resource tenant se aplicam a guests e podem exigir MFA mesmo que o home tenant não exija.