Planejar, projetar e implementar o Microsoft Entra Connect

Concluído

O Microsoft Entra Connect é uma solução que conecta o Active Directory local de uma organização com o Microsoft Entra ID baseado em nuvem. A TI pode sincronizar identidades locais para o Azure e garantir uma identidade consistente em ambas as plataformas. Essa conexão habilita serviços como sincronização de hash de senha, autenticação de passagem e SSO (logon único) contínuo.

O Microsoft Entra Connect é a ferramenta da Microsoft criada para atender e atingir suas metas de identidade híbrida. Ele fornece os seguintes recursos:

• Sincronização – responsável pela criação de usuários, grupos e outros objetos. Garanta que as informações de identidade dos usuários e grupos locais correspondam às da nuvem. Essa sincronização também inclui os hashes de senha.
• Sincronização de hash de senha: um método de entrada que sincroniza um hash da senha do AD local de um usuário com o Microsoft Entra ID.
• Autenticação de passagem – um método de entrada em que os usuários podem usar a mesma senha localmente e na nuvem, mas que não exige uma infraestrutura maior de um ambiente federado.
• Integração de federação – a federação é uma parte opcional do Microsoft Entra e pode ser usada para configurar um ambiente híbrido usando uma infraestrutura do AD FS local. Ela também fornece recursos de gerenciamento do AD FS, como renovação de certificado e implantações adicionais de servidor do AD FS.
• Monitoramento de integridade - O Microsoft Entra Connect-Health fornece um monitoramento robusto.

Por que usar o Microsoft Entra Connect?

A integração de seus diretórios locais ao Microsoft Entra ID torna os usuários mais produtivos ao fornecer uma identidade comum para acesso aos recursos na nuvem e locais. Com o Microsoft Entra Connect, os usuários podem utilizar uma única identidade para acessar aplicativos locais e serviços de nuvem, como o Microsoft 365. Além disso, as organizações podem fornecer uma experiência de implantação fácil para sincronização e entrada usando uma única ferramenta. O Microsoft Entra Connect substitui as versões mais antigas das ferramentas de integração de identidade e está incluído na sua assinatura do Microsoft Entra ID.

Selecionar um método de autenticação

A identidade é o novo plano de controle da segurança de TI, portanto, a autenticação é a proteção de acesso da organização para o novo mundo de nuvem. As organizações precisam de um plano de controle de identidade que reforce a segurança e mantenha os aplicativos de nuvem protegidos contra invasores. Quando a solução de identidade híbrida do Microsoft Entra é o seu novo plano de controle, a autenticação é a base do acesso à nuvem. A escolha do método de autenticação correto é uma primeira decisão fundamental na configuração de uma solução de identidade híbrida do Microsoft Entra. Para escolher um método de autenticação, é necessário considerar o tempo, a infraestrutura existente, a complexidade e o custo de implementação de sua escolha. Esses fatores são diferentes para cada organização e podem mudar ao longo do tempo.

Autenticação na nuvem

Ao escolher esse método de autenticação, o Microsoft Entra ID cuida do processo de entrada dos usuários. Quando você une com o SSO (logon único) contínuo, os usuários podem entrar em aplicativos de nuvem sem precisar reinserir suas credenciais. Com a autenticação na nuvem, é possível escolher entre duas opções:

Sincronização de hash de senha (PHS) do Microsoft Entra . A maneira mais simples de habilitar a autenticação para objetos de diretório locais no Microsoft Entra. Os usuários podem usar o mesmo nome de usuário e senha que usam localmente, sem a necessidade de implantar nenhuma infraestrutura adicional.

• Esforço. A sincronização de hash de senha exige o mínimo de esforço de implantação, manutenção e infraestrutura. Esse nível de esforço normalmente se aplica a organizações que precisam apenas que seus usuários entrem no Microsoft 365, em aplicativos SaaS e em outros recursos baseados no Microsoft Entra ID. Quando ativada, a sincronização de hash de senha faz parte do processo de sincronização do Microsoft Entra Connect e é executada a cada dois minutos.
• Experiência do usuário. Para melhorar a experiência de entrada dos usuários, implante o SSO contínuo com a sincronização de hash de senha. O SSO contínuo elimina prompts desnecessários quando os usuários estão conectados.
• Cenários avançados. Se as organizações optarem por isso, é possível utilizar insights de identidades com relatórios do Microsoft Entra ID Protection com o Microsoft Entra ID Premium P2. Um exemplo é o relatório de credenciais vazadas. O Windows Hello para Empresas tem requisitos específicos quando a sincronização de hash de senha é usada. O Microsoft Entra Domain Services exige a sincronização de hash de senha para criar usuários com suas credenciais corporativas no domínio gerenciado.
• Continuidade dos negócios. O uso da sincronização de hash de senha com a autenticação na nuvem está altamente disponível como um serviço de nuvem que pode ser expandido para todos os datacenters da Microsoft. Para garantir que a sincronização de hash de senha não fique inativa por longos períodos, implante um segundo servidor do Microsoft Entra Connect em modo de preparo em uma configuração de espera.
• Considerações. No momento, a sincronização de hash de senha não impõe imediatamente as alterações nos estados da conta local. Nessa situação, um usuário tem acesso a aplicativos em nuvem até que o estado da conta do usuário seja sincronizado com o Microsoft Entra ID. As organizações podem desejar superar essa limitação executando um novo ciclo de sincronização depois que os administradores fizerem atualizações em massa nos estados da conta do usuário local. Um exemplo é a desabilitação de contas.

Autenticação de passagem do Microsoft Entra (PTA). Fornece uma validação de senha simples para os serviços de autenticação do Microsoft Entra usando um agente de software que é executado em um ou mais servidores locais. Os servidores validam os usuários diretamente no Active Directory local, o que garante que a validação de senha não ocorra na nuvem. As empresas com um requisito de segurança de imposição imediata de estados de conta de usuário local, políticas de senha e horas de entrada podem usar esse método de autenticação.

• Esforço. Para a autenticação de passagem, você precisa de um ou mais (recomendamos três) agentes leves instalados nos servidores existentes. Esses agentes precisam ter acesso ao Active Directory Domain Services local, incluindo os controladores de domínio locais do AD. Esses precisam ter acesso de saída à Internet e acesso aos controladores de domínio. Por esse motivo, não há suporte para implantação dos agentes em uma rede de perímetro.
• Experiência do usuário. Para melhorar a experiência de entrada dos usuários, implante o SSO contínuo com a autenticação de passagem. O SSO contínuo elimina prompts desnecessários após a entrada dos usuários.
• Cenários avançados. A autenticação de passagem impõe a política de conta local no momento da entrada. Por exemplo, o acesso é negado quando um estado de conta do usuário local é desabilitado, bloqueado ou a senha expirar. O acesso também poderá ser negado se a tentativa de entrada ficar fora das horas em que o usuário tiver permissão para entrar.
• Continuidade dos negócios. Recomendamos a implantação de dois agentes extras de autenticação de passagem. Esses extras são adicionais ao primeiro agente no servidor do Microsoft Entra Connect. Essa implantação garante a alta disponibilidade das solicitações de autenticação. Quando você tiver três agentes implantados, um deles ainda poderá falhar quando outro agente estiver inoperante para manutenção.
• Considerações. É possível usar a sincronização de hash de senha como um método de autenticação de backup a para autenticação de passagem quando os agentes não puderem validar as credenciais de um usuário devido a uma falha local significativa. Ocorreu um erro na sincronização de hash de senha que não acontece automaticamente e você deve usar o Microsoft Entra Connect para alternar manualmente o método de entrada.

Autenticação federada

Quando você escolhe esse método de autenticação, o Microsoft Entra ID transfere o processo de autenticação para um sistema de autenticação confiável separado, como os Serviços de Federação do Active Directory (AD FS) local, para validar a senha do usuário. O sistema de autenticação pode fornecer requisitos de autenticação avançada adicionais. Entre os exemplos estão a autenticação baseada em cartão inteligente ou a autenticação multifator de terceiros.

• Esforço. Um sistema de autenticação federada depende de um sistema externo confiável para autenticar os usuários. Algumas empresas querem reutilizar seus investimentos em sistemas federados existentes com a solução de identidade híbrida do Microsoft Entra. A manutenção e o gerenciamento do sistema federado estão fora do controle do Microsoft Entra ID. Cabe à organização usar o sistema federado para garantir que ele seja implantado de forma segura e possa lidar com a carga de autenticação.

• Experiência do usuário. A experiência do usuário de autenticação federada depende da implementação dos recursos, da topologia e da configuração do farm de federação. Algumas organizações precisam dessa flexibilidade para adaptar e configurar o acesso ao farm de federação de acordo com seus requisitos de segurança. Por exemplo, é possível configurar os usuários e os dispositivos conectados internamente para conectar os usuários automaticamente, sem notificá-los para que insiram suas credenciais. Essa configuração funciona porque elas já entraram em seus dispositivos. Se necessário, alguns recursos de segurança avançada dificultam ainda mais o processo de entrada dos usuários.

• Cenários avançados. Uma solução de autenticação federada é necessária quando os clientes têm um requisito de autenticação que o Microsoft Entra ID não dá suporte nativamente.

  • Autenticação que exige certificados ou cartões inteligentes.
  • Servidores MFA locais ou provedores de autenticação multifator de terceiros exigindo um provedor de identidade federado.
  • Autenticação usando soluções de autenticação de terceiros.
  • Entrada que exige um sAMAccountName, por exemplo, DOMAIN\nome de usuário, em vez de um nome UPN, por exemplo, user@domain.com.

• Continuidade dos negócios. Normalmente, os sistemas federados exigem uma matriz com balanceamento de carga de servidores, conhecida como um farm. Esse farm é configurado em uma rede interna e topologia de rede de perímetro para garantir a alta disponibilidade para as solicitações de autenticação.

• Considerações. Normalmente, os sistemas federados exigem um investimento mais significativo em infraestrutura local. A maioria das organizações escolherá essa opção caso já tenha um investimento de federação local. Essa opção também é escolhida caso ela seja um forte requisito comercial o uso de um provedor de identidade única. A federação é mais complexa de operar e de resolver problemas em comparação com soluções de autenticação na nuvem.

Diagramas de arquitetura

Os diagramas a seguir descrevem os componentes de arquitetura de alto nível necessários para cada método de autenticação que você pode usar com a solução de identidade híbrida do Microsoft Entra. Eles fornecem uma visão geral para ajudá-lo a comparar as diferenças entre as soluções.

• Simplicidade de uma solução de sincronização de hash de senha:

  

• Requisitos de autenticação de passagem do agente, usando dois agentes para redundância:

  

• Componentes necessários para federação no perímetro e na rede interna de sua organização:

  

Recomendações

Seu sistema de identidade garante que os usuários tenham acesso aos aplicativos de nuvem e de linha de negócios que você migra e disponibiliza na nuvem. Para manter os usuários autorizados produtivos e os atores ruins fora dos dados confidenciais de sua organização, a autenticação controla o acesso aos aplicativos.

Use ou habilite a sincronização de hash de senha para o método de autenticação escolhido, seja qual for, pelos seguintes motivos:

• Alta disponibilidade e recuperação de desastre. A autenticação de passagem e a federação dependem da infraestrutura local. Para autenticação de passagem, o espaço local inclui o hardware e a rede do servidor que os agentes de autenticação de passagem exigem. Para a federação, a superfície local é ainda maior. Ela exige que os servidores na rede de perímetro atuem como um proxy para as solicitações de autenticação e os servidores internos de federação. Para evitar pontos únicos de falha, implante servidores redundantes. Assim, as solicitações de autenticação sempre serão atendidas se um componente falhar. A autenticação de passagem e a federação também dependem dos controladores de domínio para responder às solicitações de autenticação, que também podem falhar. Muitos desses componentes precisam de manutenção para permanecerem íntegros. Há uma probabilidade maior de interrupções quando a manutenção não é planejada e implementada corretamente. Evite interrupções utilizando a sincronização de hash de senha porque o serviço de autenticação de nuvem do Microsoft Entra escala globalmente e está sempre disponível.

• Sobrevivência à interrupção local. As consequências de uma interrupção local devido a um ataque cibernético ou desastre podem ser significativas, variando de danos à reputação da marca até a paralisação da organização que não consegue conter o ataque. Recentemente, muitas organizações foram vítimas de ataques de malware, incluindo ransomware direcionado, o que fez seus servidores locais ficarem inativos. Quando a Microsoft ajuda os clientes a lidar com esses tipos de ataques, ela observa duas categorias de organizações:

  • Organizações que ativaram a sincronização de hash de senha, com autenticação de passagem ou federada, alteram sua autenticação principal. Elas podem usar a sincronização de hash de senha. Elas voltaram a ficar online em questão de horas. Ao usar o acesso ao email via Microsoft 365, elas trabalharam para resolver problemas e acessar outras cargas de trabalho baseadas em nuvem.
  • As organizações que anteriormente não habilitaram a sincronização de hash de senha precisaram recorrer a sistemas de email de consumidor externo não confiáveis para comunicação para resolução dos problemas. Nesses casos, levava semanas para restaurar sua infraestrutura de identidade local, antes que os usuários conseguissem entrar em aplicativos baseados em nuvem novamente.

• Proteção de identidade. Uma das melhores maneiras de proteger os usuários na nuvem é o Microsoft Entra Identity Protection com o Microsoft Entra Premium P2. A Microsoft examina a Internet continuamente para ver se há listas de usuários e de senhas comercializadas e disponibilizadas por atores mal-intencionados na dark Web. O Microsoft Entra ID pode usar essas informações para verificar se algum dos nomes de usuário e senhas da sua organização foi comprometido. Portanto, é fundamental habilitar a sincronização de hash de senha, independentemente do método de autenticação usado, seja a autenticação federada, seja a de passagem. As credenciais vazadas são apresentadas como um relatório. Use essas informações para bloquear ou forçar os usuários a alterar suas senhas quando tentarem entrar com senhas vazadas.

Conceitos de design do Microsoft Entra Connect

Esta seção descreve as áreas que devem ser consideradas durante o projeto de implementação do Microsoft Entra Connect. Ela aprofunda determinadas áreas e esses conceitos também são descritos brevemente em outros documentos.

sourceAnchor

O atributo sourceAnchor é definido como um atributo imutável durante o tempo de vida de um objeto. Ele identifica exclusivamente um objeto como sendo o mesmo objeto local e no Microsoft Entra ID. O atributo também é chamado de immutableId e os dois nomes são usados como sinônimos. O atributo é usado para os seguintes cenários:

• Quando um novo servidor de mecanismo de sincronização é criado ou reconstruído após um cenário de recuperação de desastre, esse atributo vincula objetos existentes no Microsoft Entra ID a objetos locais.
• Se você passar de uma identidade somente na nuvem para um modelo de identidade sincronizado, esse atributo permitirá que os objetos façam uma "correspondência rígida" com objetos existentes no Microsoft Entra ID com objetos locais.
• Se você usar federação, esse atributo, junto com userPrincipalName , é usado na declaração para identificar exclusivamente um usuário.

O valor do atributo deve seguir as regras a seguir:

• Menos de 60 caracteres

  • Caracteres diferentes de a-z, A-Z ou 0-9 são codificados e contados como três caracteres

• Não contém nenhum caractere especial: \ ! # $ % & * + / = ? ^ { } | ~ > < ( ) ' ; : , [ ] " @ _

• Ser globalmente exclusivo

• Ser uma cadeia de caracteres, um inteiro ou um binário

• Não deve se basear no nome do usuário, uma vez que ele pode mudar

• Não deve ser sensível a maiúsculas e minúsculas e evitar valores que variem de acordo com a caixa

• Ser atribuído quando o objeto é criado

Se você tiver apenas uma floresta local, o atributo que você deverá usar será objectGuid. Você também pode usar o atributo objectGuid ao utilizar configurações expressas no Microsoft Entra Connect. E também o atributo usado pelo DirSync. Se você tiver várias florestas e não mover os usuários entre florestas e domínios, o objectGUID será um bom atributo a ser usado. Outra solução é escolher um atributo existente que você sabe que não será alterado. Os atributos usados normalmente incluem employeeID. Se você considerar um atributo que contenha letras, verifique se não há nenhuma possibilidade de a letra (letras maiúsculas ou letras minúsculas) alterar o valor do atributo. Atributos inválidos que não devem ser usados incluem os atributos com o nome do usuário. Depois que o atributo sourceAnchor for decidido, o assistente armazenará as informações em seu locatário do Microsoft Entra. As informações serão usadas em futuras instalações do Microsoft Entra Connect.

Entrada no Microsoft Entra

As configurações de sincronização da integração do diretório local com o Microsoft Entra ID podem afetar a forma como o usuário se autentica. O Microsoft Entra utiliza o userPrincipalName (UPN) para autenticar o usuário. No entanto, ao sincronizar os usuários, você deve escolher o atributo a ser usado para o valor de userPrincipalName cuidadosamente. Ao selecionar o atributo para fornecer o valor de UPN a ser usado no Azure, garanta que

• Os valores de atributo estão de acordo com a sintaxe UPN (RFC 822), o formato username@domain
• O sufixo nos valores corresponde a um dos domínios personalizados verificados no Microsoft Entra ID

Em configurações expressas, a opção suposta para o atributo é userPrincipalName. Se o atributo userPrincipalName não contém o valor que você deseja que os usuários usem para entrar no Azure, escolha Instalação Personalizada.

Estado do domínio personalizado e nome principal do usuário

Verifique se há um domínio verificado para o sufixo UPN (nome principal do usuário). John é um usuário em contoso.com. Você deseja que Carlos use o UPN john@contoso.com local para entrar no Azure após ter sincronizado os usuários com o diretório do Microsoft Entra contoso.onmicrosoft.com. Para fazer isso, você precisa adicionar e verificar contoso.com como um domínio personalizado no Microsoft Entra ID antes de começar a sincronizar os usuários. Se o sufixo UPN de Carlos, por exemplo, contoso.com, não corresponder a um domínio verificado no Microsoft Entra ID, a ferramenta substituirá o sufixo UPN por contoso.onmicrosoft.com.

Algumas organizações têm domínios não roteáveis, como contoso.local ou domínios de rótulo único simples, como contoso. Não é possível verificar um domínio não roteável. O Microsoft Entra Connect pode sincronizar apenas com um domínio verificado no Microsoft Entra ID. Quando você cria um diretório do Microsoft Entra, ele cria um domínio roteável que se torna o domínio padrão para sua ID do Microsoft Entra, por exemplo, contoso.onmicrosoft.com. Portanto, é necessário verificar se outros domínios roteáveis nesse cenário, caso você não deseje sincronizar com o domínio padrão onmicrosoft.com.

O Microsoft Entra Connect detecta se você está executando em um ambiente de domínio não roteável e avisa adequadamente para não prosseguir com as configurações expressas. Se você está operando em um domínio não roteável, é provável que o UPN dos usuários também tenha um sufixo não roteável. Por exemplo, se estiver executando em contoso.local, o Microsoft Entra Connect irá sugerir que você use configurações personalizadas ao invés de usar configurações expressas. Usando as configurações personalizadas, você pode especificar o atributo que deve ser usado como UPN para entrar no Azure depois que os usuários forem sincronizados com o Microsoft Entra ID.

Topologias para o Microsoft Entra Connect

Esta seção descreve várias topologias locais e do Microsoft Entra ID que usam a sincronização do Microsoft Entra Connect como a principal solução de integração; ela inclui configurações com suporte e sem suporte.

Topologia comum	Descrição
Floresta única, locatário do Microsoft Entra único	A topologia mais comum é uma floresta única local, com um ou vários domínios e um único locatário do Microsoft Entra. Para autenticação, é utilizada a sincronização de hash de senha. A instalação expressa do Azure AD Connect dá suporte apenas a esta topologia.
Várias florestas, locatário do Microsoft Entra único	Muitas organizações têm ambientes com várias florestas do Active Directory local. Há vários motivos para ter mais de uma floresta do Active Directory local. Exemplos típicos são designs com florestas de conta-recurso e o resultado de uma fusão ou aquisição. Quando você tem várias florestas, todas as florestas devem estar acessíveis por um único servidor de sincronização do Microsoft Entra Connect. O servidor deve ser unido a um domínio. Se necessário, para acessar todas as florestas, você pode colocar o servidor em uma rede de perímetro (também conhecida como DMZ, zona desmilitarizada e sub-rede selecionada).
Múltiplas florestas, servidor de sincronização única, os usuários são representados em apenas um diretório	Nesse ambiente, todas as florestas locais são tratadas como entidades separadas. Não há usuários presentes em outras florestas. Cada floresta tem sua própria organização do Exchange e não há nenhuma GALSync entre as florestas. Esta topologia deve ser a situação após uma fusão/aquisição ou em uma organização em que cada unidade de negócios opera de forma independente. Essas florestas serão da mesma empresa no Microsoft Entra ID e aparecerão com uma GAL unificada. Na imagem anterior, cada objeto em cada floresta é representado uma vez no metaverso e agregado no locatário de destino.
Várias florestas: malha completa com GALSync opcional	Uma topologia de malha completa permite que os usuários e recursos estejam localizados em qualquer floresta. Normalmente, há relações de confiança bidirecionais entre as florestas. Se o Exchange estiver presente em mais de uma floresta, poderá haver uma solução GALSync local (opcional). Cada usuário é representado como um contato em todas as outras florestas. GALSync geralmente é implementado por meio do FIM 2010 ou MIM 2016. O Microsoft Entra Connect não pode ser utilizado para o GALSync no local.
Várias florestas: floresta de recursos de conta	Nesse cenário, uma (ou mais) floresta de recursos confia em todas as florestas de conta. Essa floresta de recurso normalmente tem um esquema do Active Directory estendido com o Exchange e o Teams. Todos os serviços do Exchange e do Teams, bem como outros serviços compartilhados, estão localizados nessa floresta. Os usuários têm uma conta de usuário desabilitada nesta floresta e a caixa de correio está vinculada à floresta da conta.
Servidor de preparo	O Microsoft Entra Connect dá suporte à instalação em um segundo servidor no modo de preparo. Um servidor nesse modo lê dados de todos os diretórios conectados, mas não grava nada em diretórios conectados. Ele usa o ciclo de sincronização normal e, portanto, tem uma cópia atualizada dos dados de identidade.
Vários locatários Microsoft Entra	Existe um relacionamento individual entre um servidor de sincronização do Microsoft Entra Connect e um locatário. Para cada locatário do Microsoft Entra, você precisa de uma instalação do servidor da sincronização do Microsoft Entra Connect. As instâncias do locatário do AD são isoladas por design. Ou seja, os usuários em um locatário não podem ver os usuários no outro locatário. A separação de usuários é uma configuração com suporte. Caso contrário, você deve usar o modelo de locatário único do Microsoft Entra.
Cada objeto somente uma vez em um locatário do Microsoft Entra	Nessa topologia, um servidor de sincronização do Microsoft Entra Connect está conectado a cada locatário. Os servidores de sincronização do Microsoft Entra Connect devem ser configurados para filtragem, de modo que cada um tenha um conjunto de objetos mutuamente exclusivos para operar. Você pode, por exemplo, definir o escopo de cada servidor para um determinado domínio ou unidade organizacional.

Fatores de componente do Microsoft Entra Connect

O diagrama a seguir mostra uma arquitetura de alto nível de provisionamento de mecanismo para se conectar a uma única floresta, embora várias florestas tenham suporte. Essa arquitetura mostra como os vários componentes interagem uns com os outros.

O mecanismo de provisionamento se conecta a cada floresta do Active Directory e ao Microsoft Entra ID. O processo de ler informações de cada diretório é chamado de importação. Exportação se refere à atualização dos diretórios do mecanismo de provisionamento. A sincronização avalia as regras de como os objetos fluirão dentro do mecanismo de provisionamento.

O Microsoft Entra Connect usa as seguintes áreas de preparação, regras e processos para permitir a sincronização do Active Directory para o Microsoft Entra ID:

• Espaço do conector (CS) - objetos de cada diretório conectado (CD), os diretórios reais são testados aqui pela primeira vez antes que possam ser processados pelo mecanismo de provisionamento. O Microsoft Entra ID tem seu próprio CS e cada floresta à qual você se conectar terá seu próprio CS.
• Metaverso (MV) - os objetos que precisam ser sincronizados são criados aqui com base nas regras de sincronização. Objetos devem existir na MV antes que possam preencher os objetos e atributos para os outros diretórios conectados. Há apenas uma MV.
• Regras de sincronização - decidem quais objetos serão criados (projetados) ou conectados (associados) para objetos no MV. As regras de sincronização também decidem quais valores de atributo serão copiados ou transformados de e para os diretórios.
• Perfis de execução - agrupa as etapas do processo de copiar objetos e valores de atributo de acordo com as regras de sincronização entre as áreas de preparo e os diretórios conectados.

Sincronização na nuvem do Microsoft Entra

A sincronização na nuvem do Microsoft Entra Connect foi projetada para atingir as metas de identidade híbrida para a sincronização de usuários, grupos e contatos com o Microsoft Entra ID. A sincronização é realizada usando o agente de provisionamento de nuvem em vez do aplicativo Microsoft Entra Connect. Ele pode ser utilizado juntamente com a sincronização do Microsoft Entra Connect e fornece os seguintes benefícios:

• Suporte para sincronização com um locatário do Microsoft Entra a partir de um ambiente de floresta do Active Directory desconectado de várias florestas: Os cenários comuns incluem fusão e aquisição. As florestas do AD da empresa adquirida foram isoladas das florestas do AD da empresa-mãe. As empresas que historicamente tiveram várias florestas do AD.
• Instalação simplificada com agentes de provisionamento leves: os agentes atuam como uma ponte do AD para o Microsoft Entra ID, com todas as configurações de sincronização gerenciadas na nuvem.
• Vários agentes de provisionamento podem ser utilizados para simplificar implantações de alta disponibilidade, o que é crítico para organizações que dependem da sincronização de hash de senha do AD para o Microsoft Entra ID.
• Suporte para grandes grupos com até 50 mil membros. Recomendamos usar apenas o filtro de escopo UO na sincronização de grupos grandes.

Com a sincronização na nuvem do Microsoft Entra Connect, o provisionamento do AD para o Microsoft Entra ID é orquestrado no Microsoft Online Services. Uma organização só precisa implantar, no local ou no ambiente hospedados por IaaS, um agente leve que atue como uma ponte entre o Microsoft Entra e o AD. A configuração do provisionamento é armazenada e gerenciada como parte do serviço. Lembre-se de que a sincronização é executada a cada dois minutos.