Transición a la nube

Después de alinear su organización con el objetivo de detener el crecimiento de la huella de Active Directory Domain Services (AD DS), puede enfocarse en trasladar las cargas de trabajo presenciales existentes a Microsoft Entra ID. En este artículo se describen las distintas series de tareas de migración. Puedes ejecutar las series de tareas de este artículo en función de tus prioridades y recursos.

Una serie de tareas de migración típica tiene las siguientes fases:

• Descubre: Descubre lo que tienes actualmente en tu entorno.

• Piloto: implementación de las nuevas funcionalidades en la nube en un pequeño subconjunto de usuarios, aplicaciones o dispositivos, en función de la serie de tareas.

• Escalabilidad horizontal: expansión del piloto para completar la transición de una funcionalidad a la nube.

• Transición (cuando corresponda): Dejar de utilizar la carga de trabajo local anterior.

Usuarios y grupos

Habilitación del autoservicio de contraseñas

Se recomienda un entorno sin contraseña. Hasta entonces, puedes migrar los flujos de trabajo de autoservicio de contraseñas desde los sistemas locales a Microsoft Entra ID para simplificar el entorno. El autoservicio de restablecimiento de contraseña (SSPR) de Microsoft Entra ID ofrece a los usuarios en la posibilidad de cambiar o restablecer su contraseña, sin necesidad de que intervengan el administrador ni el departamento de soporte técnico.

Para habilitar las funcionalidades de autoservicio, elige los métodos de autenticación adecuados para tu organización. Una vez actualizados los métodos de autenticación, podrás habilitar la funcionalidad de autoservicio de contraseña del usuario para el entorno de autenticación de Microsoft Entra. Para obtener una guía sobre la implementación, consulta Consideraciones de implementación para el autoservicio de restablecimiento de contraseña de Microsoft Entra.

Consideraciones adicionales:

• Implementa la protección de contraseñas de Microsoft Entra en un subconjunto de controladores de dominio con el modo de auditoría para recopilar información sobre el impacto de las directivas modernas.
• Habilita gradualmente el registro combinado de SSPR y autenticación multifactor de Microsoft Entra. Por ejemplo, puedes implementar por región, filial o departamento para todos los usuarios.
• Lleva a cabo un ciclo de cambio de contraseña para todos los usuarios para vaciar las contraseñas no seguras. Una vez completado el ciclo, implementa la hora de expiración de la directiva.
• Cambia la configuración de protección de contraseñas en los controladores de dominio que tengan el modo establecido en Forzado. Para obtener más información, consulta Habilitación de protección de contraseñas local de Microsoft Entra.

Traslado de la gestión de grupos

Para transformar grupos y listas de distribución:

• En el caso de los grupos de seguridad existentes creados en AD DS que ahora se usan exclusivamente para conceder acceso a los recursos en la nube, use la transferencia de la Fuente de Autoridad del Grupo (SOA) para convertir esos grupos en exclusivos para la nube. Administre la pertenencia a grupos desde la nube. A continuación, elimine el grupo de AD DS.
• En el caso de los grupos de seguridad existentes creados en AD DS que todavía necesitan mantener su presencia en AD, actualice el ámbito del grupo de Active Directory para que sea universal (si aún no lo está). A continuación, use Group SOA para convertir estos grupos en editables en la nube y administrar la pertenencia desde la nube. Por último, utilice el aprovisionamiento de grupos en AD DS para provisionar los cambios de la nube a AD, de manera que la pertenencia local permanezca sincronizada.
• Para la lógica de negocios que asigna usuarios a grupos de seguridad, evalúe si puede migrar la lógica a Entra ID y usar grupos de pertenencia dinámica.
• En el caso de las funcionalidades de grupo autoadministradas que proporciona Microsoft Identity Manager, reemplaza la funcionalidad por la administración de grupos de autoservicio.
• Puedes convertir listas de distribución en grupos de Microsoft 365 en Outlook. Este enfoque es una excelente manera de proporcionar a las listas de distribución de la organización todas las características y funcionalidades de los grupos de Microsoft 365.
• Actualice las listas de distribución a grupos de Microsoft 365 en Outlook.

Transfiera el aprovisionamiento de usuarios y grupos a las aplicaciones

Puedes simplificar el entorno al quitar los flujos de aprovisionamiento de aplicaciones de los sistemas de administración de identidades (IDM) locales, como Microsoft Identity Manager. En función de la detección de aplicaciones, clasifica la aplicación según las siguientes características:

• Aplicaciones de tu entorno que tienen una integración de aprovisionamiento con la galería de aplicaciones de Microsoft Entra.

• Aplicaciones que no están en la galería pero admiten el protocolo SCIM 2.0. Estas aplicaciones son compatibles de manera nativa con el servicio de aprovisionamiento en la nube de Microsoft Entra.

• Aplicaciones locales que tienen un conector ECMA disponible. Estas aplicaciones se pueden integrar con el aprovisionamiento de aplicaciones locales de Microsoft Entra.

Para obtener más información, consulta: Planeamiento de una implementación de aprovisionamiento automático de usuarios en Microsoft Entra ID.

Traslado al aprovisionamiento de RR. HH. en la nube

Puedes reducir tu huella local al migrar los flujos de trabajo de aprovisionamiento de RR. HH desde los sistemas IDM locales, como Microsoft Identity Manager, a Microsoft Entra ID. Existen dos tipos de cuenta disponibles para el aprovisionamiento de RR. HH. en la nube de Microsoft Entra:

• En el caso de los nuevos empleados que usen exclusivamente aplicaciones que usan Microsoft Entra ID, puede optar por aprovisionar cuentas solo en la nube. Este aprovisionamiento le ayuda a reducir la huella de AD DS.

• Para los nuevos empleados que necesitan acceso a las aplicaciones que dependen de AD DS, puede aprovisionar cuentas híbridas.

El aprovisionamiento de RR. HH. en la nube de Microsoft Entra también puede administrar cuentas de AD DS para empleados existentes. Para obtener más información, consulte Planeamiento de la aplicación de RR. HH en la nube para el aprovisionamiento de usuarios de Microsoft Entra y Planeamiento del proyecto de implementación.

Trasladar flujos de trabajo de ciclo de vida

Evalúe los flujos de trabajo y los procesos de incorporación, cambio de puesto y baja de empleados existentes en cuanto a su aplicabilidad y relevancia para su entorno en la nube de Microsoft Entra. A continuación, puede simplificar estos flujos de trabajo y crear otros nuevos mediante flujos de trabajo de ciclo de vida.

Traslado de la administración de identidades externas

Si su organización aprovisiona cuentas en AD DS u otros directorios locales para identidades externas, como proveedores, contratistas o consultores, puede simplificar su entorno administrando esos objetos de usuario de terceros de forma nativa en la nube. Estas son algunas posibilidades:

• Para nuevos usuarios externos, use Microsoft Entra External ID, que reduce la huella de AD DS de los usuarios.

• Para las cuentas de AD DS existentes que aprovisiona para identidades externas, puede quitar la sobrecarga de administrar credenciales locales (por ejemplo, contraseñas) configurándolas para la colaboración de negocio a negocio (B2B). Siga los pasos que se describen en Invitar a usuarios internos a la colaboración B2B.

• Use la administración de derechos de Microsoft Entra para conceder acceso a aplicaciones y recursos. La mayoría de las empresas tienen sistemas y flujos de trabajo dedicados para este propósito, que ahora pueden ser trasladados desde herramientas locales a soluciones en la nube.

• Use las revisiones de acceso para quitar derechos de acceso o identidades externas que ya no sean necesarias.

Dispositivos

Traslado de estaciones de trabajo que no sean de Windows

Puede integrar estaciones de trabajo que no son de Windows con Microsoft Entra ID para mejorar la experiencia del usuario y beneficiarse de las características de seguridad basadas en la nube, como el acceso condicional.

• Para macOS:

  • Registre macOS en Microsoft Entra ID e inscriba o adminístrelos mediante una solución de administración de dispositivos móviles.

  • Implemente el complemento Microsoft Enterprise SSO (inicio de sesión único) para dispositivos Apple.

  • Planeamiento de la implementación del inicio de sesión único de plataforma para macOS 13.

• En el caso de Linux, puede iniciar sesión en una máquina virtual (VM) Linux mediante credenciales de Microsoft Entra.

Sustitución de otras versiones de Windows para estaciones de trabajo

Si tiene los siguientes sistemas operativos en estaciones de trabajo, considere la posibilidad de actualizar a las versiones más recientes para beneficiarse de la administración nativa de la nube (unión a Microsoft Entra y administración unificada de puntos de conexión):

• Windows 7 u 8.x

• Servidor de Windows

Solución VDI

Este proyecto tiene dos iniciativas principales:

• Nuevas implementaciones: implemente una solución de infraestructura de escritorio virtual (VDI) administrada por la nube, como Windows 365 o Azure Virtual Desktop, que no requiere AD DS local.

• Implementaciones existentes: si la implementación de VDI existente depende de AD DS, use objetivos empresariales y objetivos para determinar si mantiene la solución o la migra a Microsoft Entra ID.

Para más información, consulte:

• Implementación de máquinas virtuales unidas a Microsoft Entra en Azure Virtual Desktop

• Guía de planificación de Windows 365

APLICACIONES

Para ayudar a mantener un entorno seguro, Microsoft Entra ID admite protocolos de autenticación modernos. Para realizar la transición de la autenticación de aplicaciones de AD DS a Microsoft Entra ID, debe hacer lo siguiente:

• Determinar qué aplicaciones se pueden migrar a Microsoft Entra ID sin modificaciones.

• Determinar qué aplicaciones tienen una ruta de actualización que le permita migrar con una actualización.

• Determinar qué aplicaciones requieren sustitución o cambios significativos en el código para su migración.

El resultado de la iniciativa de detección de aplicaciones consiste en la creación de una lista con prioridades que se use para migrar la cartera de aplicaciones. La lista también contiene aplicaciones que:

• Se requiere una mejora o actualización del software, y hay una ruta de actualización disponible.

• Requieren una actualización del software, pero no existe una ruta de actualización disponible.

Mediante la lista, puede evaluar más a fondo las aplicaciones que no tienen una ruta de actualización existente. Determine si el valor empresarial garantiza la actualización del software o si se debe retirar. Si el software debe retirarse, decida si necesita un reemplazo.

En función de los resultados, puede rediseñar los aspectos de la transformación de AD DS a Microsoft Entra ID. Hay enfoques que puede usar para ampliar AD DS local a la infraestructura como servicio (IaaS) de Azure (lift-and-shift) para aplicaciones con protocolos de autenticación no admitidos. Se recomienda establecer una directiva que requiera una excepción para usar este enfoque.

Detección de aplicaciones

Una vez hayas segmentado la cartera de aplicaciones, puedes priorizar la migración en función del valor y la prioridad empresarial. Puedes usar herramientas para crear o actualizar el inventario de aplicaciones.

Existen tres maneras principales de categorizar las aplicaciones:

• Aplicaciones de autenticación modernas: estas aplicaciones usan protocolos de autenticación modernos (como OIDC, OAuth2, SAML o WS-Federation) o protocolos que usan un servicio de federación, como Servicios de federación de Active Directory (AD FS) (AD FS).

• Herramientas de administración de acceso web (WAM): estas aplicaciones usan encabezados, cookies y técnicas similares para el inicio de sesión único. Normalmente, estas aplicaciones necesitan un proveedor de identidades WAM, como Symantec SiteMinder.

• Aplicaciones heredadas: estas aplicaciones usan protocolos heredados, como Kerberos, LDAP, Radius, Escritorio remoto y NTLM (no recomendado).

Microsoft Entra ID se puede usar con cada tipo de aplicación para proporcionar niveles de funcionalidad que dan lugar a diferentes estrategias de migración, complejidad e intercambios. Algunas organizaciones tienen un inventario de aplicaciones que se puede usar como línea base de detección. (Es habitual que este inventario no esté completo o actualizado).

Para detectar aplicaciones con autenticación moderna:

• Si usas AD FS, usa el informe de actividad de aplicaciones de AD FS.

• Si usas un proveedor de identidades diferente, puedes usar los registros y la configuración.

Las siguientes herramientas pueden ayudarte a detectar aplicaciones que usan LDAP:

• Event1644Reader: herramienta de ejemplo que se usa para recopilar datos de las consultas LDAP que se realizan a los controladores de dominio utilizando registros de ingeniería de campo.

• Microsoft 365 Defender para Identity: solución de seguridad que usa una funcionalidad de supervisión de operaciones de inicio de sesión. (Ten en cuenta que captura enlaces mediante LDAP, no LDAP seguro).

• PSLDAPQueryLogging: herramienta de GitHub para informar sobre consultas LDAP.

Migración de AD FS u otros servicios de federación

Cuando planees la migración a Microsoft Entra ID, considera la posibilidad de migrar primero las aplicaciones que usen protocolos de autenticación modernos (como SAML y Open ID Connect). Puedes volver a configurar estas aplicaciones para autenticarte con Microsoft Entra ID a través de un conector integrado de la galería de aplicaciones de Azure o mediante el registro en Microsoft Entra ID.

Una vez hayas trasladado las aplicaciones SaaS que estaban federadas a Microsoft Entra ID, hay que realizar algunos pasos para retirar el sistema de federación local:

• Trasladar la autenticación de aplicación al identificador de Microsoft Entra ID

• Migración del Servidor Azure Multi-Factor Authentication (servidor MFA) a la autenticación multifactor de Microsoft Entra

• Migración de la federación a la autenticación en la nube

• Trasladar el acceso remoto a las aplicaciones internas, si está utilizando el proxy de aplicaciones de Microsoft Entra

Traslado de aplicaciones con autenticación WAM

Este proyecto se centra en la migración de la capacidad de SSO de los sistemas WAM a Microsoft Entra ID. Para obtener más información, consulta Migración de aplicaciones desde Symantec SiteMinder a Microsoft Entra ID.

Definición de la estrategia de administración del servidor de aplicaciones

En términos de administración de la infraestructura, los entornos locales suelen usar una combinación de objetos de directiva de grupo (GPO) y funciones de Microsoft Configuration Manager para segmentar las tareas de administración. Por ejemplo, las funciones se pueden segmentar en administración de directivas de seguridad, administración de actualizaciones, administración de la configuración y supervisión.

AD DS es para entornos de TI locales y microsoft Entra ID es para entornos de TI basados en la nube. Aquí no hay paridad de uno a uno de las características, por lo que puede administrar servidores de aplicaciones de varias maneras.

Por ejemplo, Azure Arc ayuda a reunir muchas de las características que existen en AD DS en una sola vista cuando se usa Microsoft Entra ID para la administración de identidades y acceso (IAM). También puedes usar Microsoft Entra Domain Services para los servidores de unión a un dominio en Microsoft Entra ID, especialmente cuando deseas que esos servidores usen GPO por motivos empresariales o técnicos específicos.

Usa la tabla siguiente para determinar las herramientas basadas en Azure que se usan para reemplazar el entorno local:

A continuación se muestra más información que puede usar para la administración del servidor de aplicaciones:

• Azure Arc habilita las características de Azure en VM que no son de Azure. Por ejemplo, puede usarlo para obtener características de Azure para Windows Server cuando se use en el entorno local o en Amazon Web Services, o autenticarse en máquinas Linux con SSH.

• Administración y protección del entorno de máquina virtual de Azure.

• Si debe esperar para migrar o realizar una migración parcial, puede usar GPOs con Microsoft Entra Domain Services.

Si se requiere la administración de los servidores de aplicaciones con Microsoft Configuration Manager (MECM), no podrá lograr este requisito mediante Microsoft Entra Domain Services. No se admite Microsoft Configuration Manager para ejecutarse en un entorno de Microsoft Entra Domain Services. En su lugar, debe ampliar la instancia de AD DS local a un controlador de dominio que se ejecuta en una máquina virtual de Azure. O bien, debe implementar una nueva instancia de AD DS en una red virtual iaaS de Azure.

Definición de la estrategia de migración para aplicaciones heredadas

Las aplicaciones heredadas tienen dependencias como estas a AD DS:

• Autenticación y autorización de usuario: Kerberos, NTLM, enlace LDAP, ACL.

• Acceso a datos de directorio: consultas LDAP, extensiones de esquema, lectura o escritura de objetos de directorio.

• Administración del servidor: según lo determinado por la estrategia de administración del servidor.

Para reducir o eliminar esas dependencias, existen tres enfoques principales.

Enfoque 1

En el enfoque que más se prefiere, puede comenzar proyectos para migrar de aplicaciones heredadas a alternativas SaaS que usan autenticación moderna. Haga que las alternativas de SaaS se autentiquen directamente en Microsoft Entra ID:

1. Implemente Microsoft Entra Domain Services en una red virtual de Azure y amplíe el esquema para incorporar atributos adicionales necesarios para las aplicaciones.

2. Migración mediante lift-and-shift de las aplicaciones heredadas a las máquinas virtuales de la red virtual de Azure que están unidas a un dominio de Microsoft Entra Domain Services.

3. Publicar aplicaciones heredadas en la nube mediante el proxy de aplicaciones de Microsoft Entra o un socio de acceso híbrido seguro.

4. A medida que las aplicaciones heredadas se retiran por desuso, eventualmente desactivar Microsoft Entra Domain Services que se ejecuta en la red virtual de Azure.

Enfoque 2

Si el primer enfoque no es posible y una aplicación tiene una dependencia sólida de AD DS, puede ampliar AD DS local a IaaS de Azure.

Puede cambiar la plataforma para admitir el hospedaje sin servidor moderno; por ejemplo, use la plataforma como servicio (PaaS). O bien, puede actualizar el código para admitir la autenticación moderna. También puede habilitar la aplicación para que se integre directamente con Microsoft Entra ID. Obtenga información sobre la biblioteca de autenticación de Microsoft en la plataforma de identidad de Microsoft.

1. Conexión de una red virtual de Azure a la red local a través de una red privada virtual (VPN) o Azure ExpressRoute.

2. Implemente nuevos controladores de dominio para la instancia de AD DS local como máquinas virtuales en la red virtual de Azure.

3. Migración mediante lift-and-shift de aplicaciones heredadas a máquinas virtuales de la red virtual de Azure unidas a un dominio.

4. Publicar aplicaciones heredadas en la nube mediante el proxy de aplicaciones de Microsoft Entra o un socio de acceso híbrido seguro.

5. Finalmente, retire la infraestructura de AD DS local y ejecute AD DS en la red virtual de Azure por completo.

6. A medida que las aplicaciones heredadas se retiran por desgaste, finalmente se desmantela la instancia de AD DS que se ejecuta en la red virtual de Azure.

Enfoque 3

Si la primera migración no es posible y una aplicación tiene una dependencia sólida de AD DS, puede implementar una nueva instancia de AD DS en IaaS de Azure. Deje las aplicaciones como aplicaciones heredadas para el futuro próximo o elimínelas cuando tenga la oportunidad.

Este enfoque permite desacoplar la aplicación de la instancia de AD DS existente para reducir el área expuesta. Se recomienda que lo considere solo como último recurso.

1. Implemente una nueva instancia de AD DS como máquinas virtuales en una red virtual de Azure.

2. Traslade y adapte aplicaciones heredadas a máquinas virtuales en la red virtual de Azure que estén unidas a un dominio de la nueva instancia de AD DS.

3. Publicar aplicaciones heredadas en la nube mediante el proxy de aplicaciones de Microsoft Entra o un socio de acceso híbrido seguro.

4. A medida que las aplicaciones heredadas se retiran por desgaste, finalmente se desmantela la instancia de AD DS que se ejecuta en la red virtual de Azure.

Comparación de estrategias

Traslado de la autenticación de VPN

Este proyecto se centra en el traslado de la autenticación de VPN a Microsoft Entra ID. Es importante saber que existen distintas configuraciones disponibles para las conexiones de VPN Gateway. Es preciso determinar qué configuración es la que mejor se adapta a sus necesidades. Para obtener más información sobre el diseño de una solución, consulte Diseño de VPN Gateway.

Estos son algunos puntos clave sobre el uso de Microsoft Entra ID para la autenticación de VPN:

• Compruebe si los proveedores de VPN admiten la autenticación moderna. Por ejemplo:

  • Tutorial: Integración de SSO de Microsoft Entra con Cisco Secure Firewall - Secure Client

  • Tutorial: integración del inicio de sesión único Microsoft Entra con Palo Alto Networks GlobalProtect

• Si tiene dispositivos Windows 10, considere la posibilidad de integrar la compatibilidad de Microsoft Entra en el cliente VPN integrado.

• Después de evaluar este escenario, puede implementar una solución para quitar su dependencia local a fin de autenticarse en VPN.

Traslado del acceso remoto a aplicaciones internas

Para simplificar el entorno, puede usar el proxy de aplicación de Microsoft Entra o asociados de acceso híbrido seguro para proporcionar acceso remoto. Esto le permite eliminar la dependencia de las soluciones de proxy inverso locales.

Es importante mencionar que la habilitación del acceso remoto a una aplicación mediante las tecnologías anteriores es un paso provisional. Necesitas hacer más trabajo para desacoplar completamente la aplicación de AD DS.

Microsoft Entra Domain Services le permite migrar servidores de aplicaciones a iaaS en la nube y desacoplar desde AD DS, mientras usa el proxy de aplicación de Microsoft Entra para habilitar el acceso remoto. Para obtener más información sobre este escenario, consulte Implementación del proxy de aplicación de Microsoft Entra para Servicios de Dominio de Microsoft Entra.

Pasos siguientes

• Introducción
• Estrategia de transformación de la nube
• Establecer una huella de Microsoft Entra
• Implementar un enfoque prioritario en la nube