Compartir a través de

Requisitos previos para Microsoft Entra Cloud Sync

  • Artículo

En este artículo se proporcionan instrucciones sobre el uso de Microsoft Entra Cloud Sync como solución de identidad.

Requisitos del agente de aprovisionamiento en la nube

Necesita lo siguiente para usar Microsoft Entra Cloud Sync:

  • Credenciales de administrador de dominio o administrador de empresa para crear la gMSA de Microsoft Entra Connect cloud sync (cuenta de servicio administrada de grupo) para ejecutar el servicio de agente.
  • Una cuenta de administrador de identidades híbridas para el inquilino de Microsoft Entra que no es 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. Para obtener más información, consulte Proteger el servidor del agente de aprovisionamiento de Microsoft Entra
    • Obligatorio para el atributo de esquema de AD: msDS-ExternalDirectoryObjectId
  • La alta disponibilidad hace referencia a la capacidad de Microsoft Entra Cloud Sync para operar continuamente sin errores durante mucho tiempo. Al tener varios agentes activos instalados y en ejecución, Microsoft Entra Cloud Sync puede seguir funcionando aunque se produzca un error en un agente. Microsoft recomienda tener 3 agentes activos instalados para alta disponibilidad.
  • Configuraciones de firewall locales.

Reforzar el servidor del agente de aprovisionamiento de Microsoft Entra

Se recomienda proteger el servidor del agente de aprovisionamiento de Microsoft Entra para reducir la superficie expuesta a ataques de seguridad para este componente crítico del entorno de TI. Seguir estas recomendaciones ayuda a mitigar algunos riesgos de seguridad para su organización.

  • Se recomienda reforzar el servidor del agente de aprovisionamiento de Microsoft Entra como un recurso del Plano de Control (anteriormente Nivel 0) siguiendo las indicaciones proporcionadas en Secure Privileged Access y Modelo de Nivel Administrativo de Active Directory.
  • Restrinja el acceso administrativo al servidor del agente de aprovisionamiento de Microsoft Entra solo a los administradores de dominio u otros grupos de seguridad estrechamente controlados.
  • Cree una cuenta dedicada para todo el personal con acceso con privilegios. Los administradores no deben navegar por la web, comprobar su correo electrónico y realizar tareas de productividad diarias con cuentas con privilegios elevados.
  • Siga las instrucciones proporcionadas en Protección del acceso con privilegios.
  • Denegar el uso de la autenticación NTLM con el servidor del agente de aprovisionamiento de Microsoft Entra. Estas son algunas maneras de hacerlo: Restringir NTLM en el servidor del agente de aprovisionamiento de Microsoft Entra y Restringir NTLM en un dominio
  • Asegúrese de que cada máquina tiene una contraseña de administrador local única. Para obtener más información, consulte solución de contraseñas de administrador local (Windows LAPS) puede configurar contraseñas aleatorias únicas en cada estación de trabajo y el servidor almacenarlas en Active Directory protegida por una ACL. Solo los usuarios autorizados aptos pueden leer o solicitar el restablecimiento de estas contraseñas de cuenta de administrador local. Puede encontrar orientación adicional para operar un entorno con Windows LAPS y estaciones de trabajo con acceso privilegiado (PAWs) en Normas operativas basadas en el principio de origen limpio.
  • Implemente estaciones de trabajo de acceso con privilegios dedicadas para todo el personal con acceso con privilegios a los sistemas de información de su organización.
  • Siga estas instrucciones adicionales para reducir la superficie expuesta a ataques de su entorno de Active Directory.
  • Consulte Supervisión de cambios en la configuración de federación para configurar alertas para supervisar los cambios en la confianza establecida entre el IDP y Microsoft Entra ID.
  • Habilite la autenticación multifactor (MFA) para todos los usuarios que tengan acceso con privilegios en microsoft Entra ID o en AD. Un problema de seguridad con el uso del agente de aprovisionamiento de Microsoft Entra es que si un atacante puede obtener control sobre el servidor del agente de aprovisionamiento de Microsoft Entra, pueden manipular usuarios en el identificador de Microsoft Entra. Para evitar que un atacante use estas funcionalidades para asumir las cuentas de Microsoft Entra, MFA ofrece protecciones. Por ejemplo, incluso si un atacante logra restablecer la contraseña de un usuario mediante el agente de aprovisionamiento de Microsoft Entra, aún no puede eludir el segundo factor.

Cuentas de servicio administradas de grupo

Una Cuenta de Servicio Gestionada de grupo es una cuenta de dominio gestionado que proporciona gestión automática de contraseñas y gestión simplificada del nombre principal de servicio (SPN). También ofrece la capacidad de delegar la administración a otros administradores y amplía esta funcionalidad a través de varios servidores. Microsoft Entra Cloud Sync admite y usa una gMSA para ejecutar el agente. Se le pedirán credenciales administrativas durante la instalación para crear esta cuenta. La cuenta aparece como domain\provAgentgMSA$. Para obtener más información sobre gMSA, consulte Cuentas de servicio administradas de grupo.

Requisitos previos para gMSA

  1. El esquema de Active Directory del bosque del dominio gMSA debe actualizarse a Windows Server 2012 o posterior.
  2. Módulos de RSAT de PowerShell en un controlador de dominio.
  3. Al menos un controlador de dominio del dominio debe ejecutar Windows Server 2012 o posterior.
  4. Un servidor unido a un dominio en el que se instala 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 tiene los permisos siguientes.

Tipo Nombre Acceso Se aplica a
Permitir Cuenta de gMSA Lectura de todas las propiedades Objetos del dispositivo descendientes
Permitir Cuenta de gMSA Lectura de todas las propiedades Objetos InetOrgPerson descendientes
Permitir Cuenta de gMSA Lectura de todas las propiedades Objetos del ordenador descendientes
Permitir Cuenta de gMSA Lectura de todas las propiedades Objetos foreignSecurityPrincipal descendientes
Permitir Cuenta de gMSA Control total Objetos del grupo descendientes
Permitir Cuenta de gMSA Lectura de todas las propiedades Objetos de usuario descendientes
Permitir Cuenta de gMSA Lectura de todas las propiedades Objetos del contacto descendiente
Permitir Cuenta de gMSA Crear/eliminar objetos de Usuario Este objeto y todos los objetos descendientes

Para obtener instrucciones sobre cómo actualizar un agente de servicio existente para usar una cuenta de gMSA, véase 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 de cuentas de servicio administradas de grupo y cuentas de servicio administradas de grupo con sincronización en la nube.

En el Centro de administración de Microsoft Entra

  1. Cree una cuenta de administrador de identidad híbrida exclusiva para la nube en el entorno de Microsoft Entra. De este modo, puede gestionar la configuración de su entorno si los servicios locales fallan o dejan de estar 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 Active Directory

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

En tu entorno local

  1. Identifique un servidor host unido a un dominio que ejecute Windows Server 2016 o superior con un mínimo de 4 GB de RAM y entorno de ejecución de .NET 4.7.1+.
  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

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

Aprovisionamiento de Microsoft Entra ID en Active Directory: requisitos previos

Los siguientes requisitos previos son necesarios para implementar grupos de aprovisionamiento en Active Directory.

Requisitos de licencia

El uso de esta característica requiere licencias de Microsoft Entra ID P1. Para encontrar la licencia que más se ajuste a sus requisitos, consulte la Comparación de las características de disponibilidad general de Microsoft Entra ID.

Requisitos generales

  • Cuenta de Microsoft Entra con al menos un rol de Administrador de identidad híbrida.
  • Entorno local de Active Directory Domain Services con el sistema operativo Windows Server 2016 o posterior.
    • Se requiere msDS-ExternalDirectoryObjectId para el atributo del esquema de AD.
  • Agente de aprovisionamiento con la versión de compilación 1.1.1370.0 o posterior.

Nota

Los permisos para la cuenta de servicio se asignan solo durante una instalación limpia. En caso de que actualice desde la versión anterior, los permisos deben asignarse manualmente mediante el cmdlet de PowerShell:

$credential = Get-Credential  

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

Si los permisos se establecen manualmente, debe asegurarse de que las propiedades Leer, Escribir, Crear y Eliminar estén disponibles para todos los objetos de usuario y grupos descendientes.

Los cmdlets de PowerShell de gMSA del agente de aprovisionamiento de Microsoft Entra predeterminados no aplican estos permisos a los objetos AdminSDHolder.

  • El agente de aprovisionamiento debe poder comunicarse con uno o varios controladores de dominio en los puertos TCP/389 (LDAP) y TCP/3268 (Catálogo global).
    • Necesario para la búsqueda global de catálogos para filtrar las referencias de pertenencia no válidas
  • Microsoft Entra Connect Sync con la versión de compilación 2.2.8.0 o posterior
    • Se necesita para admitir la pertenencia de usuarios locales sincronizados mediante Microsoft Entra Connect Sync
    • Necesario para sincronizar AD:user:objectGUID con AAD:user:onPremisesObjectIdentifier

Grupos admitidos y límites de escalado

Se admite lo siguiente:

  • Solo se admiten grupos de seguridad de creados en la nube
  • Estos grupos pueden tener grupos de pertenencia dinámicos o asignados.
  • Estos grupos solo pueden contener usuarios sincronizados locales o grupos de seguridad creados en la nube adicionales.
  • Las cuentas de usuario locales que se sincronizan y son miembros de este grupo de seguridad creado en la nube pueden ser del mismo dominio o entre dominios, pero todos deben ser del mismo bosque.
  • Estos grupos se vuelven a escribir con el ámbito de grupos de AD universal. El entorno local debe admitir el ámbito del grupo universal.
  • No se admiten grupos con más de 50 000 miembros.
  • No se admiten los inquilinos con más de 150 000 objetos. Es decir, si un inquilino tiene cualquier combinación de usuarios y grupos que supere los 150 000 objetos, no se admite el inquilino.
  • Cada grupo anidado secundario directo cuenta como un miembro del grupo de referencia
  • No se admite la conciliación de grupos entre microsoft Entra ID y Active Directory si el grupo se actualiza manualmente en Active Directory.

Información adicional

A continuación se muestra información adicional sobre el aprovisionamiento de grupos en Active Directory.

  • Los grupos aprovisionados en AD mediante la sincronización en la nube solo pueden contener usuarios sincronizados locales o grupos de seguridad creados en la nube adicionales.
  • Estos usuarios deben tener el atributo onPremisesObjectIdentifier establecido en su cuenta.
  • OnPremisesObjectIdentifier debe coincidir con un objectGUID correspondiente en el entorno de AD de destino.
  • Se puede sincronizar un atributo objectGUID de usuarios en las instalaciones con el atributo onPremisesObjectIdentifier de los usuarios en la nube utilizando Microsoft Entra Cloud Sync (1.1.1370.0) o Microsoft Entra Connect Sync (2.2.8.0)
  • Si usa Microsoft Entra Connect Sync (2.2.8.0) para sincronizar usuarios, en lugar de Microsoft Entra Cloud Sync, y quiere usar el aprovisionamiento en AD, debe ser 2.2.8.0 o posterior.
  • Solo se admiten inquilinos normales de Microsoft Entra ID para el aprovisionamiento de Microsoft Entra ID a Active Directory. No se admiten inquilinos como B2C.
  • El trabajo de aprovisionamiento de grupos está programado para ejecutarse cada 20 minutos.

Más requisitos

Requisitos de TLS

Nota

Seguridad de la capa de transporte (TLS) es un protocolo que proporciona comunicaciones seguras. El cambio de la configuración de TLS afecta a todo el bosque. Para obtener más información, consulte Actualización para habilitar TLS 1.1 y TLS 1.2 como protocolos seguros predeterminados en 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 (seleccione 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 el identificador de Microsoft Entra, configure los siguientes elementos:

  • 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 Descripción
    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) Los agentes notifican su estado cada 10 minutos a través del puerto 8080, si el puerto 443 no está disponible. Este estado se muestra en el Centro de administración de Microsoft Entra.

  • Si el firewall aplica reglas según los usuarios de origen, abra estos puertos para el tráfico de los servicios de Windows que se ejecutan como un servicio de red.

  • Asegúrese de que el proxy admite al menos el protocolo HTTP 1.1 y la codificación fragmentada está habilitada.

  • Si el firewall o el proxy le permiten especificar sufijos seguros, agregue conexiones:

URL Descripción
*.msappproxy.net
*.servicebus.windows.net		 El agente usa estas direcciones URL para comunicarse con el servicio en la nube de Microsoft Entra.
*.microsoftonline.com
*.microsoft.com
*.msappproxy.com
*.windowsazure.com		 El agente usa 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 usa estas direcciones URL para comprobar los certificados.
login.windows.net El agente usa estas direcciones URL durante el proceso de registro.

Requisito NTLM

No debe habilitar NTLM en Windows Server que ejecuta el agente de aprovisionamiento de Microsoft Entra y, si está habilitado, debe asegurarse de deshabilitarlo.

Limitaciones conocidas

A continuación se indican las limitaciones conocidas:

Sincronización diferencial

  • El filtrado de ámbito de grupo para la sincronización diferencial no admite más de 50 000 miembros.
  • Al eliminar un grupo que se usa como parte de un filtro de ámbito de grupo, los usuarios que son miembros del grupo no se eliminan.
  • Cuando cambie el nombre de la UO o del grupo que está en el ámbito, la sincronización diferencial no eliminará los usuarios.

Registros de aprovisionamiento

  • Los registros de aprovisionamiento no diferencian 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 de nombre de grupo o cambio de nombre de unidad organizativa

  • Si cambia el nombre de un grupo o una unidad organizativa en AD que está en el ámbito de una configuración determinada, el trabajo de sincronización en la nube no puede reconocer el cambio de nombre en AD. El trabajo no entra en cuarentena y permanece en estado correcto.

Filtro de ámbito

Al usar el filtro de ámbito de UO

  • La configuración de ámbito tiene una limitación de 4 MB en longitud de caracteres. En un entorno probado estándar, esto se traduce en aproximadamente 50 unidades organizativas independientes (UO) o grupos de seguridad, incluidos sus metadatos necesarios, 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ñas con InetOrgPerson.

Pasos siguientes