Compartir vía

Compare los servicios de dominio de Active Directory autoadministrados, Microsoft Entra ID y los servicios de dominio de Microsoft Entra administrados

  • Artículo

Para proporcionar a las aplicaciones, los servicios o los dispositivos acceso a una identidad central, existen tres formas comunes de usar los servicios basados en Active Directory en Azure. Esta variedad de soluciones de identidad permite usar el directorio más adecuado para las necesidades de su organización. Por ejemplo, si administra principalmente usuarios solo en la nube que ejecutan dispositivos móviles, puede que no tenga sentido que compile y ejecute su propia solución de identidad de Active Directory Domain Services (AD DS). En su lugar, simplemente podría usar Microsoft Entra ID.

Aunque las tres soluciones de identidad basadas en Active Directory comparten un nombre y una tecnología comunes, se han diseñado para proporcionar servicios que satisfagan diferentes exigencias de los clientes. De forma general, estas son las soluciones de identidad y los conjuntos de características:

  • Active Directory Domain Services (AD DS) : servidor LDAP (protocolo ligero de acceso a directorios) preparado para la empresa que proporciona características clave como la identidad y la autenticación, la administración de objetos de equipo, la directiva de grupo y confianzas.
    • AD DS es un componente central de muchas organizaciones con un entorno de TI local y proporciona características básicas de administración de equipos y autenticación de cuentas de usuario.
    • Para más información, consulte Introducción a Active Directory Domain Services en la documentación de Windows Server.
  • Microsoft Entra ID: administración de identidades basadas en la nube y de dispositivos móviles que proporciona servicios de cuentas de usuario y autenticación para recursos como Microsoft 365, el centro de administración de Microsoft Entra o las aplicaciones SaaS.
    • Microsoft Entra ID se puede sincronizar con un entorno de AD DS local para proporcionar una identidad única a los usuarios que funcionan de forma nativa en la nube.
    • Para obtener información sobre las características de Microsoft Entra ID, consulte ¿Qué es Microsoft Entra ID?
  • Microsoft Entra Domain Services: proporciona servicios de dominio administrados con un subconjunto de características de AD DS tradicionales totalmente compatibles como, por ejemplo, unión a un dominio, directiva de grupo, LDAP y autenticación Kerberos o NTLM.
    • Domain Services se integra con Microsoft Entra ID, que puede sincronizarse con un entorno de AD DS local. Esta capacidad amplía los casos de uso de identidad central a las aplicaciones web tradicionales que se ejecutan en Azure como parte de una estrategia de migración mediante lift-and-shift.
    • Para más información sobre la sincronización con Microsoft Entra ID y local, consulte Procedimiento para sincronizar objetos y credenciales en un dominio administrado.

En este artículo de introducción se compara cómo estas soluciones de identidad pueden actuar juntas o usarse de forma independiente, en función de las necesidades de su organización.

Para empezar, cree un dominio administrado de Domain Services mediante el centro de administración de Microsoft Entra

Domain Services y AD DS autoadministrado

Si tiene aplicaciones y servicios que necesitan acceder a mecanismos de autenticación tradicionales como Kerberos o NTLM, hay dos maneras de contar con Active Directory Domain Services en la nube:

  • Un dominio administrado que se crea mediante Microsoft Entra Domain Services. Microsoft crea y administra los recursos necesarios.
  • Un dominio autoadministrado que tiene que crear y configurar mediante recursos tradicionales como, por ejemplo, máquinas virtuales (VM), el sistema operativo invitado de Windows Server y Active Directory Domain Services (AD DS). Después se encarga de seguir administrando estos recursos.

Con Domain Services, Microsoft implementa y mantiene los componentes de servicios básicos como una experiencia de dominio administrado. Usted no tiene que implementar, administrar, aplicar revisiones ni proteger la infraestructura de AD DS para componentes como las máquinas virtuales, el sistema operativo Windows Server o los controladores de dominio (DC).

Domain Services proporciona un subconjunto más pequeño de características para el entorno de AD DS autoadministrado tradicional, lo que reduce parte de la complejidad del diseño y la administración. Por ejemplo, no hay bosques, dominios, sitios ni vínculos de replicación de AD que diseñar y mantener. Todavía puede crear confianzas de bosque entre Domain Services y los entornos locales.

En el caso de las aplicaciones y los servicios que se ejecutan en la nube y necesitan acceso a mecanismos de autenticación tradicionales como Kerberos o NTLM, Domain Services proporciona una experiencia de dominio administrado con la mínima cantidad posible de sobrecarga administrativa. Para más información, consulte Conceptos de administración para cuentas de usuario, contraseñas y administración en Domain Services.

Al implementar y ejecutar un entorno de AD DS autoadministrado, tiene que mantener todos los componentes de infraestructura y directorio asociados. Con un entorno de AD DS autoadministrado existe una sobrecarga de mantenimiento adicional, pero después podrá realizar tareas adicionales, como extender el esquema o crear confianzas de bosques.

Entre los modelos de implementación comunes para un entorno de AD DS autoadministrado que proporciona identidad a aplicaciones y servicios en la nube se encuentran los siguientes:

  • AD DS solo en la nube independiente: las máquinas virtuales de Azure se configuran como controladores de dominio y se crea un entorno de AD DS solo en la nube independiente. Este entorno de AD DS no se integra con un entorno de AD DS local. Se usa un conjunto diferente de credenciales para iniciar sesión en las máquinas virtuales en la nube y administrarlas.
  • Ampliación del dominio local a Azure: una red virtual de Azure se conecta a una red local mediante una conexión VPN o ExpressRoute. Las máquinas virtuales de Azure se conectan a esta red virtual de Azure, lo que les permite unirse a un dominio en el entorno de AD DS local.
    • También se pueden crear máquinas virtuales de Azure y promoverlas como controladores de dominio de réplica del dominio de AD DS local. Estos controladores de dominio se replican a través de una conexión VPN o ExpressRoute en el entorno de AD DS local. De este modo, el dominio de AD DS local se amplía de manera eficaz a Azure.

En la tabla siguiente se describen algunas de las características que puede necesitar en su organización, así como las diferencias entre un dominio administrado o un dominio de AD DS autoadministrado:

Característica Dominio administrado AD DS autoadministrado
Servicio administrado ✓ ✕
Implementaciones seguras ✓ El administrador protege la implementación
Servidor DNS ✓ (servicio administrado) ✓
Privilegios de administrador de dominio o empresa ✕ ✓
Unión a un dominio ✓ ✓
Autenticación de dominios mediante NTLM y Kerberos ✓ ✓
Delegación limitada de Kerberos Basada en recursos Basada en recursos y basada en cuentas
Estructura de unidad organizativa personalizada ✓ ✓
Directiva de grupo ✓ ✓
Extensiones de esquema ✕ ✓
Confianzas de bosques o dominios de AD ✓ (solo relaciones de confianza de bosque de salida unidireccional) ✓
LDAP seguro (LDAPS) ✓ ✓
Lectura LDAP ✓ ✓
Escritura LDAP ✓ (dentro del dominio administrado) ✓
Implementaciones distribuidas geográficamente ✓ ✓

Domain Services y Microsoft Entra ID

Microsoft Entra ID le permite administrar la identidad de los dispositivos usados por la organización y controlar el acceso a los recursos corporativos desde estos dispositivos. Los usuarios también pueden registrar su dispositivo personal (modelo BYO o Bring Your Own) con Microsoft Entra ID, lo que proporcionará una identidad al dispositivo. Microsoft Entra ID autentica el dispositivo cuando un usuario inicia sesión en Microsoft Entra ID y usa el dispositivo para acceder a los recursos protegidos. El dispositivo se puede controlar con software de administración de dispositivos móviles (MDM), como Microsoft Intune. Esta capacidad de administración permite restringir el acceso a recursos confidenciales desde dispositivos administrados que cumplen las directivas.

Los equipos y portátiles tradicionales también pueden unirse a Microsoft Entra ID. Este mecanismo ofrece las mismas ventajas que el registro de un dispositivo personal con Microsoft Entra ID, como permitir que los usuarios inicien sesión en el dispositivo con sus credenciales corporativas.

Los dispositivos unidos a Microsoft Entra ofrecen las siguientes ventajas:

  • Inicio de sesión único (SSO) en aplicaciones protegidas por Microsoft Entra ID.
  • Itinerancia de configuraciones de usuario que cumplen las directivas corporativas entre dispositivos.
  • Acceso a Microsoft Store para Empresas con credenciales corporativas.
  • Windows Hello para empresas.
  • Acceso restringido a aplicaciones y recursos desde dispositivos que cumplen las directivas corporativas.

Los dispositivos pueden unirse a Microsoft Entra ID con o sin una implementación híbrida que incluya un entorno de AD DS local. En la tabla siguiente se describen los modelos de propiedad de dispositivo habituales y cómo se suelen unir a un dominio:

Tipo de dispositivo Plataformas de dispositivo Mecanismo
Dispositivos personales Windows 10, iOS, Android y macOS Microsoft Entra registrado
Dispositivo propiedad de la organización no unido a AD DS local Windows 10 Unido a Microsoft Entra
Dispositivo propiedad de la organización unido a AD DS local Windows 10 Unido a Microsoft Entra

En un dispositivo registrado o unido a Microsoft Entra, la autenticación de usuario se realiza mediante modernos protocolos basados en OAuth u OpenID Connect. Estos protocolos están diseñados para funcionar a través de Internet, por lo que son excelentes en escenarios móviles donde los usuarios acceden a los recursos corporativos desde cualquier lugar.

Con los dispositivos unidos a Domain Services, las aplicaciones pueden usar los protocolos Kerberos y NTLM para la autenticación, por lo que se pueden admitir aplicaciones heredadas migradas para ejecutarse en máquinas virtuales de Azure como parte de una estrategia de migración mediante lift-and-shift. En la tabla siguiente se describen las diferencias en el modo en que se representan los dispositivos y cómo se pueden autenticar a sí mismos en el directorio:

Aspecto Unido a Microsoft Entra Unido a Domain Services
Dispositivo controlado por Microsoft Entra ID Dominio administrado con Domain Services
Representación en el directorio Objetos de dispositivo en el directorio de Microsoft Entra Objetos de equipo en el dominio administrado de Domain Services
Autenticación Protocolos basados en OAuth y OpenID Connect Protocolos Kerberos y NTLM
Administración Software de administración de dispositivos móviles (MSM), como Intune Directiva de grupo
Redes Funciona a través de Internet Debe estar conectado a la red virtual en la que se ha implementado el dominio administrado, o emparejarse con ella.
Idóneo para... Dispositivos móviles o de escritorio de usuario final Máquinas virtuales de servidor implementadas en Azure

Si las instancias de AD DS y Microsoft Entra ID locales están configuradas para la autenticación federada mediante AD FS, entonces no hay ningún hash de contraseña (actual o válido) disponible en Azure DS. Las cuentas de usuario de Microsoft Entra creadas antes de que se implementara la autenticación federada pueden tener un hash de contraseña antiguo, pero es probable que no coincida con un hash de la contraseña local. Como resultado, Domain Services no podrá validar las credenciales de los usuarios

Pasos siguientes

Para empezar a usar Domain Services, cree un dominio administrado de Domain Services mediante el centro de administración de Microsoft Entra.

También puede obtener más información acerca de los conceptos de administración de cuentas de usuario, contraseñas y administración en Domain Services y el proceso de sincronización de objetos y credenciales en un dominio administrado.