Considerações comuns para o gerenciamento de usuários multilocatários

Este artigo é o terceiro de uma série de artigos que fornecem orientação para configurar e fornecer gerenciamento do ciclo de vida do usuário em ambientes multilocatários do Microsoft Entra. Os seguintes artigos da série fornecem mais informações conforme descrito.

• A introdução ao gerenciamento de usuários multilocatários é a primeira da série de artigos que fornecem orientação para configurar e fornecer gerenciamento do ciclo de vida do usuário em ambientes multilocatários do Microsoft Entra.
• Os cenários de gerenciamento de usuários multilocatários descrevem três cenários para os quais você pode usar recursos de gerenciamento de usuários multilocatário: iniciado pelo usuário final, com script e automatizado.
• Soluções comuns para gerenciamento de usuários multilocatários Quando a locação única não funciona para o seu cenário, este artigo fornece orientação para esses desafios: gerenciamento automático do ciclo de vida do usuário e alocação de recursos entre locatários, compartilhamento de aplicativos locais entre locatários.

As orientações ajudam a alcançar um estado consistente de gerenciamento do ciclo de vida do usuário. O gerenciamento do ciclo de vida inclui provisionamento, gerenciamento e desprovisionamento de usuários entre locatários usando as ferramentas disponíveis do Azure que incluem colaboração B2B (B2B ) do Microsoft Entra e sincronização entre locatários.

Os requisitos de sincronização são exclusivos para as necessidades específicas da sua organização. Ao projetar uma solução para atender aos requisitos da sua organização, as considerações a seguir neste artigo ajudam a identificar suas melhores opções.

• Sincronização entre locatários
• Objeto de diretório
• Acesso condicional do Microsoft Entra
• Controlo de acesso adicional
• Escritório 365

Sincronização entre locatários

A sincronização entre locatários pode abordar os desafios de colaboração e acesso de organizações multilocatário. A tabela a seguir mostra casos de uso comuns de sincronização. Você pode usar a sincronização entre locatários e o desenvolvimento do cliente para satisfazer casos de uso quando as considerações são relevantes para mais de um padrão de colaboração.

Caso de uso	Sincronização entre locatários	Desenvolvimento à medida
Gerenciamento do ciclo de vida do usuário
Partilha de ficheiros e acesso a aplicações
Suporte a sincronização de/para nuvens soberanas
Controlar a sincronização a partir do inquilino do recurso
Sincronizar objetos de grupo
Links do Sync Manager
Nível de atributo Fonte de Autoridade
Write-back do Microsoft Entra para o Ative Directory do Microsoft Windows Server

Considerações sobre o objeto de diretório

Convidando um usuário externo com UPN versus Endereço SMTP

O Microsoft Entra B2B espera que o UserPrincipalName (UPN) de um usuário seja o principal endereço SMTP (Email) para enviar convites. Quando o UPN do usuário é o mesmo que seu endereço SMTP principal, B2B funciona conforme o esperado. No entanto, se o UPN for diferente do endereço SMTP principal do usuário externo, ele poderá falhar na resolução quando um usuário aceitar um convite. Esse problema pode ser um desafio se você não souber o UPN real do usuário. Você precisa descobrir e usar o UPN ao enviar convites para B2B.

A seção Microsoft Exchange Online deste artigo explica como alterar o SMTP primário padrão em usuários externos. Essa técnica é útil se você quiser que todos os e-mails e notificações de um externo fluam para o endereço SMTP primário real, em oposição ao UPN. Pode ser um requisito se o UPN não puder ser encaminhado para o fluxo de mensagens.

Convertendo UserType de um usuário externo

Quando você usa o console para criar manualmente um convite para uma conta de usuário externo, ele cria o objeto de usuário com um tipo de usuário convidado. O uso de outras técnicas para criar convites permite que você defina o tipo de usuário para algo diferente de uma conta de convidado externo. Por exemplo, ao usar a API, você pode configurar se a conta é uma conta de membro externo ou uma conta de convidado externo.

• Alguns dos limites da funcionalidade do convidado podem ser removidos.
• Você pode converter contas de convidado para o tipo de usuário membro.

Se você converter de um Usuário Convidado externo para uma conta de usuário membro externo, pode haver problemas com a forma como o Exchange Online lida com contas B2B. Não é possível habilitar contas para email que você convidou como usuários membros externos. Para habilitar uma conta de membro externo para email, use a melhor abordagem a seguir.

• Convide os usuários entre organizações como contas externas de Usuário Convidado.
• Mostrar as contas na GAL.
• Defina o UserType como Membro.

Quando você usa essa abordagem, as contas aparecem como objetos MailUser no Exchange Online e no Office 365. Além disso, observe que há um desafio de tempo. Verifique se o usuário está visível na GAL verificando se a propriedade ShowInAddressList do usuário do Microsoft Entra está alinhada com a propriedade HiddenFromAddressListsEnabled do PowerShell do Exchange Online (que são inversas umas das outras). A seção Microsoft Exchange Online deste artigo fornece mais informações sobre como alterar a visibilidade.

É possível converter um usuário membro em um usuário convidado, o que é útil para usuários internos que você deseja restringir a permissões de nível de convidado. Os usuários convidados internos são usuários que não são funcionários da sua organização, mas para os quais você gerencia seus usuários e credenciais. Ele pode permitir que você evite o licenciamento do Usuário Convidado interno.

Problemas com o uso de objetos de contato de email em vez de usuários ou membros externos

Você pode representar usuários de outro locatário usando uma sincronização GAL tradicional. Se você executar uma sincronização GAL em vez de usar a colaboração B2B do Microsoft Entra, ele criará um objeto de contato de email.

• O objeto de contato de email e um membro externo habilitado para email ou Usuário convidado não podem coexistir no mesmo locatário com o mesmo endereço de email ao mesmo tempo.
• Se existir um objeto de contato de email para o mesmo endereço de email que o usuário externo convidado, ele criará o usuário externo, mas não será habilitado para email.
• Se o usuário externo habilitado para email existir com o mesmo email, uma tentativa de criar um objeto de contato de email lançará uma exceção no momento da criação.

Importante

O uso de contatos de email requer os Serviços do Ative Directory (AD DS) ou o PowerShell do Exchange Online. O Microsoft Graph não fornece uma chamada de API para gerenciar contatos.

A tabela a seguir exibe os resultados de objetos de contato de email e estados de usuário externo.

Estado existente	Cenário de provisionamento	Resultado efetivo
Nenhum	Convide Membro B2B	Usuário membro não habilitado para email. Ver nota importante.
Nenhum	Convide Convidado B2B	Usuário externo habilitado para email.
O objeto de contato de email existe	Convide Membro B2B	Erro. Conflito de endereços proxy.
O objeto de contato de email existe	Convide Convidado B2B	Usuário externo habilitado para contato de email e não-email. Ver nota importante.
Usuário convidado externo habilitado para email	Criar objeto de contato de email	Erro
Existe um usuário de membro externo habilitado para email	Criar contato de e-mail	Erro

A Microsoft recomenda o uso da colaboração B2B do Microsoft Entra (em vez da sincronização GAL tradicional) para criar:

• Usuários externos que você habilita para mostrar na GAL.
• Usuários de membros externos que aparecem na GAL por padrão, mas não são habilitados para email.

Você pode optar por usar o objeto de contato de email para mostrar os usuários na GAL. Essa abordagem integra uma GAL sem fornecer outras permissões porque os contatos de email não são entidades de segurança.

Siga esta abordagem recomendada para atingir o objetivo:

• Convide usuários convidados.
• Remostre-os da GAL.
• Desative-os bloqueando-os de entrar.

Um objeto de contato de email não pode ser convertido em um objeto de usuário. Portanto, as propriedades associadas a um objeto de contato de email não podem ser transferidas (como associações de grupo e outros recursos de acesso). Usar um objeto de contato de email para representar um usuário vem com os seguintes desafios.

• Grupos do Office 365. Os Grupos do Office 365 suportam políticas que regem os tipos de utilizadores autorizados a ser membros de grupos e a interagir com conteúdo associado a grupos. Por exemplo, um grupo pode não permitir que usuários convidados participem. Essas políticas não podem controlar objetos de contato de email.
• Gerenciamento de grupo de autoatendimento (SSGM) do Microsoft Entra. Os objetos de contato de email não são qualificados para serem membros em grupos usando o recurso SSGM. Talvez você precise de mais ferramentas para gerenciar grupos com destinatários representados como contatos em vez de objetos de usuário.
• Microsoft Entra ID Governance, Access Reviews. Você pode usar o recurso de revisões de acesso para revisar e atestar a associação ao grupo do Office 365. As revisões de acesso são baseadas em objetos de usuário. Os membros representados por objetos de contato de email estão fora do escopo para revisões de acesso.
• Governança do Microsoft Entra ID, Gerenciamento de Direitos (EM). Quando você usa o EM para habilitar solicitações de acesso de autoatendimento para usuários externos no portal EM da empresa, ele cria um objeto de usuário no momento da solicitação. Ele não suporta objetos de contato de email.

Considerações sobre o Acesso Condicional do Microsoft Entra

O estado do usuário, dispositivo ou rede no locatário doméstico do usuário não transmite ao locatário do recurso. Portanto, um usuário externo pode não satisfazer as políticas de acesso condicional que usam os seguintes controles.

Quando permitido, você pode substituir esse comportamento com CTAS (Configurações de Acesso entre Locatários) que honram a autenticação multifator e a conformidade do dispositivo do locatário doméstico.

• Requer autenticação multifator. Sem CTAS configurado, um usuário externo deve registrar/responder à autenticação multifator no locatário do recurso (mesmo que a autenticação multifator tenha sido satisfeita no locatário doméstico). Esse cenário resulta em vários desafios de autenticação multifator. Se eles precisarem redefinir suas provas de autenticação multifator, talvez não estejam cientes dos registros de prova de autenticação multifator entre locatários. A falta de reconhecimento pode exigir que o usuário entre em contato com um administrador no locatário inicial, locatário de recurso ou ambos.
• Exigir que o dispositivo seja marcado como compatível. Sem o CTAS configurado, a identidade do dispositivo não é registrada no locatário do recurso, portanto, o usuário externo não pode acessar recursos que exigem esse controle.
• Requer o dispositivo híbrido associado ao Microsoft Entra. Sem o CTAS configurado, a identidade do dispositivo não é registrada no locatário do recurso (ou no Ative Directory local conectado ao locatário do recurso). Portanto, o usuário externo não pode acessar recursos que exigem esse controle.
• Exigir aplicativo cliente aprovado ou Exigir política de proteção de aplicativo. Sem o CTAS configurado, os utilizadores externos não podem aplicar a política de Gestão de Aplicações Móveis (MAM) do inquilino de recursos porque também requer o registo do dispositivo. A política de Acesso Condicional do locatário de recurso, usando esse controle, não permite que a proteção MAM do locatário doméstico satisfaça a política. Exclua usuários externos de todas as políticas de Acesso Condicional baseadas em MAM.

Além disso, embora você possa usar as seguintes condições de Acesso Condicional, esteja ciente das possíveis ramificações.

• Risco de início de sessão e risco de utilizador. O comportamento do usuário em seu locatário doméstico determina em parte o risco de entrada e o risco do usuário. O inquilino armazena os dados e a pontuação de risco. Se as políticas de locatário de recurso bloquearem um usuário externo, um administrador de locatário de recurso pode não conseguir habilitar o acesso. Microsoft Entra ID Protection e usuários B2B explica como o Microsoft Entra ID Protection deteta credenciais comprometidas para usuários do Microsoft Entra.
• Locais. As definições de local nomeado no locatário de recurso determinam o escopo da política. O escopo da política não avalia locais confiáveis gerenciados no locatário residencial. Se sua organização quiser compartilhar locais confiáveis entre locatários, defina os locais em cada locatário onde você define os recursos e as políticas de Acesso Condicional.

Protegendo seu ambiente multilocatário

A proteção de um ambiente multilocatário começa garantindo que cada locatário siga as práticas recomendadas de segurança. Reveja a lista de verificação de segurança e as práticas recomendadas para obter orientações sobre como proteger o seu inquilino. Certifique-se de que essas práticas recomendadas sejam seguidas e revise-as com todos os locatários com os quais você colabora de perto.

Proteja as contas de administrador e garanta o mínimo de privilégios

• Encontre e resolva lacunas na cobertura de autenticação forte para seus administradores
• Melhore a segurança com o princípio do menor privilégio para usuários e aplicativos. Analise as funções de menor privilégio por tarefa no Microsoft Entra ID.
• Minimize o acesso persistente do administrador habilitando o Privileged Identity Management.

Monitore seu ambiente multilocatário

• Monitore alterações nas políticas de acesso entre locatários usando a interface do usuário, a API ou a integração do Azure Monitor de logs de auditoria (para alertas proativos). Os eventos de auditoria usam as categorias "CrossTenantAccessSettings" e "CrossTenantIdentitySyncSettings". Ao monitorar eventos de auditoria nessas categorias, você pode identificar quaisquer alterações na política de acesso entre locatários em seu locatário e tomar medidas. Ao criar alertas no Azure Monitor, você pode criar uma consulta como a seguinte para identificar quaisquer alterações na política de acesso entre locatários.

AuditLogs
| where Category contains "CrossTenant"

• Monitore se há novos parceiros adicionados às configurações de acesso entre locatários.

AuditLogs
| where OperationName == "Add a partner to cross-tenant access setting"
| where parse_json(tostring(TargetResources[0].modifiedProperties))[0].displayName == "tenantId"
| extend initiating_user=parse_json(tostring(InitiatedBy.user)).userPrincipalName
| extend source_ip=parse_json(tostring(InitiatedBy.user)).ipAddress
| extend target_tenant=parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue
| project TimeGenerated, OperationName,initiating_user,source_ip, AADTenantId,target_tenant
| project-rename source_tenant= AADTenantId

• Monitore alterações nas políticas de acesso entre locatários permitindo/não permitindo sincronização.

AuditLogs
| where OperationName == "Update a partner cross-tenant identity sync setting"
| extend a = tostring(TargetResources)
| where a contains "true"
| where parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue contains "true"

• Monitore o acesso ao aplicativo em seu locatário usando o painel de atividades de acesso entre locatários. O monitoramento permite que você veja quem está acessando recursos em seu locatário e de onde esses usuários estão vindo.

Grupos dinâmicos de membros

Se sua organização estiver usando a condição de grupo de associação dinâmica de todos os usuários em sua política de Acesso Condicional existente, essa política afetará os usuários externos porque eles estão no escopo de todos os usuários.

Negar por padrão

• Exigir atribuição de usuário para aplicativos. Se um aplicativo tiver a propriedade User assignment required? definida como Não, os usuários externos poderão acessar o aplicativo. Os administradores de aplicativos devem entender os impactos do controle de acesso, especialmente se o aplicativo contiver informações confidenciais. Restringir seu aplicativo Microsoft Entra a um conjunto de usuários em um locatário do Microsoft Entra explica como os aplicativos registrados em um locatário estão disponíveis para todos os usuários do locatário que se autenticarem com êxito. Essa configuração está ativada por padrão.

Defesa em profundidade

Acesso condicional.

• Defina políticas de controle de acesso para controlar o acesso aos recursos.
• Projete políticas de Acesso Condicional com usuários externos em mente.
• Crie políticas especificamente para usuários externos.
• Crie políticas de Acesso Condicional dedicadas para contas externas. Se sua organização estiver usando a condição de grupo de associação dinâmica de todos os usuários em sua política de Acesso Condicional existente, essa política afetará os usuários externos porque eles estão no escopo de todos os usuários.

Unidades de Gestão Restritas

Ao usar grupos de segurança para controlar quem está no escopo da sincronização entre locatários, limite quem pode fazer alterações no grupo de segurança. Minimize o número de proprietários dos grupos de segurança atribuídos ao trabalho de sincronização entre locatários e inclua os grupos em uma unidade de gerenciamento restrita. Esse cenário limita o número de pessoas que podem adicionar ou remover membros do grupo e provisionar contas entre locatários.

Outras considerações sobre controle de acesso

Termos e condições

Os termos de uso do Microsoft Entra fornecem um método simples que as organizações podem usar para apresentar informações aos usuários finais. Você pode usar os termos de uso para exigir que usuários externos aprovem os termos de uso antes de acessar seus recursos.

Considerações sobre licenciamento para usuários convidados com recursos do Microsoft Entra ID P1 ou P2

O preço do Microsoft Entra External ID é baseado em usuários ativos mensais (MAU). O número de usuários ativos é a contagem de usuários exclusivos com atividade de autenticação dentro de um mês de calendário. O modelo de faturamento do Microsoft Entra External ID descreve como o preço é baseado no MAU.

Considerações sobre o Office 365

As informações a seguir abordam o Office 365 no contexto dos cenários deste documento. Informações detalhadas estão disponíveis em Microsoft 365 intertenant collaboration 365 intertenant collaboration. Este artigo descreve opções que incluem o uso de um local central para arquivos e conversas, o compartilhamento de calendários, o uso de mensagens instantâneas, chamadas de áudio/vídeo para comunicação e a proteção do acesso a recursos e aplicativos.

Microsoft Exchange Online

O Exchange Online limita determinadas funcionalidades para usuários externos. Você pode diminuir os limites criando usuários membros externos em vez de usuários convidados externos. O suporte para utilizadores externos tem as seguintes limitações.

• Você pode atribuir uma licença do Exchange Online a um usuário externo. No entanto, você não pode emitir para eles um token para o Exchange Online. O resultado é que eles não podem acessar o recurso.
  • Os usuários externos não podem usar caixas de correio compartilhadas ou delegadas do Exchange Online no locatário do recurso.
  • Você pode atribuir um usuário externo a uma caixa de correio compartilhada, mas ele não pode acessá-la.
• Você precisa exibir usuários externos para incluí-los na GAL. Por padrão, eles estão ocultos.
  • Usuários externos ocultos são criados no momento do convite. A criação é independente de o usuário ter resgatado o convite. Portanto, se todos os usuários externos estiverem ocultos, a lista incluirá objetos de usuário de usuários externos que não resgataram um convite. Com base no seu cenário, você pode ou não querer os objetos listados.
  • Os usuários externos podem não estar ocultos usando o PowerShell do Exchange Online. Você pode executar o cmdlet Set-MailUser PowerShell para definir a propriedade HiddenFromAddressListsEnabled com um valor de $false.

Por exemplo:

Set-MailUser [ExternalUserUPN] -HiddenFromAddressListsEnabled:\$false\

Onde ExternalUserUPN é o UserPrincipalName calculado .

Por exemplo:

Set-MailUser externaluser1_contoso.com#EXT#@fabricam.onmicrosoft.com\ -HiddenFromAddressListsEnabled:\$false

Os usuários externos podem estar ocultos no centro de administração do Microsoft 365.

• Você só pode definir atualizações para propriedades específicas do Exchange (como PrimarySmtpAddress, ExternalEmailAddress, EmailAddresses e MailTip) usando o PowerShell do Exchange Online. O Centro de Administração do Exchange Online não permite que você modifique os atributos usando a interface gráfica do usuário (GUI).

Como mostrado no exemplo, você pode usar o cmdlet Set-MailUser PowerShell para propriedades específicas de email. Há propriedades de usuário que você pode modificar com o cmdlet Set-User PowerShell. Você pode modificar a maioria das propriedades com as APIs do Microsoft Graph.

Um dos recursos mais úteis de Set-MailUser é a capacidade de manipular a propriedade EmailAddresses . Esse atributo de valores múltiplos pode conter vários endereços proxy para o usuário externo (como SMTP, X500, SIP (Session Initiation Protocol)). Por padrão, um usuário externo tem o endereço SMTP primário carimbado correlacionando-se ao UserPrincipalName (UPN). Se desejar alterar o SMTP principal ou adicionar endereços SMTP, você pode definir essa propriedade. Não é possível usar o Centro de Administração do Exchange; você deve usar o PowerShell do Exchange Online. Adicionar ou remover endereços de email de uma caixa de correio no Exchange Online mostra diferentes maneiras de modificar uma propriedade de vários valores, como EmailAddresses.

Microsoft SharePoint no Microsoft 365

O SharePoint no Microsoft 365 tem suas próprias permissões específicas de serviço, dependendo se o usuário (interno ou externo) é do tipo membro ou convidado no locatário do Microsoft Entra. O compartilhamento externo do Microsoft 365 e a colaboração B2B do Microsoft Entra descrevem como você pode habilitar a integração com o SharePoint e o OneDrive para compartilhar arquivos, pastas, itens de lista, bibliotecas de documentos e sites com pessoas fora da sua organização. O Microsoft 365 faz isso ao usar o Azure B2B para autenticação e gerenciamento.

Depois de habilitar o compartilhamento externo no SharePoint no Microsoft 365, a capacidade de pesquisar usuários convidados no seletor de pessoas do SharePoint no Microsoft 365 está DESATIVADA por padrão. Essa configuração proíbe que os usuários convidados sejam detetáveis quando estiverem ocultos da GAL do Exchange Online. Você pode permitir que os usuários convidados se tornem visíveis de duas maneiras (não mutuamente exclusivas):

• Você pode habilitar a capacidade de pesquisar usuários convidados das seguintes maneiras:
  • Modifique a configuração ShowPeoplePickerSuggestionsForGuestUsers no nível do locatário e do conjunto de sites.
  • Defina o recurso usando os cmdlets Set-SPOTenant e Set-SPOSite SharePoint no Microsoft 365 PowerShell .
• Os usuários convidados que são visíveis na GAL do Exchange Online também são visíveis no SharePoint no seletor de pessoas do Microsoft 365. As contas são visíveis independentemente da configuração para ShowPeoplePickerSuggestionsForGuestUsers.

Microsoft Teams

O Microsoft Teams tem recursos para limitar o acesso e com base no tipo de usuário. Alterações no tipo de usuário podem afetar o acesso ao conteúdo e os recursos disponíveis. O Microsoft Teams exige que os usuários alterem seu contexto usando o mecanismo de comutação de locatário do cliente do Teams ao trabalhar no Teams fora do locatário inicial.

O mecanismo de comutação de locatário do Microsoft Teams pode exigir que os usuários alternem manualmente o contexto do cliente do Teams ao trabalhar no Teams fora do locatário inicial.

Você pode habilitar usuários do Teams de outro domínio externo inteiro para localizar, ligar, conversar e configurar reuniões com seus usuários com a Federação do Teams. Gerenciar reuniões externas e conversar com pessoas e organizações usando identidades da Microsoft descreve como você pode permitir que os usuários em sua organização conversem e se encontrem com pessoas fora da organização que estão usando a Microsoft como um provedor de identidade.

Considerações sobre licenciamento para usuários convidados no Teams

Quando você usa o Azure B2B com cargas de trabalho do Office 365, as principais considerações incluem instâncias nas quais os usuários convidados (internos ou externos) não têm a mesma experiência que os usuários membros.

• Grupos da Microsoft. Adicionar convidados aos Grupos do Office 365 descreve como o acesso de convidado nos Grupos do Microsoft 365 permite que você e sua equipe colaborem com pessoas de fora da sua organização, concedendo-lhes acesso a conversas de grupo, arquivos, convites de calendário e bloco de anotações de grupo.
• Microsoft Teams. Os recursos de proprietário, membro e convidado da equipe no Teams descrevem a experiência da conta de convidado no Microsoft Teams. Você pode habilitar uma experiência de fidelidade total no Teams usando usuários membros externos.
  • Para vários inquilinos na nossa nuvem Comercial, os utilizadores licenciados no seu inquilino doméstico podem aceder a recursos noutro inquilino dentro da mesma entidade legal. Você pode conceder acesso usando a configuração de membros externos sem taxas de licenciamento extras. Esta definição aplica-se ao SharePoint e ao OneDrive para Equipas e Grupos.
  • Para vários locatários em outras nuvens da Microsoft e para vários locatários em nuvens diferentes, as verificações de licença de membro B2B ainda não estão disponíveis. O uso de Membro B2B com Equipes requer uma licença adicional para cada Membro B2B. Esse requisito também pode afetar outras cargas de trabalho, como o Power BI.
  • O uso de membros B2B para locatários que não fazem parte da mesma entidade legal está sujeito a requisitos de licença adicionais.
• Recursos de governança de identidade. O Gerenciamento de Direitos e as revisões de acesso podem exigir outras licenças para usuários externos.
• Outros produtos. Produtos como o CRM (Customer Relationship Management, gerenciamento de relacionamento com o cliente) do Dynamics podem exigir licenciamento em cada locatário no qual um usuário está representado.

Próximos passos

• A introdução ao gerenciamento de usuários multilocatários é a primeira da série de artigos que fornecem orientação para configurar e fornecer gerenciamento do ciclo de vida do usuário em ambientes multilocatários do Microsoft Entra.
• Os cenários de gerenciamento de usuários multilocatários descrevem três cenários para os quais você pode usar recursos de gerenciamento de usuários multilocatário: iniciado pelo usuário final, com script e automatizado.
• Soluções comuns para gerenciamento de usuários multilocatários Quando a locação única não funciona para o seu cenário, este artigo fornece orientação para esses desafios: gerenciamento automático do ciclo de vida do usuário e alocação de recursos entre locatários, compartilhamento de aplicativos locais entre locatários.
• O Microsoft Collaboration Framework para a Base Industrial de Defesa dos EUA descreve arquiteturas de referência candidatas para identidade para acomodar organizações multilocatárias (MTO). Este cenário aplica-se especificamente aos MTOs que têm uma implementação na Nuvem Soberana dos EUA com o Microsoft 365 US Government (GCC High) e o Azure Government. Ele também aborda a colaboração externa em ambientes altamente regulamentados, incluindo organizações que estão hospedadas na Nuvem Soberana Comercial ou nos EUA.