Pré-requisitos para Azure AD Conecte a sincronização da nuvem

Este artigo fornece orientações sobre como escolher e utilizar o Azure Ative Directory (Azure AD) Conecte a sincronização de nuvem como solução de identidade.

Requisitos de agente de provisionamento em nuvem

Precisa do seguinte para utilizar Azure AD Sync de nuvem de ligação:

  • Credenciais de Administrador de Domínio ou Administrador Empresarial para criar o Azure AD Connect Cloud Sync gMSA (conta de serviço gerido do grupo) para executar o serviço de agente.
  • Um administrador de identidade híbrido conta para o seu inquilino Azure AD que não é um utilizador convidado.
  • Um servidor no local para o agente de provisionamento com o Windows 2016 ou mais tarde. Este servidor deve ser um servidor de nível 0 baseado no modelo de nível administrativo ative diretório. A instalação do agente num controlador de domínio é suportada.
  • A alta disponibilidade refere-se à capacidade da sincronização de nuvem Azure AD Ligar a sincronização de nuvem para funcionar continuamente sem falhas durante muito tempo. Ao ter vários agentes ativos instalados e em execução, Azure AD sync de nuvem Connect pode continuar a funcionar mesmo que um agente falhe. A Microsoft recomenda ter 3 agentes ativos instalados para uma elevada disponibilidade.
  • Configurações de firewall no local.

Contas de Serviço Geridas de Grupo

Um grupo Managed Service Account é uma conta de domínio gerida que fornece gestão automática de passwords, gestão de nome principal de serviço simplificado (SPN), a capacidade de delegar a gestão a outros administradores, e também estende esta funcionalidade sobre vários servidores. Azure AD Connect Cloud Sync suporta e utiliza um gMSA para executar o agente. Ser-lhe-á solicitado credenciais administrativas durante a configuração, de forma a criar esta conta. A conta aparecerá como (domínio\provAgentgMSA$). Para obter mais informações sobre um gMSA, consulte contas de serviço geridas pelo grupo

Pré-requisitos para a GMSA:

  1. O esquema do Diretório Ativo na floresta do domínio gMSA tem de ser atualizado para Windows Server 2012 ou posteriormente.
  2. Módulos PowerShell RSAT num controlador de domínio
  3. Pelo menos um controlador de domínio no domínio deve estar a funcionar Windows Server 2012 ou posteriormente.
  4. Um servidor de domínio associado onde o agente está a ser instalado precisa de ser Windows Server 2016 ou mais tarde.

Conta gMSA personalizada

Se estiver a criar uma conta gMSA personalizada, tem de garantir que a conta tem as seguintes permissões.

Tipo Name Access Aplica-se A
Permitir conta gMSA Leia todas as propriedades Objetos de dispositivo descendente
Permitir conta gMSA Leia todas as propriedades Objetos inetOrgperson descendentes
Permitir conta gMSA Leia todas as propriedades Objetos de computador descendentes
Permitir conta gMSA Leia todas as propriedades Objetos de Segurança Estrangeira Descendentes
Permitir conta gMSA Controlo total Objetos do grupo descendente
Permitir conta gMSA Leia todas as propriedades Objetos de utilizador descendentes
Permitir conta gMSA Leia todas as propriedades Objetos de contacto descendentes
Permitir conta gMSA Criar/eliminar objetos de utilizador Este objeto e todos os objetos descendentes

Para etapas sobre como atualizar um agente existente para utilizar uma conta gMSA consulte contas de serviço geridas pelo grupo.

Criar conta gMSA com PowerShell

Pode utilizar o seguinte script PowerShell para criar uma conta gMSA personalizada. Em seguida, pode utilizar os cmdlets gMSA de sincronização de nuvem para aplicar mais permissões granulares.

# Filename:    1_SetupgMSA.ps1
# Description: Creates and installs a custom gMSA account for use with Azure AD Connect cloud sync.
#
# DISCLAIMER:
# Copyright (c) Microsoft Corporation. All rights reserved. This 
# script is made available to you without any express, implied or 
# statutory warranty, not even the implied warranty of 
# merchantability or fitness for a particular purpose, or the 
# warranty of title or non-infringement. The entire risk of the 
# use or the results from the use of this script remains with you.
#
#
#
#
# Declare variables
$Name = 'provAPP1gMSA'
$Description = "Azure AD Cloud Sync service account for APP1 server"
$Server = "APP1.contoso.com"
$Principal = Get-ADGroup 'Domain Computers'

# Create service account in Active Directory
New-ADServiceAccount -Name $Name `
-Description $Description `
-DNSHostName $Server `
-ManagedPasswordIntervalInDays 30 `
-PrincipalsAllowedToRetrieveManagedPassword $Principal `
-Enabled $True `
-PassThru

# Install the new service account on Azure AD Cloud Sync server
Install-ADServiceAccount -Identity $Name

Para obter informações adicionais sobre os cmdlets acima, consulte Introdução com contas de serviço geridas pelo grupo.

No centro de administração do Azure Ative Directory

  1. Crie uma conta de administrador de identidade híbrida apenas em nuvem no seu inquilino Azure AD. Desta forma, pode gerir a configuração do seu inquilino se os seus serviços no local falharem ou ficarem indisponíveis. Saiba como adicionar uma conta de administrador de identidade híbrida apenas em nuvem. Terminar este passo é fundamental para garantir que não fique trancado fora do seu inquilino.
  2. Adicione um ou mais nomes de domínio personalizados ao seu inquilino Azure AD. Os seus utilizadores podem iniciar sôms com um destes nomes de domínio.

No seu diretório em Diretório Ativo

Executar a ferramenta IdFix para preparar os atributos do diretório para sincronização.

No seu ambiente no local

  1. Identifique um servidor anfitrião ligado a domínios que Windows Server 2016 ou superior com um mínimo de 4-GB de RAM e .NET 4.7.1+ tempo de execução.

  2. A política de execução PowerShell no servidor local deve ser definida para Undefined ou RemoteSigned.

  3. Se houver uma firewall entre os seus servidores e Azure AD, configuure ver firewall e requisitos de procuração abaixo.

Nota

A instalação do agente de provisionamento em nuvem no Windows Server Core não é suportada.

Requisitos adicionais

Requisitos TLS

Nota

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

O servidor Windows que acolhe o Azure AD Agente de provisionamento de nuvem Connect deve ter o TLS 1.2 ativado antes de o instalar.

Para ativar o TLS 1.2, siga estes passos.

  1. Definir as seguintes chaves de registo:

    [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 uma firewall entre os seus servidores e Azure AD, configuure os seguintes itens:

  • Certifique-se de que os agentes podem fazer pedidos de saída para Azure AD sobre as seguintes portas:

    Número da porta Como é utilizado
    80 Descarrega as listas de revogação do certificado (CRLs) ao mesmo tempo que valida o certificado TLS/SSL.
    443 Lida com toda a comunicação de saída com o serviço.
    8080 (opcional) Os agentes reportam o seu estado a cada 10 minutos sobre o porto 8080, se a porta 443 não estiver disponível. Este estado é apresentado no portal do Azure Active Directory.
  • Se a firewall impuser regras de acordo com os utilizadores de origem, abra estas portas para o tráfego dos serviços Windows que são executados com um serviço de rede.

  • Se a sua firewall ou proxy permitir que especifique sufixos seguros, adicione ligações:

URL Como é utilizado
*.msappproxy.net
*.servicebus.windows.net
O agente utiliza estes URLs para comunicar com o serviço de nuvem Azure AD.
*.microsoftonline.com
*.microsoft.com
*.msappproxy.com
*.windowsazure.com
O agente utiliza estes URLs para comunicar com o serviço de nuvem Azure AD.
mscrl.microsoft.com:80
crl.microsoft.com:80
ocsp.msocsp.com:80
www.microsoft.com:80
O agente usa estes URLs para verificar os certificados.
login.windows.net
O agente utiliza estes URLs durante o processo de registo.

Requisito NTLM

Não deve ativar o NTLM no Windows Server que está a executar o Azure AD Agente de Provisionamento de Ligação e, se estiver ativado, deve certificar-se de que o desativa.

Limitações conhecidas

São conhecidas as seguintes limitações:

Sincronização Delta

  • A filtragem de âmbito de grupo para a sincronização delta não suporta mais de 50.000 membros.
  • Quando eliminar um grupo que é usado como parte de um filtro de deteção de grupo, os utilizadores que são membros do grupo, não sejam eliminados.
  • Quando mudar o nome do OU ou do grupo que está no âmbito, a Delta Sync não removerá os utilizadores.

Registos de Aprovisionamento

  • Os registos de provisionamento não diferenciam claramente entre as operações de criação e atualização. 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 do grupo ou rebatição de U

  • Se mudar o nome de um grupo ou ou em AD que está no âmbito de uma determinada configuração, o trabalho de sincronização de nuvem não será capaz de reconhecer a mudança de nome em AD. O trabalho não vai para a quarentena e permanecerá saudável.

Filtro de escotagem

Ao usar o filtro de deteção de OU

  • Só é possível sincronizar até 59 OUs ou Grupos de Segurança separados para uma determinada configuração.
  • As OUs aninhadas são suportadas (isto é, pode sincronizar um OU que tem 130 OUs aninhados, mas não é possível sincronizar 60 OUs separadas na mesma configuração).

Sincronização do Hash de Palavras-passe

  • A utilização de sincronização de haxixe de palavra-passe com o InetOrgPerson não é suportada.

Passos seguintes