Compartir vía

Requisitos previos para Microsoft Entra Cloud Sync

  • Artículo

Este artículo ofrece orientación sobre el uso de 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. Para obtener más información, consulte Protección del servidor del agente de aprovisionamiento de Microsoft Entra
    • Se requiere para el atributo de esquema de AD: msDS-ExternalDirectoryObjectId
  • 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.

Protección del servidor del agente de aprovisionamiento de Microsoft Entra

Se recomienda reforzar el servidor del agente de aprovisionamiento de Microsoft Entra para reducir la superficie de ataque de seguridad para este componente crítico de su entorno de TI. La aplicación de estas recomendaciones lo ayudará a reducir algunos riesgos de seguridad de su organización.

  • Se recomienda proteger el servidor del agente de aprovisionamiento de Microsoft Entra como un recurso de plano de control (anteriormente nivel 0) siguiendo las instrucciones proporcionadas en Protección del acceso con privilegios y Modelo de nivel administrativo de Active Directory.
  • Restrinja el acceso administrativo al servidor del agente de aprovisionamiento de Microsoft Entra a solo los administradores del dominio o a otros grupos de seguridad rigurosamente controlados.
  • Cree una cuenta dedicada para todo el personal con privilegios de acceso. Los administradores no deben explorar la Web, consultar su correo electrónico y realizar las tareas de productividad cotidianas con cuentas con privilegios elevados.
  • Siga las instrucciones que se proporcionan 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 todas las máquinas tienen una contraseña de administrador local única. Para más información, vea cómo la Solución de contraseñas de administrador local (Windows LAPS) puede configurar contraseñas aleatorias únicas en cada estación de trabajo y almacenarlas en Active Directory protegidas mediante una ACL. Solo los usuarios autorizados válidos pueden leer o solicitar el restablecimiento de estas contraseñas de cuenta de administrador local. Puede encontrar orientación adicional para el funcionamiento de un entorno con Windows LAPS y las estaciones de trabajo de acceso privilegiado en Estándares operativos basados en el principio de origen limpio.
  • Implemente estaciones de trabajo de acceso privilegiado 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 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, puede manipular a los usuarios en Microsoft Entra ID. Para evitar que un atacante use estas funcionalidades para tomar el control de las cuentas de Microsoft Entra, MFA ofrece protecciones para que, aunque un atacante logre, por ejemplo, restablecer la contraseña de un usuario mediante el agente de aprovisionamiento de Microsoft Entra, no pueda omitir el segundo factor.

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. Se le pedirán credenciales administrativas durante la configuración, con el fin de 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 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
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 equipo 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 del usuario descendientes
Permitir Cuenta de gMSA Lectura de todas las propiedades Objetos del contacto descendiente
Permitir 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 más información sobre cómo preparar Active Directory para la cuenta de servicio administrada de grupo, consulte Información general de las cuentas de servicio administradas de grupo y Cuentas de servicio administradas de grupo con la sincronización en la nube.

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.

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 una licencia P1 de Microsoft Entra ID. Para encontrar la licencia que más se ajuste a sus requisitos, vea 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 para el atributo de esquema de AD: msDS-ExternalDirectoryObjectId
  • Aprovisionamiento del agente 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 la instalación limpia. En caso de que esté actualizando desde la versión anterior, los permisos deben asignarse manualmente mediante un 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.

Estos permisos no se aplican a objetos AdminSDHolder de forma predeterminada cmdlets de PowerShell gMSA del agente de aprovisionamiento de Microsoft Entra

  • El agente de aprovisionamiento debe poder comunicarse con los controladores de dominio en los puertos TCP/389 (LDAP) y TCP/3268 (catálogo global).
    • Se necesita para la búsqueda del catálogo global, 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
    • Se necesita para sincronizar AD:user:objectGUID con AAD:user:onPremisesObjectIdentifier

Grupos admitidos y límites de escalado

Lo siguiente es compatible:

  • Solo se admiten Grupos de seguridad creados en la nube
  • Estos grupos pueden tener grupos de pertenencia dinámica 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 que tienen 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 locales a usuarios en la nube onPremisesObjectIdentifier mediante 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

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 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) 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.

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

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

URL Descripción
*.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.
  • Cuando cambie el nombre de la OU o del grupo que está en el ámbito, la sincronización delta 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 de nombre de grupo o cambio de nombre de 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

  • 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 (UO) independientes 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ña con InetOrgPerson.

Pasos siguientes