Considerações comuns para o gerenciamento de usuários multilocatário
Este artigo é o terceiro de uma série de artigos que fornecem diretrizes para configurar e fornecer gerenciamento do ciclo de vida do usuário em ambientes multilocatários do Microsoft Entra. Os artigos a seguir da série fornecem mais informações conforme descrito.
- Introdução ao gerenciamento de usuários multilocatários é o primeiro de uma série de artigos que fornecem diretrizes 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ário descrevem três cenários para os quais você pode usar os recursos de gerenciamento de usuários multilocatários: iniciados pelo usuário final, com script e automatizados.
- Soluções comuns para gerenciamento de usuários multilocatários quando a locação única não funciona para o seu cenário, esse artigo fornece diretrizes para estes desafios: gerenciamento automático do ciclo de vida do usuário e alocação de recursos entre locatários, compartilhando aplicativos locais entre locatários.
As diretrizes ajudam a alcançar um estado consistente de gerenciamento do ciclo de vida do usuário. O gerenciamento do ciclo de vida inclui provisionar, gerenciar e desprovisionar usuários entre locatários usando as ferramentas disponíveis do Azure que incluem colaboração B2B do Microsoft Entra (B2B) e sincronização entre locatários.
Os requisitos de sincronização são exclusivos das necessidades específicas da sua organização. Ao criar uma solução para atender aos requisitos da sua organização, as considerações a seguir neste artigo ajudarão você a identificar suas melhores opções.
- Sincronização entre locatários
- Objeto do directoy
- Acesso Condicional ao Microsoft Entra
- Controle de acesso adicional
- Office 365
Sincronização entre locatários
A sincronização entre locatários pode resolver os desafios de colaboração e acesso de organizações multilocatárias. A tabela a seguir mostra casos comuns de uso de sincronização. Você pode usar a sincronização entre locatários e o desenvolvimento do cliente para atender aos casos de uso quando considerações forem relevantes para mais de um padrão de colaboração.
Caso de uso | Sincronização entre os locatários | Desenvolvimento personalizado |
---|---|---|
Gerenciamento do ciclo de vida do usuário | ||
Compartilhamento de arquivos e acesso ao aplicativo | ||
Suporte à sincronização de/para nuvens soberanas | ||
Controlar a sincronização do locatário de recursos | ||
Objetos do grupo de sincronização | ||
Links do gerenciador de sincronização | ||
Fonte de autoridade no nível de atributo | ||
Write-back do Microsoft Entra para o Microsoft Windows Server Active Directory |
Considerações sobre o objeto do directoy
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 endereço principal do Protocolo SMTP (Email) para enviar convites. Quando o UPN do usuário é o mesmo que o endereço SMTP principal, o B2B funciona conforme o esperado. No entanto, se o UPN for diferente do endereço SMTP principal do usuário externo, ele poderá não resolver 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 principal padrão dos usuários externos. Essa técnica será útil se você quiser que todos os emails e notificações de um usuário externo sejam enviados para o endereço SMTP principal real em vez do UPN. Pode ser um requisito se o UPN não puder rotear para o fluxo de emails.
Convertendo o 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 possibilita definir o tipo de usuário 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 as contas de convidado em 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 lidará com as contas B2B. Não é possível habilitar para email as contas que você convidou como usuários membros externos. Para habilitar para email uma conta de membro externo, use a melhor abordagem a seguir.
- Convide os usuários entre as organizações como contas de usuários convidados externos.
- Exibir as contas no GAL.
- Definir UserType como Membro.
Quando você usa essa abordagem, as contas aparecem como objetos MailUser no Exchange Online e no Office 365. Observe também que há um problema de tempo. Veja se o usuário está visível na GAL verificando se a propriedade ShowInAddressList do usuário do Microsoft Entra se alinha com a propriedade HiddenFromAddressListsEnabled do Exchange Online PowerShell (que são inversas uma da outra). A seção Microsoft Exchange Online desse artigo fornece mais informações sobre como alterar a visibilidade.
É possível converter um usuário membro em um usuário convidado. Isso é útil para usuários internos cujas permissões devem ser limitadas ao 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 quem 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 por email em vez de usuários externos ou membros
É possível 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.
- Um objeto de contato de email e um membro externo ou usuário convidado habilitado para email 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 do usuário externo convidado, ele criará o usuário externo, mas não será habilitado para email.
- Se houver um usuário externo habilitado para email com o mesmo email, uma tentativa de criar um objeto de contato de email gerará uma exceção no momento da criação.
Importante
O uso de contatos de email requer o AD DS (Active Directory Services) ou o PowerShell do Exchange Online. O Microsoft Graph não fornece uma chamada à API para gerenciar contatos.
A tabela a seguir exibe os resultados de objetos de contato de email e estados de usuário externos.
Estado existente | Cenário de provisionamento | Resultado efetivo |
---|---|---|
Nenhum | Convidar membro B2B | Usuário membro não habilitado para email. Veja observações importantes. |
Nenhum | Convidar participantes B2B | Usuário externo habilitado para email. |
O objeto de contato de email existe | Convidar membro B2B | Erro. Conflito de Endereços Proxy. |
O objeto de contato de email existe | Convidar participantes B2B | Contato por email e usuário externo não habilitado para email. Veja observações importantes. |
Usuário convidado externo habilitado para email | Criar objeto de contato por email | Erro |
Existe um usuário membro externo habilitado para email | Criar contato por email | Erro |
A Microsoft recomenda usar as colaboração B2B do Microsoft Entra (em vez da sincronização GAL tradicional) para criar:
- Usuários externos que você habilita para exibir na GAL.
- Usuários membros externos, que aparecem na GAL por padrão, mas não estã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 essa abordagem recomendada para atingir a meta:
- Convidar usuários convidados.
- Exibi-los a partir da GAL.
- Desabilite-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 outro acesso a recursos). O uso de um objeto de contato de email para representar um usuário apresenta os seguintes desafios.
- Grupos do Office 365. Os Grupos do Office 365 oferecem suporte a políticas que regem os tipos de usuários que podem ser membros de grupos e interagir com o 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 grupos de autoatendimento (SSGM) do Microsoft Entra. Os objetos de contato de email não são elegíveis para serem membros de grupos que usam 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, Revisões de Acesso. Você pode usar o recurso de revisões de acesso para examinar e atestar a associação ao grupo do Office 365. As revisões de acesso são baseadas em objetos de usuário. Membros representados por objetos de contato de email estão fora do escopo das revisões de acesso.
- Microsoft Entra ID Governance, EM (Gerenciamento de Direitos). 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 dá suporte a objetos de contato de email.
considerações de Acesso Condicional do Microsoft Entra
O estado do usuário, dispositivo ou rede no locatário principal do usuário não é transmitido ao locatário de recursos. Portanto, um usuário externo pode não atender às 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 respeitam a autenticação multifator e a conformidade do dispositivo do locatário inicial.
- Exigir autenticação multifator. Sem o 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 atendida no locatário inicial). Esse cenário resulta em vários desafios de autenticação multifator. Se precisarem redefinir suas provas de autenticação multifator, talvez não estejam cientes dos vários 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, no locatário de recursos ou em ambos.
- Exigir que o dispositivo seja marcado como em conformidade. Sem o CTAS configurado, a identidade do dispositivo não é registrada no locatário de recursos, portanto, o usuário externo não poderá acessar os recursos que exigem esse controle.
- Exigir um dispositivo ingressado no Microsoft Entra híbrido. Sem o CTAS configurado, a identidade do dispositivo não é registrada no locatário de recursos (ou no Active Directory local conectado ao locatário de recursos). Portanto, o usuário externo não poderá acessar recursos que exigem esse controle.
- Exigir aplicativo cliente aprovado ou Exigir política de proteção de aplicativo. Sem o CTAS configurado, os usuários externos não podem aplicar a política de MAM (Gerenciamento de Aplicativo Móvel) do Intune de locatário de recurso porque ela também requer o registro do dispositivo. A política de Acesso Condicional do locatário de recurso que usa esse controle não possibilita que a proteção de MAM do locatário principal atenda à 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.
- Entrada suspeita e Usuário suspeito. O comportamento do usuário em seu locatário principal determina, em parte, o risco de entrada e o risco do usuário. O locatário principal armazena os dados e a pontuação de risco. Se as políticas de locatário de recursos bloquearem um usuário externo, um administrador de locatário de recursos poderá não conseguir habilitar o acesso. Os usuários do Microsoft Extra ID Protection e do B2B explicam como o Microsoft Extra ID Protection detecta as credenciais comprometidas dos usuários do Microsoft Entra.
- Localizações. As definições de localização nomeada no locatário de recursos determinam o escopo da política. O escopo da política não avalia as localizações confiáveis gerenciadas no locatário principal. Se sua organização quiser compartilhar localizações confiáveis entre locatários, defina as localizações 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 cumpra as práticas recomendadas de segurança. Examine a lista de verificação de segurança e as práticas recomendadas para obter diretrizes sobre como proteger seu locatário. Verifique se essas práticas recomendadas são seguidas e examine-as com todos os locatários com os quais você colabora de perto.
Proteger as contas de administrador e garantir privilégios mínimos
- Encontrar e resolver lacunas na cobertura de autenticação forte para seus administradores
- Melhorar a segurança com o princípio de privilégios mínimos para usuários e aplicativos. Revisar as funções com menos privilégios por tarefa no Microsoft Entra ID.
- Minimize o acesso persistente do administrador habilitando o Privileged Identity Management.
Monitorar seu ambiente multilocatário
- Monitore as alterações nas políticas de acesso entre locatários usando a interface do usuário de logs de auditoria, a API ou a integração do Azure Monitor (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 de 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 de política de acesso entre locatários.
AuditLogs
| where Category contains "CrossTenant"
- Monitore todos os 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 as alterações nas políticas de acesso entre locatários que permitem ou não a 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 atividade de acesso entre locatários. Monitorar permite que você veja quem está acessando recursos em seu locatário e a origem desses.
Grupos de associação dinâmica
Se sua organização estiver usando a condição grupo de associação dinâmico 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 a atribuição de usuário a aplicativos. Se um aplicativo tiver a propriedade Atribuição de usuário necessária? definida como Não, os usuários externos poderão acessar o aplicativo. Os administradores de aplicativos devem entender os impactos no controle de acesso, especialmente se o aplicativo contém 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 a todos os usuários do locatário que se autenticam. Esta configuração está ativada por padrão.
Defesa em profundidade
Acesso condicional.
- Defina as políticas de controle de acesso para controlar o acesso aos recursos.
- Pense nos usuários externos ao criar as políticas de Acesso Condicional.
- 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 grupo de associação dinâmico 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 Gerenciamento Restrito
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 limitará o número de pessoas que podem adicionar ou remover membros do grupo e contas de provisionamento 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. É possível usar os termos de uso para exigir que os usuários externos aprovem os termos de uso antes de acessar os recursos.
Considerações sobre licenciamento para usuários convidados com recursos de Microsoft Entra ID P1 ou P2
Os preços do Microsoft Entra ID baseiam-se em usuários ativos mensais (MAU). O número de usuários ativos é a contagem de usuários exclusivos com atividade de autenticação em um mês civil. O modelo de cobrança da ID Externa do Microsoft Entra descreve como os preços são baseados no MAU.
Considerações sobre o Office 365
As informações a seguir abordam o Office 365 no contexto dos cenários desse documento. Informações detalhadas estão disponíveis em Colaboração entre locatários do Microsoft 365 Colaboração entre locatários do 365. Este artigo descreve opções que incluem o uso de uma localização central para arquivos e conversas, compartilhamento de calendários, uso de mensagens instantâneas, chamadas de áudio/vídeo para comunicação e proteção de acesso a recursos e aplicativos.
Microsoft Exchange Online
O Exchange online limita certas 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 usuários 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 poderá emitir um token do Exchange Online. Como resultado, ele não poderá acessar o recurso.
- Os usuários externos não podem usar as caixas de correio do Exchange Online compartilhadas ou delegadas no locatário de recursos.
- Você pode atribuir um usuário externo a uma caixa de correio compartilhada, mas ele não poderá acessá-la.
- Você precisa exibir os usuários externos para incluí-los na GAL. Por padrão, eles estão ocultos.
- Os 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 aparecerem, a lista incluirá objetos de usuário de usuários externos que não resgataram um convite. Com base em seu cenário, talvez você queira ou não os objetos listados.
- Os usuários externos podem não estar ocultos usando o Exchange Online PowerShell. É possível executar o cmdlet do PowerShell Set-MailUser para definir a propriedade HiddenFromAddressListsEnabled com um valor de $false.
Por exemplo:
Set-MailUser [ExternalUserUPN] -HiddenFromAddressListsEnabled:\$false\
Em que ExternalUserUPN é o UserPrincipalName calculado.
Por exemplo:
Set-MailUser externaluser1_contoso.com#EXT#@fabricam.onmicrosoft.com\ -HiddenFromAddressListsEnabled:\$false
Os usuários externos podem não 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 Exchange Online PowerShell. O Centro de Administração do Exchange Online não permite que você modifique os atributos usando a GUI (interface gráfica do usuário).
Como mostrado no exemplo, é possível usar o cmdlet do PowerShell Set-MailUser em propriedades específicas de email. Há mais propriedades do usuário que podem ser modificadas com o cmdlet Set-User do PowerShell. Você pode modificar a maioria das propriedades com as APIs do Graph da Microsoft.
Um dos recursos mais úteis do Set-MailUser é a capacidade de manipular a propriedade EmailAddresses . Esse atributo multivalorizado pode conter vários endereços proxy para o usuário externo (como SMTP, X500, SIP (Protocolo de Iniciação de Sessão)). Por padrão, um usuário externo tem o endereço SMTP principal carimbado correlacionando-se com o UserPrincipalName (UPN). Se você quiser alterar o SMTP primário ou adicionar endereços SMTP, poderá definir essa propriedade. Você não pode usar o Centro de Administração do Exchange; use o Exchange Online PowerShell. 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 Office 365 e a colaboração B2B do Microsoft Entra descrevem como é possível 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 de 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 é OFF por padrão. Essa configuração proíbe que os usuários convidados sejam descobertos quando estiverem ocultos da GAL Exchange Online. É possível permitir que os usuários convidados se tornem visíveis de duas maneiras (não mutuamente exclusivas):
- Você pode ativar 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 visíveis na GAL do Exchange Online também estão visíveis no seletor de pessoas do SharePoint no Microsoft 365. As contas são visíveis, independentemente da configuração de ShowPeoplePickerSuggestionsForGuestUsers.
Microsoft Teams
O Microsoft Teams tem recursos para limitar o acesso e com base no tipo de usuário. As 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 alternância de locatário do cliente do Teams ao trabalhar nessa plataforma fora do locatário principal.
O mecanismo de alternância de locatário do Microsoft Teams pode exigir que os usuários alternem manualmente o contexto do cliente Teams ao trabalhar nessa plataforma fora do locatário principal.
É possível habilitar usuários do Teams de outro domínio externo inteiro para localizar, chamar, bater papo e configurar reuniões com os usuários com Teams Federation. Gerenciar reuniões externas e conversar com pessoas e organizações usando as identidades da Microsoft descreve como você pode permitir que os usuários em sua organização conversem e se reúnam com pessoas de fora da organização que usam a Microsoft como provedor de identidade.
Considerações sobre licenciamento de usuários convidados no Teams
Ao usar 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 convidados a Grupos do Microsoft 365 permite que você e sua equipe colaborem com pessoas de fora da sua organização concedendo acesso aos convidados a conversas em grupo, arquivos, convites de calendário e o bloco de observações do grupo.
- Microsoft Teams. Recursos de proprietário de equipe, membro e convidado no Teams descreve a experiência da conta de convidado no Microsoft Teams. É possível habilitar uma experiência de fidelidade completa no Teams usando usuários membros externos.
- Para vários locatários em nossa nuvem comercial, os usuários licenciados em seu locatário principal podem acessar os recursos de outro locatário dentro da mesma entidade legal. Você pode conceder acesso usando a configuração de membros externos sem taxas extras de licenciamento. Esta configuração se aplica ao SharePoint e OneDrive for Teams 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 o Teams requer uma licença adicional para cada membro B2B. O requisito também pode afetar outras cargas de trabalho, como o Power BI.
- O uso de membro B2B para locatários que não fazem parte da mesma pessoa jurídica 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 (Gerenciamento de relacionamento com o cliente) do Dynamics podem exigir licenciamento em cada locatário no qual um usuário é representado.
Próximas etapas
- Introdução ao gerenciamento de usuários multilocatários é o primeiro de uma série de artigos que fornecem diretrizes 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ário descrevem três cenários para os quais você pode usar os recursos de gerenciamento de usuários multilocatários: iniciados pelo usuário final, com script e automatizados.
- Soluções comuns para gerenciamento de usuários multilocatários quando a locação única não funciona para o seu cenário, esse artigo fornece diretrizes para estes desafios: gerenciamento automático do ciclo de vida do usuário e alocação de recursos entre locatários, compartilhando 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 MTO (Organizações Multilocatários). Esse cenário se aplica especificamente aos MTOs que têm uma implantação na Nuvem Soberana dos EUA com o Microsoft 365 US Government (GCC High) e o Azure Government. Ela também aborda a colaboração externa em ambientes altamente regulamentados, inclusive de organizações que estão abrigadas na Nuvem Comercial ou na Nuvem Soberana dos EUA.