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

  • Artículo

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 usarlo 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 una administración de identidad y acceso moderna y segura, adecuada para muchas organizaciones y cargas de trabajo, y se encuentra en el núcleo de los servicios de Azure y Microsoft 365. Si su organización tiene una infraestructura de AD DS local, es posible que las cargas de trabajo basadas en la nube requieran la sincronización de directorios con Microsoft Entra ID para un conjunto coherente de identidades, grupos y roles entre los entornos locales y en la nube. O bien, si tiene aplicaciones que dependen de mecanismos de autenticación heredados, es posible que tenga que implementar Domain Services administrado en la nube.

La administración de identidades basada en la nube es un proceso iterativo. Podría empezar con una solución nativa de la nube con un pequeño conjunto de usuarios y roles correspondientes para una implementación inicial y, a medida que su migración madure, podría necesitar integrar su solución de identidad utilizando la sincronización de directorios o añadir servicios de dominio hospedados en la nube como parte de sus implementaciones en la nube.

Con el tiempo, revise su solución de identidad 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 Active Directory, comprenda las diferencias entre Microsoft Entra ID, Domain Services y AD DS en Windows Server.

Para obtener ayuda con la estrategia de identidad, consulte Guía de decisión 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. Las organizaciones pueden usar Microsoft Entra ID para proteger los recursos de la plataforma mediante el control del acceso administrativo. 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.

Las organizaciones que usan AD DS o Domain Services también deben proteger los controladores de dominio frente al acceso no autorizado. Los controladores de dominio son objetivos especialmente atractivos para los atacantes y deben tener estrictos controles de seguridad y segregación de las cargas de trabajo de aplicación.

Los controladores de dominio y los componentes asociados, como los servidores de Microsoft Entra ID Connect, se implementan 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. Al proporcionar este aislamiento, los propietarios de aplicaciones pueden consumir los servicios de identidad sin tener que administrarlos y se reduce el riesgo de que los servicios de administración de identidad y acceso estén en peligro. 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.

Se deben aprovisionar zonas de aterrizaje para que los propietarios de aplicaciones puedan usar Microsoft Entra ID o AD DS y Domain Services, según lo requieran sus cargas de trabajo. En función de la solución de identidad que use, es posible que tenga que configurar otros servicios según sea necesario. 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 se crean completamente en Microsoft Entra ID se conocen como cuentas solo en la 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.

Sin embargo, muchas organizaciones ya tienen directorios de AD DS de larga duración que podrían integrarse con otros sistemas, como la planificación de recursos empresariales o de línea de negocio (ERP) a través del 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 unió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 a través de Microsoft Entra Connect o la sincronización de Microsoft Entra Connect. Para determinar la configuración recomendada para su entorno, consulte Topologías para Microsoft Entra Connect.

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

Recomendaciones de identidad híbrida

Importante

Se recomienda encarecidamente migrar a Microsoft Entra ID a menos que haya un requisito específico para usar AD FS. Para obtener más información, consulte Recursos para retirar AD FS y Migración de AD FS a Microsoft Entra ID.

Microsoft Entra ID, Domain Services y AD DS

Los administradores deben familiarizarse con las opciones para implementar servicios de directorio de Microsoft:

  • Puede implementar controladores de dominio de AD DS en Azure como máquinas virtuales Windows de las que los administradores de plataformas o identidades tienen 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 puede 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.

Una vez configurado AD DS o Domain Services, puede unir a un dominio máquinas virtuales de Azure y recursos compartidos de archivos mediante el mismo método que los equipos locales. 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 a través de Microsoft Entra ID, use el proxy de aplicación de Microsoft Entra. Esta característica proporciona acceso remoto seguro a aplicaciones web locales. 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. Evite la conectividad directa a Internet hacia y desde esos sistemas colocando los servidores de AD DS en una subred aislada con un grupo de seguridad de red (NSG), lo que proporciona funcionalidad de firewall. 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, Azure Policy o etiquetas de recursos de red virtual se pueden usar 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.

  • 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. Puede expandir Domain Services a otras regiones agregando hasta cuatro conjuntos de réplicas más en redes virtuales independientes emparejadas con la red virtual principal. Para minimizar la latencia, mantenga las aplicaciones principales cerca o en la misma región que la red virtual para los conjuntos de réplicas.

  • Al implementar controladores de dominio de AD DS en Azure, impleméntelos en zonas de disponibilidad para aumentar la resistencia. 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.

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

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

Pasos siguientes

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