Partilhar via

Pré-requisitos para o Microsoft Entra Cloud Sync

  • Artigo

Este artigo fornece orientação sobre como usar o Microsoft Entra Cloud Sync como sua solução de identidade.

Requisitos do agente de provisionamento na nuvem

Você precisa do seguinte para usar o Microsoft Entra Cloud Sync:

  • Credenciais de Administrador de Domínio ou Administrador da Empresa para criar a conta gMSA (conta de serviço de grupo gerido) de 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 Windows 2016 ou posterior. Este servidor deve ser um servidor de camada 0 baseado no modelo de camada administrativa do Ative Directory . Há suporte para a instalação do agente em um controlador de domínio. Para obter mais informações, consulte Reforçar o servidor do agente de provisionamento do Microsoft Entra
    • Necessário para o atributo Esquema do AD - msDS-ExternalDirectoryObjectId
  • Alta disponibilidade refere-se à capacidade do Microsoft Entra Cloud Sync de operar continuamente sem falhas por um longo tempo. Ao ter vários agentes ativos instalados e em execução, o Microsoft Entra Cloud Sync pode continuar a funcionar mesmo se um agente falhar. A Microsoft recomenda ter 3 agentes ativos instalados para alta disponibilidade.
  • Configurações de firewall local.

Proteja seu servidor de agente de provisionamento do Microsoft Entra

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

  • Recomendamos proteger o servidor do agente de provisionamento do Microsoft Entra como um ativo do Plano de Controle (anteriormente Tier 0) seguindo as orientações fornecidas no Secure Privileged Access e modelo de camada administrativa do Ative Directory.
  • Restrinja o acesso administrativo ao servidor do agente de provisionamento do Microsoft Entra apenas a administradores de domínio ou outros grupos de segurança rigorosamente controlados.
  • Crie uma conta dedicada para todo o pessoal com acesso privilegiado. Os administradores não devem navegar na Web, verificar seus e-mails e fazer tarefas diárias de produtividade 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 NTLM no agente de provisionamento do Microsoft Entra Server e Restringir NTLM num domínio
  • Certifique-se de que cada máquina tenha uma senha de administrador local exclusiva. Para obter mais informações, consulte Solução de Senha de Administrador Local (Windows LAPS), que pode configurar senhas aleatórias únicas em cada estação de trabalho e servidor, armazenando-as 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. Orientações adicionais para operar um ambiente com LAPS do Windows e estações de trabalho de acesso privilegiado (PAWs) podem ser encontradas em Padrões operacionais baseados no princípio de fonte limpa.
  • Implemente estações de trabalho dedicadas de acesso privilegiado para todo o pessoal com acesso privilegiado aos sistemas de informação da sua organização.
  • Siga estas diretrizes adicionais para reduzir a superfície de ataque do seu ambiente do Active Directory.
  • Siga o Monitorizar alterações na configuração de federação para configurar alertas que monitorizem alterações na confiança estabelecida entre o seu IdP e o Microsoft Entra ID.
  • Habilite a autenticação multifator (MFA) 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 os usuários na ID do Microsoft Entra. Para impedir que um invasor use esses recursos para assumir contas do Microsoft Entra, o MFA oferece proteções. Por exemplo, mesmo que um invasor consiga redefinir a senha de um usuário usando o agente de provisionamento do Microsoft Entra, ele ainda não poderá ignorar o segundo fator.

Contas de Serviço Gerenciado de Grupo

Uma Conta de Serviço Gerenciado de grupo é uma conta de domínio gerenciada que fornece gerenciamento automático de senhas e gerenciamento simplificado de SPN (nome principal de serviço). Ele também oferece a capacidade de delegar o gerenciamento a outros administradores e estende essa funcionalidade a vários servidores. O Microsoft Entra Cloud Sync suporta e usa um gMSA para executar o agente. Ser-lhe-ão solicitadas credenciais administrativas durante a configuração para criar esta conta. A conta aparece como domain\provAgentgMSA$. Para obter mais informações sobre um gMSA, consulte grupo Contas de Serviço Gerenciado.

Pré-requisitos para gMSA

  1. O esquema do Ative Directory na floresta do domínio gMSA precisa ser atualizado para o Windows Server 2012 ou posterior.
  2. módulos RSAT 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 ingressado no domínio onde o agente está sendo instalado precisa ser o Windows Server 2016 ou posterior.

Conta gMSA personalizada

Se você estiver criando uma conta gMSA personalizada, precisará garantir que a conta tenha as seguintes permissões.

Tipo Nome Acesso Aplica-se a
Permitir Conta gMSA Ler todos os imóveis Objetos de dispositivo descendentes
Permitir Conta gMSA Ler todos os imóveis Descendentes de objetos InetOrgPerson
Permitir Conta gMSA Ler todos os imóveis Objetos de computador descendentes
Permitir Conta gMSA Ler todos os imóveis Objetos descendentes foreignSecurityPrincipal
Permitir Conta gMSA Controlo total Objetos do Grupo Descendente
Permitir Conta gMSA Ler todos os imóveis Objetos de usuário descendente
Permitir Conta gMSA Ler todos os imóveis Objetos de contato descendentes
Permitir Conta gMSA Criar/excluir objetos de usuário Este objeto e todos os objetos descendentes

Para obter etapas sobre como atualizar um agente existente para usar uma conta gMSA, consulte grupo Contas de Serviço Gerenciado.

Para mais informações sobre como preparar o Active Directory para a Conta de Serviço Gerenciado de Grupo, consulte 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 somente na nuvem em seu locatário do Microsoft Entra. Dessa forma, você pode gerenciar a configuração do locatário se os serviços locais falharem ou ficarem indisponíveis. Saiba como adicionar uma conta de Administrador de Identidade Híbrida somente na nuvem. Concluir esta etapa é fundamental para garantir que você não fique bloqueado fora do seu inquilino.
  2. Adicione um ou mais nomes de domínio personalizados à sua instância do Microsoft Entra. Os seus utilizadores podem iniciar sessão com um destes nomes de domínio.

No seu diretório no Active Directory

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

Em seu ambiente local

  1. Identifique um servidor host associado a um domínio que executa o Windows Server 2016 ou superior com um mínimo de 4 GB de RAM e tempo de execução 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 ID do Microsoft Entra no Active Directory - Pré-requisitos

Os pré-requisitos a seguir são necessários para implementar grupos de provisionamento no Ative Directory.

Requisitos de licença

O uso desse recurso requer licenças do Microsoft Entra ID P1. Para encontrar a licença certa para os seus requisitos, consulte Comparação de recursos geralmente disponíveis do Microsoft Entra ID.

Requisitos gerais

  • Conta do Microsoft Entra com pelo menos uma função de Administrador de Identidade Híbrida .
  • Ambiente local dos Serviços de Domínio Ative Directory com sistema operacional Windows Server 2016 ou posterior.
    • Necessário para o atributo do esquema do AD - msDS-ExternalDirectoryObjectId
  • Agente de provisionamento com versão de compilação 1.1.1370.0 ou posterior.

Observação

As permissões para a conta de serviço são atribuídas exclusivamente durante uma 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, terá de garantir Ler, Gravar, Criar e Eliminar todas as propriedades para todos os grupos descendentes e objetos de utilizador.

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

  • O agente de provisionamento deve ser capaz de 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 associação inválidas
  • Microsoft Entra Connect Sync com a versão de compilação 2.2.8.0 ou posterior
    • Necessário para suportar a associação de usuário local sincronizada usando o Microsoft Entra Connect Sync
    • Necessário para sincronizar AD:user:objectGUID com AAD:user:onPremisesObjectIdentifier

Grupos suportados e limites de escala

O seguinte é suportado:

  • Apenas os grupos de segurança criados na nuvem são suportados
  • Esses grupos podem ter grupos de associação atribuídos ou dinâmicos.
  • 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 sincronizadas e que 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.
  • Esses grupos são escritos de volta com o escopo universal dos grupos AD de . Seu ambiente local deve oferecer suporte ao escopo de 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. Ou seja, se um locatário tiver qualquer combinação de usuários e grupos que exceda 150K objetos, o locatário não será suportado.
  • Cada grupo filho directo aninhado conta como um membro no grupo de referência
  • A reconciliação de grupos entre o Microsoft Entra ID e o Ative Directory não é suportada se o grupo for atualizado manualmente no Ative Directory.

Informações adicionais

A seguir estão informações adicionais sobre o provisionamento de grupos para o Ative Directory.

  • Os grupos provisionados para o AD usando a sincronização na nuvem só podem conter usuários sincronizados no local e/ou grupos de segurança adicionais criados na nuvem.
  • Esses usuários devem ter o atributo onPremisesObjectIdentifier definido em sua conta.
  • O 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 de nuvem pode ser sincronizado usando o Microsoft Entra Cloud Sync (1.1.1370.0) ou o Microsoft Entra Connect Sync (2.2.8.0)
  • Se estiveres a usar o Microsoft Entra Connect Sync (2.2.8.0) para sincronizar utilizadores, em vez do Microsoft Entra Cloud Sync, e quiseres utilizar o Provisionamento no AD, a versão deve ser 2.2.8.0 ou posterior.
  • Apenas locatários regulares do Microsoft Entra ID são suportados para o provisionamento do Microsoft Entra ID para o Active Directory. Locatários como B2C não são suportados.
  • O trabalho de provisionamento de grupo está agendado para ser executado a cada 20 minutos.

Mais requisitos

Requisitos TLS

Observação

Transport Layer Security (TLS) é um protocolo que fornece comunicações seguras. A alteração das configurações de TLS afeta toda a floresta. Para obter mais informações, consulte Update para habilitar o TLS 1.1 e o TLS 1.2 como protocolos seguros padrão no WinHTTP no Windows.

O servidor Windows que hospeda o agente de provisionamento de nuvem do Microsoft Entra Connect deve ter o TLS 1.2 habilitado antes de instalá-lo.

Para ativar o TLS 1.2, siga estes passos.

  1. Defina as seguintes chaves do Registro copiando o conteúdo em um arquivo .reg e, em seguida, execute o arquivo (selecione com o botão direito 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 seus servidores e o Microsoft Entra ID, configure os seguintes itens:

  • Certifique-se de que os agentes possam fazer solicitações de de saída para o Microsoft Entra ID nas seguintes portas:

    Número da porta Descrição
    80 Baixa as listas de revogação de certificados (CRLs) enquanto valida o certificado TLS/SSL.
    443 Lida com toda a comunicação de saída com o serviço.
    8080 (opcional) Os agentes relatam seu status a cada 10 minutos pela 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 impor regras de acordo com os usuários de origem, abra essas portas para o tráfego de serviços do Windows que são executados como um serviço de rede.

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

  • Se o firewall ou proxy permitir que você especifique 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 Microsoft Entra.
*.microsoftonline.com
*.microsoft.com
*.msappproxy.com
*.windowsazure.com		 O agente usa essas URLs para se comunicar com o serviço de nuvem 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 NTLM

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

Limitações conhecidas

As seguintes limitações são conhecidas:

Sincronização Delta

  • A filtragem de escopo de grupo para sincronização delta não suporta mais de 50.000 membros.
  • Quando você exclui um grupo usado como parte de um filtro de escopo de grupo, os usuários que são 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 logs de provisionamento não diferenciam claramente entre operações de criação e atualização. Poderá 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 OU

  • Se você renomear um grupo ou UO no AD que esteja no escopo de uma determinada configuração, o trabalho de sincronização na nuvem não poderá reconhecer a alteração de nome no AD. O trabalho não entra em quarentena e mantém-se em bom estado.

Filtro de escopo

Ao usar o filtro de escopo da UO

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

  • Há suporte para UOs aninhadas (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 da sincronização de hash de senha com InetOrgPerson.

Próximos passos