Casos de uso y escenarios comunes para Microsoft Entra Domain Services

Microsoft Entra Domain Services proporciona servicios de dominio administrados, como unión a un dominio, directiva de grupo, protocolo ligero de acceso a directorios (LDAP) y autenticación Kerberos/NTLM. Microsoft Entra Domain Services se integra con el inquilino de Microsoft Entra existente, lo que permite a los usuarios iniciar sesión con sus credenciales existentes. Estos servicios de dominio se usan sin necesidad de implementar, administrar y aplicar revisiones a los controladores de dominio en la nube, lo que proporciona una migración más fluida de los recursos locales a Azure.

En este artículo se describen algunos escenarios empresariales comunes en los que Microsoft Entra Domain Services proporciona valor y satisface esas necesidades.

Formas comunes de proporcionar soluciones de identidad en la nube

Al migrar cargas de trabajo existentes a la nube, las aplicaciones compatibles con directorios pueden usar LDAP para el acceso de lectura o escritura a un directorio de AD DS local. Las aplicaciones que se ejecutan en Windows Server normalmente se implementan en máquinas virtuales (VM) unidas a un dominio para que se puedan administrar de forma segura mediante la directiva de grupo. Para autenticar a los usuarios finales, las aplicaciones también pueden confiar en la autenticación integrada de Windows, como la autenticación Kerberos o NTLM.

Los administradores de TI suelen usar una de las siguientes soluciones para proporcionar un servicio de identidad a las aplicaciones que se ejecutan en Azure:

• Configure una conexión VPN de sitio a sitio entre cargas de trabajo que se ejecutan en Azure y un entorno de AD DS local.
  • A continuación, los controladores de dominio locales proporcionan autenticación a través de la conexión VPN.
• Cree controladores de dominio de réplica mediante máquinas virtuales (VM) de Azure para ampliar el dominio o bosque de AD DS desde el entorno local.
  • Los controladores de dominio que se ejecutan en máquinas virtuales de Azure proporcionan autenticación y replican información de directorio entre el entorno de AD DS local.
• Implemente un entorno de AD DS independiente en Azure mediante controladores de dominio que se ejecutan en máquinas virtuales de Azure.
  • Los controladores de dominio que se ejecutan en máquinas virtuales de Azure proporcionan autenticación, pero no hay información de directorio replicada desde un entorno de AD DS local.

Con estos enfoques, las conexiones VPN al directorio local hacen que las aplicaciones sean vulnerables a errores o interrupciones de red transitorios. Si implementa controladores de dominio mediante máquinas virtuales en Azure, el equipo de TI debe administrar las máquinas virtuales y, después, proteger, revisar, supervisar, realizar copias de seguridad y solucionar problemas.

Microsoft Entra Domain Services ofrece alternativas a la necesidad de volver a crear conexiones VPN a un entorno de AD DS local o ejecutar y administrar máquinas virtuales en Azure para proporcionar servicios de identidad. Como servicio administrado, Microsoft Entra Domain Services reduce la complejidad de crear una solución de identidad integrada para entornos híbridos y solo en la nube.

Comparación de Microsoft Entra Domain Services con el identificador de Microsoft Entra y AD DS autoadministrado en máquinas virtuales de Azure o locales

Microsoft Entra Domain Services para organizaciones híbridas

Muchas organizaciones ejecutan una infraestructura híbrida que incluye cargas de trabajo de aplicaciones locales y en la nube. Las aplicaciones heredadas migradas a Azure como parte de una estrategia de lift-and-shift pueden usar conexiones LDAP tradicionales para proporcionar información de identidad. Para admitir esta infraestructura híbrida, la información de identidad de un entorno de AD DS local se puede sincronizar con un inquilino de Microsoft Entra. A continuación, Microsoft Entra Domain Services proporciona estas aplicaciones heredadas en Azure con un origen de identidad, sin necesidad de configurar y administrar la conectividad de aplicaciones de nuevo a los servicios de directorio locales.

Echemos un vistazo a un ejemplo de Litware Corporation, una organización híbrida que ejecuta recursos locales y de Azure:

• Las aplicaciones y las cargas de trabajo de servidor que requieren servicios de dominio se implementan en una red virtual en Azure.
  • Esto puede incluir aplicaciones heredadas migradas a Azure como parte de una estrategia de lift-and-shift.
• Para sincronizar la información de identidad desde su directorio local a su inquilino de Microsoft Entra, Litware Corporation implementa Microsoft Entra Connect.
  • La información de identidad que se sincroniza incluye cuentas de usuario y pertenencias a grupos.
• El equipo de TI de Litware habilita Microsoft Entra Domain Services para su inquilino de Microsoft Entra en este o una red virtual emparejada.
• Las aplicaciones y máquinas virtuales implementadas en la red virtual de Azure pueden usar características de Microsoft Entra Domain Services, como unión a un dominio, lectura LDAP, enlace LDAP, autenticación NTLM y Kerberos y directiva de grupo.

Importante

Microsoft Entra Connect solo debe instalarse y configurarse para la sincronización con entornos de AD DS locales. No se admite la instalación de Microsoft Entra Connect en un dominio administrado para volver a sincronizar objetos con Microsoft Entra ID.

Microsoft Entra Domain Services para organizaciones exclusivamente en la nube

Una entidad de Microsoft Entra que opera exclusivamente en la nube no tiene una fuente de identidad local. Las cuentas de usuario y las pertenencias a grupos, por ejemplo, se crean y administran directamente en el identificador de Microsoft Entra.

Ahora echemos un vistazo a un ejemplo de Contoso, una organización solo en la nube que usa microsoft Entra ID para la identidad. Todas las identidades de usuario, sus credenciales y pertenencias a grupos se crean y administran en el identificador de Microsoft Entra. No hay ninguna configuración adicional de Microsoft Entra Connect para sincronizar ninguna información de identidad desde un directorio local.

• Las aplicaciones y las cargas de trabajo de servidor que requieren servicios de dominio se implementan en una red virtual en Azure.
• El equipo de TI de Contoso habilita Microsoft Entra Domain Services para su inquilino de Microsoft Entra en este o una red virtual emparejada.
• Las aplicaciones y máquinas virtuales implementadas en la red virtual de Azure pueden usar características de Microsoft Entra Domain Services, como unión a un dominio, lectura LDAP, enlace LDAP, autenticación NTLM y Kerberos y directiva de grupo.

Administración segura de máquinas virtuales de Azure

Para permitirle usar un único conjunto de credenciales de AD, las máquinas virtuales (VM) de Azure se pueden unir a un dominio administrado de Microsoft Entra Domain Services. Este enfoque reduce los problemas de administración de credenciales, como el mantenimiento de cuentas de administrador local en cada máquina virtual o la separación de cuentas y contraseñas entre entornos.

Las máquinas virtuales unidas a un dominio administrado también se pueden administrar y proteger mediante la directiva de grupo. Las líneas base de seguridad necesarias se pueden aplicar a las máquinas virtuales para bloquearlas de acuerdo con las directrices de seguridad corporativas. Por ejemplo, puede usar funcionalidades de administración de directivas de grupo para restringir los tipos de aplicaciones que se pueden iniciar en la máquina virtual.

Echemos un vistazo a un escenario de ejemplo común. A medida que los servidores y otras infraestructuras llegan al final del ciclo de vida, Contoso quiere mover aplicaciones hospedadas actualmente de forma local a la nube. Su estándar de TI actual exige que los servidores que hospedan aplicaciones corporativas deben estar unidos a un dominio y administrarse mediante la directiva de grupo.

El administrador de TI de Contoso prefiere unir las máquinas virtuales a un dominio en Azure para facilitar la administración, ya que los usuarios pueden iniciar sesión con sus credenciales corporativas. Cuando se une a un dominio, las máquinas virtuales también se pueden configurar para cumplir las líneas base de seguridad necesarias mediante objetos de directiva de grupo (GPO). Contoso prefiere no implementar, supervisar y administrar sus propios controladores de dominio en Azure.

Microsoft Entra Domain Services es una excelente opción para este caso de uso. Un dominio administrado le permite unir máquinas virtuales a un dominio, usar un único conjunto de credenciales y aplicar la directiva de grupo. Y como es un dominio administrado, no es necesario configurar y mantener los controladores de dominio usted mismo.

Notas de implementación

Las siguientes consideraciones de implementación se aplican a este caso de uso de ejemplo:

• Los dominios administrados usan una única estructura de unidad organizativa plana (OU) de forma predeterminada. Todas las máquinas virtuales unidas a un dominio se encuentran en una sola unidad organizativa. Si lo desea, puede crear unidades organizativas personalizadas.
• Microsoft Entra Domain Services utiliza un GPO integrado para cada uno de los contenedores de equipos y usuarios. Para tener un control adicional, puede crear directivas de grupo personalizadas (GPO) y asignarlas a unidades organizativas personalizadas.
• Microsoft Entra Domain Services admite el esquema de objetos de equipo de AD base. No se puede extender el esquema del objeto de computadora.

Migración mediante lift-and-shift de las aplicaciones locales que usan la autenticación de enlace LDAP

Como escenario de ejemplo, Contoso tiene una aplicación local que se compró de un ISV hace muchos años. La aplicación está actualmente en modo de mantenimiento por el ISV y la solicitud de cambios en la aplicación es prohibitivamente costosa. Esta aplicación tiene un front-end basado en web que recopila credenciales de usuario mediante un formulario web y, a continuación, autentica a los usuarios mediante la realización de un enlace LDAP al entorno de AD DS local.

Contoso quiere migrar esta aplicación a Azure. La aplicación debe seguir funcionando as-is, sin necesidad de realizar ningún cambio. Además, los usuarios deben poder autenticarse con sus credenciales corporativas existentes y sin entrenamiento adicional. Debe ser transparente para los usuarios finales en los que se ejecuta la aplicación.

En este escenario, Microsoft Entra Domain Services permite a las aplicaciones realizar enlaces LDAP como parte del proceso de autenticación. Las aplicaciones locales heredadas pueden migrar mediante lift-and-shift a Azure y continuar seguir autenticando a los usuarios sin ningún cambio en la configuración o la experiencia del usuario.

Notas de implementación

Las siguientes consideraciones de implementación se aplican a este caso de uso de ejemplo:

• Asegúrese de que la aplicación no necesita modificar o escribir en el directorio. No se admite el acceso de escritura LDAP a un dominio administrado.
• No se pueden cambiar las contraseñas directamente en un dominio administrado. Los usuarios finales pueden cambiar su contraseña mediante el mecanismo de cambio de contraseña de autoservicio de Microsoft Entra o en el directorio local. Estos cambios se sincronizan y están disponibles automáticamente en el dominio administrado.

Migración mediante lift-and-shift de las aplicaciones locales que usan la lectura LDAP para acceder al directorio

Al igual que en el escenario de ejemplo anterior, supongamos que Contoso tiene una aplicación de línea de negocio (LOB) local que se desarrolló hace casi una década. Esta aplicación es consciente del directorio y se diseñó para usar LDAP para leer información o atributos sobre los usuarios de AD DS. La aplicación no modifica atributos ni escribe en el directorio.

Contoso quiere migrar esta aplicación a Azure y retirar el hardware local antiguo que hospeda actualmente esta aplicación. La aplicación no se puede volver a escribir para usar api de directorio modernas, como la API de Microsoft Graph basada en REST. Se desea una opción de lift-and-shift en la que se puede migrar la aplicación para que se ejecute en la nube, sin modificar el código ni volver a escribir la aplicación.

Para ayudar con este escenario, Microsoft Entra Domain Services permite a las aplicaciones realizar lecturas LDAP en el dominio administrado para obtener la información de atributo que necesita. No es necesario volver a escribir la aplicación, por lo que una migración mediante lift-and-shift en Azure permite a los usuarios seguir usando la aplicación sin darse cuenta de que hay un cambio en el lugar donde se ejecuta.

Notas de implementación

Las siguientes consideraciones de implementación se aplican a este caso de uso de ejemplo:

• Asegúrese de que la aplicación no necesita modificar o escribir en el directorio. No se admite el acceso de escritura LDAP a un dominio administrado.
• Asegúrese de que la aplicación no necesita un esquema personalizado o extendido de Active Directory. No se admiten extensiones de esquema en Microsoft Entra Domain Services.

Migración de un servicio o aplicación de daemon en las instalaciones a Azure

Algunas aplicaciones incluyen varios niveles, donde uno de los niveles necesita realizar llamadas autenticadas a un nivel de back-end, como una base de datos. Las cuentas de servicio de AD se usan normalmente en estos escenarios. Al migrar mediante lift-and-shift las aplicaciones en Azure, Microsoft Entra Domain Services le permite seguir usando cuentas de servicio de la misma manera. Puede optar por usar la misma cuenta de servicio que se sincroniza desde el directorio local con el identificador de Microsoft Entra o crear una unidad organizativa personalizada y, a continuación, crear una cuenta de servicio independiente en esa unidad organizativa. Con cualquiera de estos enfoques, las aplicaciones siguen funcionando de la misma manera para realizar llamadas autenticadas a otros niveles y servicios.

En este escenario de ejemplo, Contoso tiene una aplicación de almacén de software personalizada que incluye un front-end web, un servidor SQL Server y un servidor FTP back-end. La autenticación integrada de Windows mediante cuentas de servicio autentica el front-end web en el servidor FTP. El front-end web está configurado para ejecutarse como una cuenta de servicio. El servidor back-end está configurado para autorizar el acceso desde la cuenta de servicio para el front-end web. Contoso no quiere implementar y administrar sus propias máquinas virtuales del controlador de dominio en la nube para mover esta aplicación a Azure.

En este escenario, los servidores que hospedan el front-end web, SQL Server y el servidor FTP se pueden migrar a máquinas virtuales de Azure y unirse a un dominio administrado. Después, las máquinas virtuales pueden usar la misma cuenta de servicio en su directorio local con fines de autenticación de la aplicación, que se sincroniza a través de Microsoft Entra ID mediante Microsoft Entra Connect.

Notas de implementación

Las siguientes consideraciones de implementación se aplican a este caso de uso de ejemplo:

• Asegúrese de que las aplicaciones usan un nombre de usuario y una contraseña para la autenticación. Microsoft Entra Domain Services no admite la autenticación basada en tarjetas inteligentes o certificados.
• No se pueden cambiar las contraseñas directamente en un dominio administrado. Los usuarios finales pueden cambiar su contraseña mediante el mecanismo de cambio de contraseña de autoservicio de Microsoft Entra o en el directorio local. Estos cambios se sincronizan y están disponibles automáticamente en el dominio administrado.

Implementaciones de servicios de Escritorio remoto de Windows Server en Azure

Puede usar Microsoft Entra Domain Services para proporcionar servicios de dominio administrados a servidores de Escritorio remoto implementados en Azure.

Para obtener más información sobre este escenario de implementación, consulte cómo integrar Microsoft Entra Domain Services con la implementación de RDS.

Clústeres de HDInsight unidos a un dominio

Puede configurar un clúster de Azure HDInsight que esté unido a un dominio administrado con Apache Ranger habilitado. Puede crear y aplicar directivas de Hive a través de Apache Ranger y permitir a los usuarios, como científicos de datos, conectarse a Hive mediante herramientas basadas en ODBC como Excel o Tableau. Seguimos trabajando para incluir otras cargas de trabajo, como HBase, Spark y Storm a HDInsight unido a un dominio.

Para más información sobre este escenario de implementación, consulte configuración de clústeres de HDInsight unidos a un dominio.

Pasos siguientes

Para empezar, cree y configure un dominio administrado de Microsoft Entra Domain Services.