Comparación de Active Directory Domain Services autoadministrado, Microsoft Entra ID y Microsoft Entra Domain Services administrado
Para proporcionar a las aplicaciones, servicios o dispositivos acceso a una identidad central, hay tres maneras comunes de usar servicios basados en Active Directory en Azure. Esta opción en las soluciones de identidad ofrece la flexibilidad de 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, es posible que no tenga sentido compilar y ejecutar su propia solución de identidad de Active Directory Domain Services (AD DS). En su lugar, simplemente podría usar el identificador de Microsoft Entra.
Aunque las tres soluciones de identidad basadas en Active Directory comparten un nombre común y una tecnología, están diseñados para proporcionar servicios que satisfagan las diferentes demandas de los clientes. En alto nivel, estas soluciones de identidad y conjuntos de características son:
- Active Directory Domain Services (AD DS) - Servidor de Protocolo Ligero de Acceso a Directorios (LDAP) ligero, listo para empresas, que ofrece características clave como identidad y autenticación, gestión de objetos de ordenador, directiva de grupo y relaciones de confianza.
- AD DS es un componente central en muchas organizaciones con un entorno de TI local y proporciona características principales de autenticación de cuentas de usuario y administración de equipos.
- Para más información, consulte Introducción a Active Directory Domain Services en la documentación de Windows Server.
- Microsoft Entra ID, gestión de identidades y dispositivos móviles basada en la nube que proporciona servicios de cuentas de usuario y autenticación para recursos como Microsoft 365, el Centro de administración de Microsoft Entra o aplicaciones SaaS.
- Microsoft Entra ID se puede sincronizar con un entorno de AD DS local para proporcionar una única identidad a los usuarios que funcionan de forma nativa en la nube.
- Para obtener más información sobre microsoft Entra ID, consulte ¿Qué es microsoft Entra ID?
- Microsoft Entra Domain Services: proporciona servicios de dominio administrados con un subconjunto de características tradicionales de AD DS totalmente compatibles, como la unión a un dominio, la directiva de grupo, LDAP y la autenticación Kerberos /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 la identidad central a las aplicaciones web tradicionales que se ejecutan en Azure como parte de una estrategia de traslado y adaptación (lift-and-shift).
- Para obtener más información sobre la sincronización con el identificador de Microsoft Entra y el entorno local, consulte Cómo se sincronizan los objetos y las credenciales en un dominio administrado.
En este artículo de información general se compara y contrasta cómo estas soluciones de identidad pueden funcionar juntas o se usarían de forma independiente, en función de las necesidades de su organización.
Domain Services y AD DS autoadministrado
Si tiene aplicaciones y servicios que necesitan acceso a mecanismos de autenticación tradicionales, como Kerberos o NTLM, hay dos maneras de proporcionar Active Directory Domain Services en la nube:
- Un dominio administrado que creas mediante Microsoft Entra Domain Services. Microsoft crea y administra los recursos necesarios.
- Un dominio de autoadministrado que se crea y configura mediante recursos tradicionales como máquinas virtuales (VM), sistema operativo invitado de Windows Server y Active Directory Domain Services (AD DS). Luego, continúa administrando estos recursos.
Con Domain Services, los componentes principales del servicio son desplegados y mantenidos para usted por Microsoft como una experiencia de dominio gestionada . No implementa, administra, parchea ni protege la infraestructura de AD DS para componentes como las máquinas virtuales, el sistema operativo Windows Server o los controladores de dominio.
Domain Services proporciona un subconjunto más pequeño de características al entorno de AD DS autoadministrado tradicional, lo que reduce parte de la complejidad de diseño y administración. Por ejemplo, no hay bosques de AD, dominios, sitios ni vínculos de replicación para diseñar o mantener. Todavía puede crear confianzas de bosque entre Domain Services y los entornos locales.
Para aplicaciones y 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 administrada con la cantidad mínima 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, debe mantener todos los componentes de directorio e infraestructura asociados. Hay una sobrecarga de mantenimiento con un entorno de AD DS autoadministrado, pero usted puede realizar tareas adicionales, como extender el esquema o establecer confianzas entre bosques.
Los modelos de implementación comunes para un entorno de AD DS autoadministrado que proporciona identidad a aplicaciones y servicios en la nube incluyen lo siguiente:
- AD DS independiente solo en la nube - Se configuran las máquinas virtuales de Azure como controladores de dominio y se crea un entorno de AD DS independiente solo en la nube. 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 y administrar máquinas virtuales en la nube.
- Ampliar el 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 al dominio del entorno local de AD DS.
- Una alternativa es crear máquinas virtuales de Azure y promoverlas como controladores de dominio de réplica desde el dominio de AD DS local. Estos controladores de dominio se replican a través de una conexión VPN o ExpressRoute al entorno de AD DS local. El dominio de AD DS local se extiende eficazmente a Azure.
En la tabla siguiente se describen algunas de las características que puede necesitar para su organización y 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 dominio de mediante NTLM y Kerberos | ✓ | ✓ |
| Delegación limitada de Kerberos | Basado 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 | ✓ (versión preliminar requiere SKU enterprise) | ✓ |
| 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 esos dispositivos. Los usuarios también pueden registrar su dispositivo personal (un modelo 'trae tu propio dispositivo' (BYO)) con Microsoft Entra ID, lo que le proporciona una identidad al dispositivo. A continuación, microsoft Entra ID autentica el dispositivo cuando un usuario inicia sesión en el identificador de Microsoft Entra y usa el dispositivo para acceder a los recursos protegidos. El dispositivo se puede administrar mediante software de administración de dispositivos móviles (MDM), como Microsoft Intune. Esta capacidad de administración permite restringir el acceso a recursos confidenciales a dispositivos administrados y compatibles con directivas.
Los equipos tradicionales y portátiles también se pueden unir a Microsoft Entra ID. Este mecanismo ofrece las mismas ventajas de registrar un dispositivo personal con el identificador de Entra de Microsoft, 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 la Tienda Windows para empresas mediante credenciales corporativas.
- Windows Hello para empresas.
- Acceso restringido a aplicaciones y recursos de dispositivos compatibles con la directiva corporativa.
Los dispositivos se pueden unir 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 comunes de propiedad de dispositivos y cómo se unirían normalmente a un dominio:
| tipo de dispositivo | Plataformas de dispositivo | Mecanismo |
|---|---|---|
| Dispositivos personales | Windows 10, iOS, Android, macOS | Microsoft Entra registrado |
| Dispositivo propiedad de la organización no unido a AD DS local | Windows 10 | Microsoft Entra se unió |
| Dispositivo propiedad de la organización unido a un AD DS local | Windows 10 | Unido a Microsoft Entra híbrido |
En un dispositivo registrado o unido a Microsoft Entra, la autenticación de usuarios se produce mediante protocolos modernos basados en OAuth o OpenID Connect. Estos protocolos están diseñados para funcionar a través de Internet, por lo que son excelentes para escenarios móviles en los que 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 pueden admitir aplicaciones heredadas migradas para ejecutarse en máquinas virtuales de Azure como parte de una estrategia de lift-and-shift. En la tabla siguiente se describen las diferencias en la forma en que se representan los dispositivos y se pueden autenticar en el directorio:
| Aspecto | Microsoft Entra se unió a | Unido a Domain Services |
|---|---|---|
| Dispositivo controlado por | Microsoft Entra ID | Dominio administrado de Domain Services |
| Representación en el directorio | Objetos de dispositivo en el directorio Microsoft Entra | Objetos de equipo en el dominio administrado de Domain Services |
| Autenticación | Protocolos basados en OAuth/OpenID Connect | Protocolos Kerberos y NTLM |
| Administración | Software de administración de dispositivos móviles (MDM), como Intune | Directiva de grupo |
| Gestión de redes | Funciona a través de Internet | Debe estar conectado o emparejado con la red virtual con la que se implementa el dominio administrado. |
| Genial para... | Dispositivos móviles o de escritorio de usuario final | Máquinas virtuales de servidor implementadas en Azure |
Si AD DS local y microsoft Entra ID están configurados para la autenticación federada mediante AD FS, 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 implementar la autenticación fed podrían tener un hash de contraseña antiguo, pero es probable que esto no coincida con un hash de su contraseña local. Como resultado, Domain Services no podrá validar las credenciales de los usuarios.
Pasos siguientes
Para empezar a usar los servicios de dominio, cree un dominio administrado mediante el Centro de administración de Microsoft Entra.
También puede obtener más información sobre los conceptos de administración de para cuentas de usuario, contraseñas y administración en Domain Services y cómo se sincronizan los objetos y las credenciales en un dominio administrado.