Editar

Partilhar via


Várias florestas com AD DS e ID do Microsoft Entra

Azure Virtual Desktop
Microsoft Entra ID
Microsoft Entra
Azure ExpressRoute
Azure Storage

Muitas organizações querem aproveitar a Área de Trabalho Virtual do Azure para criar ambientes com várias florestas locais do Ative Directory.

Este artigo expande a arquitetura descrita no artigo Área de Trabalho Virtual do Azure em escala empresarial. Destina-se a ajudá-lo a entender como integrar vários domínios e a Área de Trabalho Virtual do Azure usando o Microsoft Entra Connect para sincronizar usuários dos Serviços de Domínio Ative Directory (AD DS) locais com a ID do Microsoft Entra.

Arquitetura

Diagrama que mostra a integração da Área de Trabalho Virtual do Azure com os Serviços de Domínio Ative Directory.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de dados

Nessa arquitetura, o fluxo de identidade funciona da seguinte maneira:

  1. O Microsoft Entra Connect sincroniza usuários do CompanyA.com e do CompanyB.com com um locatário do Microsoft Entra (NewCompanyAB.onmicrosoft.com).
  2. Pools de hosts, espaços de trabalho e grupos de aplicativos são criados em assinaturas separadas e redes virtuais faladas.
  3. Os usuários são atribuídos aos grupos de aplicativos.
  4. Os hosts de sessão da Área de Trabalho Virtual do Azure nos pools de hosts ingressam nos domínios CompanyA.com e CompanyB.com usando os controladores de domínio (DCs) no Azure.
  5. Os usuários entram usando o aplicativo de Área de Trabalho Virtual do Azure ou o cliente Web com um Nome Principal de Usuário (UPN) no seguinte formato: user@NewCompanyA.com, user@CompanyB.comou user@NewCompanyAB.com, dependendo do sufixo UPN configurado.
  6. Os usuários são apresentados aos seus respetivos desktops virtuais ou aplicativos. Por exemplo, os usuários na CompanyA são apresentados a uma área de trabalho virtual ou aplicativo no Espaço de Trabalho A, pool de hosts 1 ou 2.
  7. Os perfis de usuário do FSLogix são criados em compartilhamentos do Azure Files nas contas de armazenamento correspondentes.
  8. Os GPOs (Objetos de Política de Grupo) sincronizados no local são aplicados aos usuários e aos hosts de sessão da Área de Trabalho Virtual do Azure.

Componentes

Essa arquitetura usa os mesmos componentes listados na Área de Trabalho Virtual do Azure na arquitetura de escala empresarial.

Além disso, essa arquitetura usa os seguintes componentes:

  • Microsoft Entra Connect no modo de preparação: O servidor de preparo para topologias do Microsoft Entra Connect fornece redundância adicional para a instância do Microsoft Entra Connect.

  • Assinaturas do Azure, espaços de trabalho da Área de Trabalho Virtual do Azure e pools de hosts: você pode usar várias assinaturas, espaços de trabalho da Área de Trabalho Virtual do Azure e pools de hosts para limites de administração e requisitos de negócios.

Detalhes do cenário

Este diagrama de arquitetura representa um cenário típico que contém os seguintes elementos:

  • O locatário do Microsoft Entra está disponível para uma nova empresa chamada NewCompanyAB.onmicrosoft.com.
  • O Microsoft Entra Connect sincroniza usuários do AD DS local com a ID do Microsoft Entra.
  • A empresa A e a empresa B têm subscrições do Azure separadas. Eles também têm uma assinatura de serviços compartilhados, referida como a Assinatura 1 no diagrama.
  • Uma arquitetura hub-spoke do Azure é implementada com uma rede virtual de hub de serviços compartilhados.
  • Ambientes complexos híbridos locais do Ative Directory estão presentes com duas ou mais florestas do Ative Directory. Os domínios vivem em florestas separadas, cada uma com um sufixo UPN diferente. Por exemplo, CompanyA.local com o sufixo UPN CompanyA.com, CompanyB.local com o sufixo UPN CompanyB.com e um sufixo UPN adicional, NewCompanyAB.com.
  • Os controladores de domínio para ambas as florestas estão localizados no local e no Azure.
  • Os domínios verificados estão presentes no Azure para CompanyA.com, CompanyB.com e NewCompanyAB.com.
  • GPO e autenticação herdada, como Kerberos, NTLM (Windows New Technology LAN Manager) e LDAP (Lightweight Directory Access Protocol), são usados.
  • Para ambientes do Azure que ainda têm infraestrutura local de dependência, a conectividade privada (VPN site a site ou Rota Expressa do Azure) é configurada entre o local e o Azure.
  • O ambiente de Área de Trabalho Virtual do Azure consiste em um espaço de trabalho da Área de Trabalho Virtual do Azure para cada unidade de negócios e dois pools de hosts por espaço de trabalho.
  • Os hosts de sessão da Área de Trabalho Virtual do Azure são associados aos controladores de domínio no Azure. Ou seja, os hosts de sessão CompanyA ingressam no domínio CompanyA.local e os hosts de sessão CompanyB ingressam no domínio CompanyB.local.
  • As contas de Armazenamento do Azure podem usar os Arquivos do Azure para perfis FSLogix. É criada uma conta por domínio da empresa (ou seja, CompanyA.local e CompanyB.local) e a conta é associada ao domínio correspondente.

Nota

Os Serviços de Domínio Ative Directory são um componente local autogerenciado em muitos ambientes híbridos, e os Serviços de Domínio Microsoft Entra fornecem serviços de domínio gerenciados com um subconjunto de recursos AD DS tradicionais totalmente compatíveis, como ingresso no domínio, política de grupo, LDAP e autenticação Kerberos/NTLM. Para obter uma comparação detalhada desses componentes, consulte Comparar AD DS autogerenciado, ID do Microsoft Entra e Serviços de Domínio Microsoft Entra gerenciados.

A ideia da solução Várias florestas da Área de Trabalho Virtual do Azure usando os Serviços de Domínio do Microsoft Entra discute a arquitetura que usa os Serviços de Domínio Microsoft Entra gerenciados na nuvem.

Potenciais casos de utilização

Aqui estão alguns casos de uso relevantes para essa arquitetura:

Considerações

Ao projetar sua carga de trabalho com base nessa arquitetura, tenha em mente as seguintes ideias.

Objetos de Política de Grupo

  • Para estender a infraestrutura de GPO para a Área de Trabalho Virtual do Azure, os controladores de domínio locais devem sincronizar com os controladores de domínio IaaS (infraestrutura como serviço) do Azure.

  • Estender a infraestrutura de GPO para controladores de domínio IaaS do Azure requer conectividade privada.

Rede e conectividade

  • Os controladores de domínio são componentes compartilhados, portanto, precisam ser implantados em uma rede virtual de hub de serviços compartilhados nessa arquitetura hub-spoke.

  • Os anfitriões de sessão do Ambiente de Trabalho Virtual do Azure juntam-se ao controlador de domínio no Azure através do respetivo emparelhamento de rede virtual hub-spoke.

Armazenamento do Azure

As seguintes considerações de design se aplicam a contêineres de perfil de usuário, contêineres de cache em nuvem e pacotes MSIX :

  • Você pode usar os Arquivos do Azure e os Arquivos NetApp do Azure nesse cenário. Você escolhe a solução certa com base em fatores como desempenho esperado, custo e assim por diante.

  • As contas de Armazenamento do Azure e os Arquivos NetApp do Azure estão limitados a ingressar em um único AD DS de cada vez. Nesses casos, várias contas de Armazenamento do Azure ou instâncias de Arquivos NetApp do Azure são necessárias.

Microsoft Entra ID

Em cenários com usuários em várias florestas locais do Ative Directory, apenas um servidor Microsoft Entra Connect Sync está conectado ao locatário do Microsoft Entra. Uma exceção a isso é um servidor Microsoft Entra Connect usado no modo de preparação.

Diagrama que mostra variações de design para várias florestas do Ative Directory para a Área de Trabalho Virtual do Azure.

As seguintes topologias de identidade são suportadas:

  • Várias florestas locais do Ative Directory.
  • Uma ou mais florestas de recursos confiam em todas as florestas de conta.
  • Uma topologia de malha completa permite que usuários e recursos estejam em qualquer floresta. Comumente, existem confianças bidirecionais entre as florestas.

Para obter mais detalhes, consulte a seção Servidor de preparo das topologias do Microsoft Entra Connect.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

  • Tom Maher - Brasil | Engenheiro de Segurança e Identidade Sênior

Próximos passos

Para obter mais informações, consulte os seguintes artigos: