Requisitos previos de la sincronizar en la nube de Azure AD Connect

En este artículo se proporciona una guía sobre cómo elegir y usar la sincronización en la nube de Azure Active Directory (Azure AD Connect) como solución de identidad.

Requisitos del agente de aprovisionamiento en la nube

Para usar la sincronización en la nube de Azure AD Connect, se necesitan los siguientes elementos:

  • Credenciales de administrador de dominio o administrador de empresa para crear la gMSA (cuenta de servicio administrada de grupo) de sincronización en la nube de Azure AD Connect para ejecutar el servicio del agente.
  • Una cuenta de administrador de identidades híbridas para su inquilino de Azure AD que no sea un usuario invitado.
  • Un servidor local para el agente de aprovisionamiento con Windows 2016 o posterior. Este servidor debe ser un servidor de nivel 0 basado en el modelo de nivel administrativo de Active Directory. Se admite la instalación del agente en un controlador de dominio.
  • La alta disponibilidad hace referencia a la capacidad de Azure AD Connect Cloud Sync de funcionar continuamente sin errores durante mucho tiempo. Al tener varios agentes activos instalados y en ejecución, Azure AD Connect Cloud Sync puede seguir funcionando incluso si se produjera un error en un agente. Microsoft recomienda tener 3 agentes activos instalados para alta disponibilidad.
  • Configuraciones de firewall locales.

Cuentas de servicio administradas de grupo

Una cuenta de servicio administradas de grupo es una cuenta de dominio administrado que proporciona administración automática de contraseñas, administración simplificada del nombre de entidad de seguridad de servicio (SPN), la posibilidad de delegar la administración a otros administradores y, además, amplía esta funcionalidad a varios servidores. La sincronización en la nube de Azure AD Connect admite y usa una gMSA para ejecutar el agente. Para poder crear esta cuenta, se le pedirán credenciales administrativas durante la instalación. La cuenta aparecerá como (domain\provAgentgMSA$). Para obtener más información sobre gMSA, consulte Cuentas de servicio administradas de grupo.

Requisitos previos de gMSA:

  1. El esquema de Active Directory del bosque del dominio de gMSA se tiene que actualizar a Windows Server 2012 o versiones posteriores.
  2. Módulos de RSAT de PowerShell en un controlador de dominio
  3. Al menos un controlador de dominio en el dominio debe ejecutar Windows Server 2012 o versiones posteriores.
  4. Un servidor unido a un dominio en el que se está instalando el agente debe ser Windows Server 2016 o posterior.

Cuenta de gMSA personalizada

Si va a crear una cuenta de gMSA personalizada, debe asegurarse de que la cuenta tenga los permisos siguientes.

Tipo Nombre Acceso Se aplica a
Allow Cuenta de gMSA Lectura de todas las propiedades Objetos del dispositivo descendientes
Allow Cuenta de gMSA Lectura de todas las propiedades Objetos InetOrgPerson descendientes
Allow Cuenta de gMSA Lectura de todas las propiedades Objetos del equipo descendientes
Allow Cuenta de gMSA Lectura de todas las propiedades Objetos foreignSecurityPrincipal descendientes
Allow Cuenta de gMSA Control total Objetos del grupo descendientes
Allow Cuenta de gMSA Lectura de todas las propiedades Objetos del usuario descendientes
Allow Cuenta de gMSA Lectura de todas las propiedades Objetos del contacto descendiente
Allow Cuenta de gMSA Creación o eliminación de objetos de usuario Este objeto y todos los objetos descendientes

Para conocer los pasos sobre cómo actualizar un agente existente para usar una cuenta gMSA, consulte Cuentas de servicio administradas de grupo.

Creación de una cuenta de gMSA con PowerShell

Puede usar el siguiente script de PowerShell para crear una cuenta de gMSA personalizada. A continuación, puede usar los cmdlets de gMSA de sincronización en la nube para aplicar permisos más pormenorizados.

# 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 más información sobre el uso de los cmdlets anteriores, consulte Introducción a las cuentas de servicio administradas de grupo.

En el Centro de administración de Azure Active Directory

  1. Cree una cuenta de administrador de identidades híbridas exclusiva para la nube en su inquilino de Azure AD. De esta manera, puede administrar la configuración del inquilino en caso de que los servicios locales fallen o no estén disponibles. Descubra cómo agregar una cuenta de administrador de identidades híbridas exclusiva para la nube. La finalización de este paso es esencial para garantizar que no queda bloqueado fuera de su inquilino.
  2. Agregue uno o varios nombres de dominio personalizados al inquilino de Azure AD. Los usuarios pueden iniciar sesión con uno de estos nombres de dominio.

En su directorio de Azure Active Directory

Ejecute la herramienta IdFix para preparar los atributos del directorio para la sincronización.

En el entorno local

  1. Identifique un servidor host unido a un dominio en el que se ejecuta Windows Server 2016 o superior con 4 GB de RAM como mínimo y un entorno de ejecución .NET 4.7.1 o posterior.

  2. La directiva de ejecución de PowerShell en el servidor local debe establecerse en Undefined o RemoteSigned.

  3. Si hay un firewall entre sus servidores y Azure AD, consulte Requisitos de firewall y proxy a continuación.

Nota:

La instalación del agente de aprovisionamiento en la nube en Windows Server Core no se admite.

Requisitos adicionales

Requisitos de TLS

Nota:

La seguridad de la capa de transporte (TLS) es un protocolo que proporciona comunicaciones seguras. Si se cambia la configuración de TLS, todo el bosque se verá afectado. Para más información, consulte Actualización para habilitar TLS 1.1 y TLS 1.2 como protocolos seguros predeterminados de WinHTTP en Windows.

El servidor de Windows que hospeda el agente de aprovisionamiento en la nube de Azure AD Connect debe tener TLS 1.2 habilitado antes de instalarlo.

Para habilitar TLS 1.2, siga estos pasos.

  1. Establezca las siguientes claves del Registro:

    [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 el servidor.

Requisitos de firewall y proxy

Si hay un firewall entre los servidores y Azure AD, configure los elementos siguientes:

  • Asegúrese de que los agentes pueden realizar solicitudes de salida a Azure AD a través de los puertos siguientes:

    Número de puerto Cómo se usa
    80 Descarga las listas de revocación de certificados (CRL) al validar el certificado TLS/SSL
    443 Controla toda la comunicación saliente con el servicio.
    8080 (opcional) Si el puerto 443 no está disponible, los agentes notifican su estado cada 10 minutos en el puerto 8080. Este estado se muestra en el portal de Azure AD.
  • Si el firewall fuerza las reglas según los usuarios que las originan, abra estos puertos para el tráfico de servicios de Windows que se ejecutan como un servicio de red.

  • Si su firewall o proxy le permite configurar sufijos seguros, agregue conexiones:

URL Cómo se usa
*.msappproxy.net
*.servicebus.windows.net
El agente utiliza estas direcciones URL para comunicarse con el servicio en la nube de Azure AD.
*.microsoftonline.com
*.microsoft.com
*.msappproxy.com
*.windowsazure.com
El agente utiliza estas direcciones URL para comunicarse con el servicio en la nube de Azure AD.
mscrl.microsoft.com:80
crl.microsoft.com:80
ocsp.msocsp.com:80
www.microsoft.com:80
El agente utiliza estas direcciones URL para verificar los certificados.
login.windows.net
El agente utiliza estas direcciones URL durante el proceso de registro.

Requisito de NTLM

No habilite NTLM en el servidor de Windows Server que ejecuta el agente de aprovisionamiento de Azure Active Directory Connect; si está habilitado, asegúrese de deshabilitarlo.

Restricciones conocidas

Estas son las limitaciones conocidas:

Sincronización delta

  • El filtro de ámbito de grupos para la sincronización diferencial no admite más de 50 000 miembros.
  • Cuando se elimina un grupo que se usa como parte de un filtro de ámbito de grupo, los usuarios que pertenecen a dicho grupo no se eliminan.
  • Al cambiar el nombre de la unidad organizativa o del grupo que se encuentra en el ámbito, la sincronización diferencial no eliminará los usuarios.

Registros de aprovisionamiento

  • Los registros de aprovisionamiento no distinguen claramente entre las operaciones de creación y actualización. Es posible que se muestre una operación de creación para una actualización, y viceversa.

Cambio del nombre de grupo o de la unidad organizativa

  • Si cambia el nombre de un grupo o de una unidad organizativa de AD que se encuentra en el ámbito de una configuración determinada, el trabajo de sincronización en la nube no podrá reconocer el cambio de nombre en AD. El trabajo no entrará en cuarentena y permanecerá en buen estado.

Filtro de ámbito

Al usar el filtro de ámbito de unidad organizativa

  • Solo puede sincronizar hasta 59 unidades organizativas para una configuración determinada.
  • Se admiten unidades organizativas anidadas (es decir, puede sincronizar una unidad organizativa que tenga 130 unidades organizativas anidadas, pero no puede sincronizar 60 unidades organizativas independientes en la misma configuración).

Sincronización de hash de contraseñas

  • No se admite el uso de la sincronización de hash de contraseña con InetOrgPerson.

Pasos siguientes