Identidad híbrida con Active Directory y Microsoft Entra ID en zonas de aterrizaje de Azure

En este artículo se proporcionan instrucciones sobre cómo diseñar e implementar Microsoft Entra ID y la identidad híbrida para las zonas de aterrizaje de Azure.

Las organizaciones que operan en la nube requieren un servicio de directorio para administrar identidades de usuario y acceso a los recursos. Microsoft Entra ID es un servicio de administración de identidad y acceso basado en la nube que proporciona capacidades sólidas para administrar usuarios y grupos. Puede usar Microsoft Entra ID como solución de identidad independiente o integrarlo con una infraestructura de Microsoft Entra Domain Services o una infraestructura local de Active Directory Domain Services (AD DS).

Microsoft Entra ID proporciona administración de identidad y acceso moderna y segura para los servicios de Azure y Microsoft 365. Puede usar Microsoft Entra ID para varias organizaciones y cargas de trabajo. Por ejemplo, las organizaciones con una infraestructura de AD DS local y cargas de trabajo basadas en la nube pueden usar la sincronización de directorios con Microsoft Entra ID. La sincronización de directorios garantiza que los entornos locales y en la nube compartan un conjunto coherente de identidades, grupos y roles. Las aplicaciones que requieren mecanismos de autenticación heredados pueden necesitar Domain Services para servicios de dominio administrados en la nube y ampliar la infraestructura de AD DS local a Azure.

La administración de identidades basada en la nube es un proceso iterativo. Podría comenzar con una solución nativa en la nube que tenga un pequeño conjunto de usuarios y roles correspondientes para una implementación inicial. A medida que madure la migración, es posible que deba integrar la solución de identidades mediante la sincronización de directorios o agregar servicios de dominios hospedados en la nube como parte de las implementaciones de nube.

Ajuste su solución de identidad a lo largo del tiempo en función de los requisitos de autenticación de su carga de trabajo y otras necesidades, como los cambios en su estrategia de identidad organizativa y los requisitos de seguridad, o la integración con otros servicios de directorio. Al evaluar las soluciones de Windows Server Active Directory, comprenda las diferencias entre Microsoft Entra ID, Domain Services y AD DS en Windows Server.

Para obtener más información, consulte la Guía de decisiones de identidad.

Servicios de administración de identidad y acceso en zonas de aterrizaje de Azure

El equipo de la plataforma es responsable de la gestión de la administración de identidad y acceso. Los servicios de administración de identidad y acceso son fundamentales para la seguridad de la organización. La organización puede usar Microsoft Entra ID para controlar el acceso administrativo y proteger los recursos de la plataforma. Este enfoque impide que los usuarios externos al equipo de la plataforma realicen cambios en la configuración o en las entidades de seguridad contenidas en Microsoft Entra ID.

Si usa AD DS o Domain Services, también debe proteger los controladores de dominio frente al acceso no autorizado. Los controladores de dominio son muy vulnerables a los ataques y deben tener estrictos controles de seguridad y segregación de las cargas de trabajo de aplicación.

Implemente controladores de dominio y componentes asociados, como los servidores de Microsoft Entra Connect, en la suscripción de identidad, que se encuentra en el grupo de administración de plataformas. Los controladores de dominio no se delegan a los equipos de aplicación. Este aislamiento permite a los propietarios de aplicaciones usar servicios de identidad sin tener que mantenerlos, lo que reduce el riesgo de poner en peligro los servicios de administración de identidad y acceso. Los recursos de la suscripción de plataforma de identidad son un punto crítico de seguridad para los entornos locales y en la nube.

Aprovisione zonas de aterrizaje para que los propietarios de aplicaciones puedan elegir Microsoft Entra ID o AD DS y Domain Services para satisfacer sus necesidades de carga de trabajo. En función de su solución de identidad, es posible que tenga que configurar otros servicios. Por ejemplo, puede que tenga que habilitar y proteger la conectividad de red a la red virtual de identidad. Si usa un proceso de ventas de suscripciones, incluya esta información de configuración en la solicitud de suscripción.

Dominios de Azure y locales (identidad híbrida)

Los objetos de usuario que crea completamente en Microsoft Entra ID se conocen como cuentas solo en la nube. Las cuentas solo de nube admiten la autenticación moderna y el acceso a los recursos de Azure y Microsoft 365, y el acceso a dispositivos locales que usan Windows 10 o Windows 11.

Su organización podría tener ya directorios de AD DS de larga duración que integra con otros sistemas, como la planificación de recursos empresariales (ERP) o de línea de negocio mediante el protocolo ligero de acceso a directorios (LDAP). Estos dominios pueden tener muchos equipos y aplicaciones unidos a un dominio que usan protocolos Kerberos o NTLMv2 anteriores para la autenticación. En estos entornos, puede sincronizar objetos de usuario con Microsoft Entra ID para que los usuarios puedan iniciar sesión en sistemas locales y recursos en la nube con una sola identidad. La unificación de servicios de directorio locales y en la nube se conoce como identidad híbrida. Puede ampliar dominios locales a zonas de aterrizaje de Azure:

• Para mantener un único objeto de usuario en entornos locales y en la nube, puede sincronizar usuarios de dominio de AD DS con Microsoft Entra ID mediante Microsoft Entra Connect o la sincronización en la nube de Microsoft Entra. A fin de determinar la configuración recomendada para su entorno, vea Topologías para Microsoft Entra Connect o Topologías para Microsoft Entra Cloud Sync.

• Para unir un dominio a máquinas virtuales (VM) Windows y otros servicios, puede implementar controladores de dominio de AD DS o Domain Services en Azure. Use este enfoque de modo que los usuarios de AD DS puedan iniciar sesión en servidores de Windows, recursos compartidos de archivos de Azure y otros recursos que usan Active Directory como origen de autenticación. También puede usar otras tecnologías de Active Directory; por ejemplo, la directiva de grupo, como origen de autenticación. Para obtener más información, consulte Escenarios de implementación comunes para Microsoft Entra Domain Services.

Recomendaciones de identidad híbrida

• Para determinar los requisitos de la solución de identidad, documente el proveedor de autenticación que usa cada aplicación. Use la Guía de decisión de identidad a fin de seleccionar los servicios adecuados para su organización. Para obtener más información, vea Comparación entre Active Directory y Microsoft Entra ID.

• Puede utilizar Domain Services para aplicaciones que dependen de los servicios de dominio y utilizan protocolos más antiguos. A veces, los dominios de AD DS existentes admiten la compatibilidad con versiones anteriores y permiten protocolos heredados, lo que puede afectar negativamente a la seguridad. En lugar de ampliar un dominio local, considere la posibilidad de usar Domain Services para crear un dominio que no permita protocolos heredados. Use el nuevo dominio como servicio de directorio para aplicaciones hospedadas en la nube.

• Tenga en cuenta la resistencia como requisito de diseño crítico para la estrategia de identidad híbrida en Azure. Microsoft Entra ID, a diferencia de Domain Services y AD DS, es un sistema basado en la nube con redundancia global. Planifique cuidadosamente la resistencia al implementar Domain Services y AD DS. Al diseñar cualquiera de los servicios, considere la posibilidad de usar implementaciones de varias regiones para garantizar una operación de servicio continua en caso de un incidente regional.

• Para ampliar una instancia de AD DS local a Azure y optimizar la implementación, incorpore las regiones de Azure al diseño del sitio de Active Directory. En sitios y servicios de AD DS, cree un sitio para cada región de Azure donde tenga previsto implementar cargas de trabajo. Después, cree un objeto de subred en sitios y servicios de AD DS para cada intervalo de direcciones IP que tenga previsto implementar en la región. Asocie el nuevo objeto de subred al sitio de AD DS que ha creado. Esta configuración garantiza que el servicio de localizador de controladores de dominio dirija las solicitudes de autorización y autenticación a los controladores de dominio de AD DS más cercanos dentro de la misma región de Azure.

• Evalúe escenarios que impliquen la configuración de invitados, clientes o asociados para que puedan acceder a los recursos. Determine si estos escenarios implican Microsoft Entra B2B o Microsoft Entra ID para los clientes. Para obtener más información, consulte Microsoft Entra External ID.

• No use el proxy de aplicación de Microsoft Entra para el acceso a la intranet, ya que agrega latencia a la experiencia del usuario. Para obtener más información, consulte Planeación del proxy de aplicación de Microsoft Entra y Consideraciones de seguridad del proxy de aplicación de Microsoft Entra.

• Tenga en cuenta varios métodos que puede usar para integrar Active Directory local con Azure para satisfacer los requisitos de la organización.

• Si tiene los Servicios de federación de Active Directory (AD FS) con Microsoft Entra ID, puede usar la sincronización de hash de contraseña como copia de seguridad. AD FS no admite el inicio de sesión único (SSO) de Microsoft Entra.

• Determine la herramienta de sincronización adecuada para su identidad en la nube.

• Si tiene requisitos para usar AD FS, consulte Implementación de AD FS en Azure.

• Si usa Microsoft Entra Connect como herramienta de sincronización, considere la posibilidad de implementar un servidor de almacenamiento provisional en una región diferente del servidor principal de Microsoft Entra Connect para la recuperación ante desastres. Como alternativa, si no usa varias regiones, implemente zonas de disponibilidad para obtener alta disponibilidad.

• Si usa Microsoft Entra Cloud Sync como herramienta de sincronización, considere la posibilidad de instalar al menos tres agentes en servidores diferentes en varias regiones para la recuperación ante desastres. Como alternativa, puede instalar los agentes en servidores en diferentes zonas de disponibilidad para lograr una alta disponibilidad.

Importante

Se recomienda encarecidamente migrar a Microsoft Entra ID, a menos que específicamente requiera AD FS. Para obtener más información, vea Recursos para retirar AD FS y Migración de AD FS a Microsoft Entra ID.

Microsoft Entra ID, Domain Services y AD DS

Para implementar los servicios de directorio de Microsoft, familiarice a los administradores con las siguientes opciones:

• Puede implementar controladores de dominio de AD DS en Azure como VM Windows de las que los administradores de plataformas o identidades tengan control total. Este enfoque es una solución de infraestructura como servicio (IaaS). Puede unir los controladores de dominio a un dominio de Active Directory existente o bien hospedar un nuevo dominio que tenga una relación de confianza opcional con dominios locales existentes. Para más información, consulte Arquitectura de línea base de Azure Virtual Machines en una zona de aterrizaje de Azure.

• Domain Services es un servicio administrado por Azure que puede usar para crear un dominio de Active Directory administrado hospedado en Azure. El dominio puede tener una relación de confianza con los dominios existentes y puede sincronizar las identidades de Microsoft Entra ID. Los administradores no tienen acceso directo a los controladores de dominio y no son responsables de aplicar revisiones ni de otras operaciones de mantenimiento.

• Al implementar Domain Services o integrar entornos locales en Azure, use ubicaciones con zonas de disponibilidad para aumentar la disponibilidad cuando sea posible. Considere también la posibilidad de implementar en varias regiones de Azure para aumentar la resistencia.

Una vez configurado AD DS o Domain Services, puede usar el mismo método que en los equipos locales para unir a un dominio máquinas virtuales de Azure y recursos compartidos de archivos. Para obtener más información, consulte Comparación de los servicios basados en directorios de Microsoft.

Recomendaciones de Microsoft Entra ID y AD DS

• Para acceder a las aplicaciones que usan la autenticación local de forma remota medainte Microsoft Entra ID, use el proxy de aplicación de Microsoft Entra. Esta característica proporciona acceso remoto seguro a aplicaciones web locales. El proxy de aplicación de Microsoft Entra no requiere una VPN ni ningún cambio en la infraestructura de red. Sin embargo, se implementa como una sola instancia en Microsoft Entra ID, por lo que los propietarios de la aplicación y los equipos de plataforma o identidad deben colaborar para asegurarse de que la aplicación está configurada correctamente.

• Evalúe la compatibilidad de las cargas de trabajo para AD DS en Windows Server y Domain Services. Para obtener más información, consulte Casos de uso y escenarios comunes.

• Implemente máquinas virtuales del controlador de dominio o conjuntos de réplicas de Domain Services en la suscripción de plataforma de identidad dentro del grupo de administración de plataformas.

• Proteja la red virtual que contiene los controladores de dominio. Para evitar la conectividad directa a Internet hacia la red virtual y el controlador de dominio y desde estos, coloque los servidores de AD DS en una subred aislada con un grupo de seguridad de red (NSG). El grupo de seguridad de red proporciona función de servidor de seguridad. Los recursos que usan controladores de dominio para la autenticación deben tener una ruta de red a la subred del controlador de dominio. Habilite solo una ruta de red para las aplicaciones que requieren acceso a los servicios de la suscripción de identidad. Para más información, consulte Implementación de AD DS en una red virtual de Azure.

• Use Azure Virtual Network Manager para aplicar reglas estándar que se aplican a las redes virtuales. Por ejemplo, puede usar Azure Policy o etiquetas de recursos de red virtual para agregar redes virtuales de zona de aterrizaje a un grupo de red si requieren servicios de identidad de Active Directory. A continuación, se puede usar el grupo de red que permite el acceso a la subred del controlador de dominio solo desde las aplicaciones que lo requieren y bloquean el acceso de otras aplicaciones.

• Proteja los permisos de control de acceso basado en rol (RBAC) que se aplican a las máquinas virtuales del controlador de dominio y a otros recursos de identidad. Los administradores con asignaciones de roles de RBAC en el plano de control de Azure, como Colaborador, Propietario o Colaborador de máquina virtual, pueden ejecutar comandos en las máquinas virtuales. Asegúrese de que solo los administradores autorizados pueden acceder a las máquinas virtuales de la suscripción de identidad y que las asignaciones de roles excesivamente permisivas no se heredan de grupos de administración superiores.

• A fin de minimizar la latencia, mantenga las aplicaciones principales cerca o en la misma región que la red virtual para los conjuntos de réplicas. En una organización multirregional, implemente Domain Services en la región que hospeda los componentes principales de la plataforma. Solo puede implementar Domain Services en una sola suscripción. Para expandir Domain Services a otras regiones, puede agregar hasta cuatro conjuntos de réplicas más en redes virtuales independientes emparejadas con la red virtual principal.

• Considere la posibilidad de implementar controladores de dominio de AD DS en varias regiones de Azure y entre zonas de disponibilidad para aumentar la resistencia y la disponibilidad. Para más información, consulte Creación de máquinas virtuales en zonas de disponibilidad y Migración de máquinas virtuales a zonas de disponibilidad.

• Como parte de la planificación de identidades, explore los métodos de autenticación para Microsoft Entra ID. La autenticación puede producirse en la nube y en el entorno local, o solo en el entorno local.

• Si un usuario de Windows requiere Kerberos para recursos compartidos de archivos de Azure Files, considere la posibilidad de usar la autenticación Kerberos para Microsoft Entra ID en lugar de implementar controladores de dominio en la nube.

Paso siguiente

Administración de identidad y acceso a la zona de aterrizaje