Compartilhar via

Pré-requisitos para a Sincronização na Nuvem do Microsoft Entra

  • Artigo

Este artigo fornece diretrizes sobre o uso do Microsoft Entra Cloud Sync como solução de identidade.

Requisitos do agente de provisionamento de nuvem

Você precisa dos seguintes itens para usar a Sincronização na Nuvem do Microsoft Entra:

  • Credenciais de Administrador de Domínio ou Administrador Corporativo para criar a gMSA (conta de serviço gerenciado de grupo) da sincronização na nuvem do Microsoft Entra Connect para executar o serviço do agente.
  • Uma conta de Administrador de Identidade Híbrida para seu locatário do Microsoft Entra que não seja um usuário convidado.
  • Um servidor local para o agente de provisionamento com o Windows 2016 ou posterior. Esse servidor deve ser de camada 0 e baseado no modelo de camada administrativa do Active Directory. Há suporte para a instalação do agente em um controlador de domínio. Para obter mais informações, consulte Proteger o servidor do agente de provisionamento do Microsoft Entra
    • Necessário para o atributo de esquema do AD – msDS-ExternalDirectoryObjectId
  • Alta disponibilidade refere-se à capacidade da Sincronização na Nuvem do Microsoft Entra de operar continuamente sem falhas por um longo período. Ao ter vários agentes ativos instalados e em execução, a Sincronização na Nuvem do Microsoft Entra pode continuar funcionando mesmo que um agente falhe. A Microsoft recomenda ter três agentes ativos instalados para garantir a alta disponibilidade.
  • Configurações de firewall local.

Proteger o servidor do agente de provisionamento do Microsoft Entra

Recomendamos que você proteja seu servidor do agente de provisionamento do Microsoft Entra para diminuir a superfície de ataque de segurança desse componente crítico de seu ambiente de TI. Seguir essas recomendações ajudará a reduzir alguns riscos de segurança para sua organização.

  • É recomendável proteger o servidor do agente de provisionamento do Microsoft Entra como um ativo de Plano de Controle (anteriormente camada 0) seguindo as diretrizes fornecidas no modelo de camada administrativa do Acesso Privilegiado Seguro e do Active Directory.
  • Restrinja o acesso administrativo ao servidor do agente de provisionamento do Microsoft Entra somente a administradores de domínio ou a outros grupos de segurança rigidamente controlados.
  • Crie uma conta dedicada para todos os funcionários com acesso privilegiado. Os administradores não devem navegar na Web, verificar emails nem realizar tarefas de produtividade cotidianas com contas altamente privilegiadas.
  • Siga as orientações fornecidas em Protegendo o acesso privilegiado.
  • Negar o uso da autenticação NTLM com o servidor do agente de provisionamento do Microsoft Entra. Aqui estão algumas maneiras de fazer isso: Restringir o NTLM no servidor do agente de provisionamento do Microsoft Entra e Restringir o NTLM em um domínio
  • Verifique se cada computador tem uma senha de administrador local exclusiva. Para obter mais informações, confira LAPS do Windows (Solução de Senha de Administrador Local), que pode configurar senhas aleatórias exclusivas em cada estação de trabalho e servidor e armazená-las no Active Directory protegidas por uma ACL. Somente usuários autorizados qualificados podem ler ou solicitar a redefinição dessas senhas de conta de administrador local. Diretrizes adicionais para operar um ambiente com LAPS do Windows e PAWs (estações de trabalho com acesso privilegiado) podem ser encontradas em Padrões operacionais com base no princípio de código-fonte limpo.
  • Implemente estações de trabalho de acesso privilegiado dedicadas para todos os funcionários com acesso privilegiado aos sistemas de informações da sua organização.
  • Siga estas diretrizes adicionais para reduzir a superfície de ataque do seu ambiente do Active Directory.
  • Siga Monitorar alterações na configuração de federação para configurar alertas para monitorar alterações na relação de confiança estabelecida entre o Idp e o Microsoft Entra ID.
  • Habilite a MFA (Autenticação Multifator) para todos os usuários que têm acesso privilegiado no Microsoft Entra ID ou no AD. Um problema de segurança com o uso do agente de provisionamento do Microsoft Entra é que, se um invasor puder obter controle sobre o servidor do agente de provisionamento do Microsoft Entra, ele poderá manipular usuários no Microsoft Entra ID. Para impedir que um invasor use essas funcionalidades para assumir o controle das contas do Microsoft Entra, a MFA oferece proteções para que, mesmo que um invasor consiga, por exemplo, redefinir a senha de um usuário usando o agente de provisionamento do Microsoft Entra, ele ainda não possa ignorar o segundo fator.

Group Managed Service Accounts

Uma Conta de Serviço Gerenciada de grupo é uma conta de domínio gerenciada que fornece gerenciamento automático de senhas, gerenciamento simplificado de SPN (nome da entidade de serviço) e a capacidade de delegar o gerenciamento para outros administradores, além de estender essa funcionalidade para vários servidores. A Sincronização na Nuvem do Microsoft Entra dá suporte e usa uma gMSA para executar o agente. Você será solicitado a fornecer credenciais administrativas durante a configuração, a fim de criar essa conta. A conta aparece como domain\provAgentgMSA$. Para obter mais informações sobre uma gMSA, confira Contas de Serviço Gerenciado de grupo.

Pré-requisitos da gMSA

  1. O esquema do Active Directory na floresta de domínio da gMSA precisa ser atualizado para o Windows Server 2012 ou posterior.
  2. Módulos das Ferramentas de Administração de Servidor Remoto do PowerShell em um controlador de domínio.
  3. Pelo menos um controlador de domínio no domínio deve estar executando o Windows Server 2012 ou posterior.
  4. Um servidor conectado ao domínio em que o agente está sendo instalado precisa ser o Windows Server 2016 ou posterior.

Conta gMSA personalizada

Se estiver criando uma conta gMSA personalizada, é necessário garantir que a conta tenha as seguintes permissões.

Tipo Nome Acesso Aplica-se A
Allow Conta gMSA Leia todas as propriedades Objetos de dispositivo descendente
Allow Conta gMSA Leia todas as propriedades Objetos descendentes de InetOrgPerson
Allow Conta gMSA Leia todas as propriedades Objetos de computador descendentes
Allow Conta gMSA Leia todas as propriedades Objetos descendentes de foreignSecurityPrincipal
Allow Conta gMSA Controle total Objetos de grupo descendentes
Allow Conta gMSA Leia todas as propriedades Objetos de usuário descendentes
Allow Conta gMSA Leia todas as propriedades Objetos de contato descendentes
Allow Conta gMSA Criar/excluir objetos de usuário Este objeto e todos os objetos descendentes

Para ver as etapas sobre como atualizar um agente existente para usar uma conta gMSA, confira Contas de Serviço Gerenciadas de grupo.

Para obter mais informações sobre como preparar o Active Directory da Conta de Serviço Gerenciado de grupo, confira Visão geral das Contas de Serviço Gerenciado de grupo e Contas de serviço gerenciado de grupo com sincronização na nuvem.

No centro de administração do Microsoft Entra

  1. Crie uma conta de Administrador de Identidade Híbrida apenas na nuvem no seu locatário do Microsoft Entra. Dessa forma, você pode gerenciar a configuração do seu locatário se seus serviços locais falhem ou ficarem indisponíveis. Saiba como adicionar uma conta de Administrador de Identidade Híbrida apenas na nuvem. Finalizar essa etapa é essencial para garantir que você não seja bloqueado de seu locatário.
  2. Adicione um ou mais nomes de domínio personalizados ao locatário do Microsoft Entra. Os usuários podem entrar com um desses nomes de domínio.

No seu diretório no Active Directory

Execute a ferramenta IdFix para preparar os atributos de diretório para sincronização.

Em seu ambiente local

  1. Identifique um servidor de host conectado ao domínio que executa o Windows Server 2016 ou superior com o mínimo de 4 GB de RAM e o runtime do .NET 4.7.1+.
  2. A política de execução do PowerShell no servidor local deve ser definida como Undefined ou RemoteSigned.
  3. Se houver um firewall entre seus servidores e o Microsoft Entra ID, consulte Requisitos de firewall e proxy.

Observação

Não há suporte para a instalação do agente de provisionamento de nuvem no Windows Server Core.

Provisionar o Microsoft Entra ID no Active Directory - Pré-requisitos

Os seguintes pré-requisitos são necessários para implementar grupos de provisionamento no Active Directory.

Requisitos de licença

O uso desse recurso requer licenças P1 do Microsoft Entra ID. Para encontrar a licença certa para seus requisitos, confira Comparar recursos do Microsoft Entra ID com disponibilidade geral.

Requisitos gerais

  • Conta do Microsoft Entra com pelo menos uma função de Administrador de Identidade Híbrida.
  • Ambiente local do Active Directory Domain Services com o sistema operacional Windows Server 2016 ou posterior.
    • Necessário para o atributo de esquema do AD – msDS-ExternalDirectoryObjectId
  • Agente de provisionamento com a versão de build 1.1.1370.0 ou posterior.

Observação

As permissões para a conta de serviço são atribuídas somente durante a instalação limpa. Caso você esteja atualizando da versão anterior, as permissões precisam ser atribuídas manualmente usando o cmdlet do PowerShell:

$credential = Get-Credential  

  Set-AADCloudSyncPermissions -PermissionType UserGroupCreateDelete -TargetDomain "FQDN of domain" -EACredential $credential

Se as permissões forem definidas manualmente, você precisará garantir a definição todas as propriedades de Leitura, Gravação, Criação e Exclusão para todos os Grupos e objetos de usuário descendentes.

Essas permissões não são aplicadas a objetos AdminSDHolder por padrão cmdlets do PowerShell do agente de provisionamento gMSA do Microsoft Entra

  • O agente de provisionamento precisa conseguir se comunicar com um ou mais controladores de domínio nas portas TCP/389 (LDAP) e TCP/3268 (Catálogo Global).
    • Necessário para pesquisa de catálogo global para filtrar referências de subscrição inválidas
  • Sincronização do Microsoft Entra Connect com versão de build 2.2.8.0 ou posterior
    • Necessário para dar suporte à subscrição de usuário local sincronizada usando a Sincronização do Microsoft Entra Connect
    • Necessário para sincronizar o AD:user:objectGUID ao AAD:user:onPremisesObjectIdentifier

Grupos com suporte e limites de escala

As seguintes ações são compatíveis:

  • Há suporte apenas para os Grupos de segurança criados na nuvem
  • Esses grupos podem ter uma associação atribuída ou dinâmica.
  • Esses grupos só podem conter usuários sincronizados no local e/ou grupos de segurança adicionais criados na nuvem.
  • As contas de usuário locais que são sincronizadas e são membros desse grupo de segurança criado na nuvem podem ser do mesmo domínio ou entre domínios, mas todas devem ser da mesma floresta.
  • O write-back desses grupos é feito com o escopo de grupos do AD universal. Seu ambiente local deve dar suporte ao escopo do grupo universal.
  • Não há suporte para grupos com mais de 50.000 membros.
  • Não há suporte para locatários com mais de 150.000 objetos. Logo, se um locatário tiver qualquer combinação de usuários e grupos que exceda 150 mil objetos, não haverá suporte para o locatário.
  • Cada grupo filho aninhado de forma direta conta como um membro no grupo de referência
  • Não há suporte para a reconciliação de grupos entre o Microsoft Entra ID e o Active Directory se o grupo for atualizado manualmente no Active Directory.

Informações adicionais

A seguir, informações adicionais sobre o provisionamento de grupos no Active Directory.

  • Os grupos provisionados no AD usando a sincronização na nuvem só podem conter usuários sincronizados locais e/ou grupos de segurança adicionais criados na nuvem.
  • Esses usuários devem ter o atributo onPremisesObjectIdentifier definido em suas contas.
  • O atributo onPremisesObjectIdentifier deve corresponder a um objectGUID correspondente no ambiente AD de destino.
  • Um atributo objectGUID de usuários locais para um atributo onPremisesObjectIdentifier de usuários na nuvem pode ser sincronizado usando a Sincronização na nuvem do Microsoft Entra (1.1.1370.0) ou a Sincronização do Microsoft Entra Connect (2.2.8.0)
  • Se você estiver usando a Sincronização do Microsoft Entra Connect (2.2.8.0) para sincronizar usuários em vez da Sincronização na nuvem do Microsoft Entra e quiser usar o Provisionamento para o AD, deverá usar a versão 2.2.8.0 ou posterior.
  • Há suporte somente para locatários regulares do Microsoft Entra ID para o provisionamento do Microsoft Entra ID para o Active Directory. Não há suporte para locatários como B2C.
  • O trabalho de provisionamento de grupos está agendado para ser executado a cada 20 minutos.

Mais requisitos

Requisitos de TLS

Observação

O protocolo TLS fornece comunicações seguras. A alteração das configurações de TLS afeta toda a floresta. Para obter mais informações, consulte Atualizar para habilitar TLS 1.1 e TLS 1.2 como protocolos seguros padrão no WinHTTP no Windows.

O Windows Server que hospeda o agente de provisionamento de nuvem do Microsoft Entra Connect precisa ter o TLS 1.2 habilitado antes da instalação.

Para habilitar o TLS 1.2, siga estas etapas.

  1. Defina as seguintes chaves do Registro copiando o conteúdo em um arquivo .reg e execute o arquivo (clique com o botão direito do mouse e escolha Mesclar):

    Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001

  2. Reinicie o servidor.

Requisitos de firewall e proxy

Se houver um firewall entre os servidores e o Microsoft Entra ID, configure os seguintes itens:

  • Verifique se os agentes podem fazer solicitações de saída ao Microsoft Entra ID nas seguintes portas:

    Número da porta Descrição
    80 Baixa as listas de CRLs (certificados revogados) enquanto valida o certificado TLS/SSL.
    443 Lida com toda a comunicação de saída com o serviço.
    8080 (opcional) Agentes relatarão seu status a cada 10 minutos através da porta 8080, se a porta 443 não estiver disponível. Esse status é exibido no centro de administração do Microsoft Entra.

  • Se o firewall impõe as regras de acordo com os usuários originadores, abra essas portas para o tráfego proveniente dos serviços Windows que são executados como um serviço de rede.

  • Verifique se o proxy oferece suporte a pelo menos o protocolo HTTP 1.1 e se a codificação em partes está habilitada.

  • Se o firewall ou proxy permitir a especificação de sufixos seguros, adicione conexões:

URL Descrição
*.msappproxy.net
*.servicebus.windows.net		 O agente usa essas URLs para se comunicar com o serviço de nuvem do Microsoft Entra.
*.microsoftonline.com
*.microsoft.com
*.msappproxy.com
*.windowsazure.com		 O agente usa essas URLs para se comunicar com o serviço de nuvem do Microsoft Entra.
mscrl.microsoft.com:80
crl.microsoft.com:80
ocsp.msocsp.com:80
www.microsoft.com:80		 O agente usa essas URLs para verificar certificados.
login.windows.net O agente usa essas URLs durante o processo de registro.

Requisito de NTLM

Você não deve habilitar o NTLM no Windows Server que está executando o agente de provisionamento do Microsoft Entra e, se estiver habilitado, deve certificar-se de desabilitá-lo.

Limitações conhecidas

Veja a seguir as limitações conhecidas:

Sincronização de delta

  • A filtragem de escopo de grupo para sincronização delta não dá suporte para mais de 50.000 membros.
  • Quando você exclui um grupo que é usado como parte de um filtro de escopo de grupo, os usuários membros do grupo não são excluídos.
  • Quando você renomeia a UO ou o grupo que está no escopo, a sincronização delta não remove os usuários.

Logs de provisionamento

  • Os registros de provisionamento não diferenciam claramente as operações de criação e atualização. Você pode ver uma operação de criação para uma atualização e uma operação de atualização para uma criação.

Renomeação de grupo ou renomeação de UO

  • Se você renomear um grupo ou uma UO no AD que esteja no escopo de uma determinada configuração, o trabalho de sincronização na nuvem não conseguirá reconhecer a alteração do nome no AD. O trabalho não entrará em quarentena e permanecerá íntegro.

Filtro de escopo

Quando usar o filtro de escopo UO

  • A configuração de escopo tem uma limitação de 4MB de comprimento de caracteres. Em um ambiente testado padrão, isso se traduz em aproximadamente 50 UOs (unidades organizacionais) ou grupos de segurança separados, incluindo os metadados necessários, para uma determinada configuração.

  • As UOs aninhadas têm suporte (ou seja, você pode sincronizar uma UO que tenha 130 UOs aninhadas, mas não pode sincronizar 60 UOs separadas na mesma configuração).

Sincronização de hash de senha

  • Não há suporte para o uso de sincronização de hash de senha com InetOrgPerson.

Próximas etapas