Requisitos previos para Microsoft Entra Cloud Sync

  • Artículo

En este artículo se proporciona una guía sobre cómo elegir y usar Microsoft Entra Cloud Sync como solución de identidad.

Requisitos del agente de aprovisionamiento en la nube

Para usar Microsoft Entra Cloud Sync, necesita:

  • Credenciales de administrador de dominio o administrador de empresa para crear la gMSA (cuenta de servicio administrada de grupo) de Microsoft Entra Connect Cloud Sync para ejecutar el servicio del agente.
  • Una cuenta de administrador de identidades híbridas para su inquilino de Microsoft Entra 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 se refiere a la capacidad de Microsoft Entra Cloud Sync para funcionar continuamente sin errores durante mucho tiempo. Al tener varios agentes activos instalados y en ejecución, Microsoft Entra 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 administrada 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. Microsoft Entra Cloud Sync 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

Si quiere conocer los pasos para actualizar un agente existente con el fin de usar una cuenta de gMSA, consulte Cuentas de servicio administradas de grupo.

Para obtener más información sobre cómo preparar Active Directory para la cuenta de servicio administrada de grupo, consulte Información general sobre las cuentas de servicio administradas de grupo.

En el Centro de administración de Microsoft Entra

  1. Cree una cuenta de administrador de identidades híbridas exclusiva para la nube en su inquilino de Microsoft Entra. 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 Microsoft Entra. 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 los servidores y Microsoft Entra ID, consulte más adelante Requisitos de firewall y proxy.

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 Microsoft Entra 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 copiando el contenido en un archivo .reg y, a continuación, ejecute el archivo (haga clic con el botón derecho y elija Combinar):

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

Requisitos de firewall y proxy

Si hay un firewall entre los servidores y Microsoft Entra ID, configure los elementos siguientes:

  • Asegúrese de que los agentes pueden realizar solicitudes de salida a Microsoft Entra ID 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 centro de administración de Microsoft Entra.

  • 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 Microsoft Entra.
*.microsoftonline.com
*.microsoft.com
*.msappproxy.com
*.windowsazure.com		 El agente utiliza estas direcciones URL para comunicarse con el servicio en la nube de Microsoft Entra.
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 se debería habilitar NTLM en el servidor de Windows Server que ejecute el agente de aprovisionamiento de Microsoft Entra. Si estuviera habilitado, asegúrese de deshabilitarlo.

Limitaciones 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 o grupos de seguridad 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