Compartir a través de

Transición a la nube

  • Artículo

Después de alinear la organización para detener el crecimiento de la superficie de Active Directory, puede centrarse en trasladar las cargas de trabajo locales existentes a Microsoft Entra ID. En este artículo se describen las distintas series de tareas de migración. Puede ejecutar las series de tareas de este artículo en función de sus prioridades y recursos.

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

  • Detección: averiguar lo que tiene actualmente en su 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): fin del uso de 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, puede 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, elija los métodos de autenticación adecuados para su organización. Una vez actualizados los métodos de autenticación, podrá 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, consulte Consideraciones de implementación para el autoservicio de restablecimiento de contraseña de Microsoft Entra.

Consideraciones adicionales:

Nota:

Traslado de grupos de administración

Para transformar grupos y listas de distribución:

  • En el caso de los grupos de seguridad, use la lógica de negocios existente que asigna usuarios a grupos de seguridad. Migre la lógica y la funcionalidad a Microsoft Entra ID y grupos dinámicos.

  • En el caso de las funcionalidades de grupo autoadministradas que proporciona Microsoft Identity Manager, reemplace la funcionalidad por la administración de grupos de autoservicio.

  • Puede 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 y retire el servidor local de Exchange.

Traslado del aprovisionamiento de usuarios y grupos a aplicaciones

Puede simplificar el entorno al eliminar 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, clasifique la aplicación según las siguientes características:

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

Traslado al aprovisionamiento de RR. HH. en la nube

Puede reducir la huella superficie local al trasladar los flujos de trabajo de aprovisionamiento de RR. HH de 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 ayuda a contener la superficie de Active Directory.

  • En el caso de los nuevos empleados que necesiten acceso a aplicaciones que tengan dependencias en Active Directory, puede aprovisionar cuentas híbridas.

El aprovisionamiento de RR. HH. en la nube de Microsoft Entra también puede administrar cuentas de Azure Active Directory de los 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 unión, movimiento y abandono del usuario existentes para la aplicabilidad y relevancia del 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 la organización aprovisiona cuentas en Active Directory u otros directorios locales para identidades externas, como proveedores, contratistas o consultores, puede simplificar el entorno al administrar esos objetos de usuario de terceros de manera nativa en la nube. Estas son algunas posibilidades:

  • En el caso de los nuevos usuarios externos, use Id. externa de Microsoft Entra, lo que detiene la superficie de Active Directory de los usuarios.

  • En el caso de las cuentas de Active Directory existentes que aprovisione para identidades externas, puede quitar la sobrecarga de la administración de credenciales locales (por ejemplo, contraseñas) mediante su configuración para la colaboración de empresa a empresa (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 puede trasladar desde las herramientas locales.

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

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

  • Windows Server

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 Active Directory local.

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

Para más información, consulte:

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 Active Directory 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:

  • Requieren una actualización del software y existe 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 algunos aspectos de la transformación de Active Directory a Microsoft Entra ID. Existen enfoques que puede usar para ampliar Active Directory local a la infraestructura como servicio (IaaS) de Azure (lift-and-shift) para las 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 haya segmentado la cartera de aplicaciones, puede priorizar la migración en función del valor y la prioridad empresarial. Puede 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:

Las siguientes herramientas pueden ayudarle 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 mediante los 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. (Tenga 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 planee la migración a Microsoft Entra ID, considere la posibilidad de migrar primero las aplicaciones que usen protocolos de autenticación modernos (como SAML y Open ID Connect). Puede volver a configurar estas aplicaciones para autenticarse 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 haya trasladado las aplicaciones SaaS que estaban federadas a Microsoft Entra ID, hay que realizar algunos pasos para retirar el sistema de federación local:

Importante

Si usa otras características, compruebe que esos servicios se han reubicado antes de retirar los Servicios de federación de Active Directory (AD FS).

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, consulte 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.

Active Directory es para entornos de TI locales y Microsoft Entra ID 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 Active Directory en una sola vista cuando se usa Microsoft Entra ID para la administración de identidad y acceso (IAM). También puede usar Microsoft Entra Domain Services para los servidores de unión a un dominio en Microsoft Entra ID, especialmente cuando desea que esos servidores usen GPO por motivos empresariales o técnicos específicos.

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

Área de administración Característica local (Active Directory) Característica de Microsoft Entra equivalente
Administración de directivas de seguridad. GPO, Microsoft Configuration Manager Microsoft 365 Defender for Cloud
Administración de actualizaciones Microsoft Configuration Manager, Windows Server Update Services Update Management en Azure Automation
Administración de configuración GPO, Microsoft Configuration Manager State Configuration de Azure Automation
Supervisión System Center Operations Manager Log Analytics de Azure Monitor

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

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 lugar de esto, debe ampliar la instancia de Active Directory local a un controlador de dominio que se ejecuta en una VM de Azure. O bien, debe implementar una nueva instancia de Active Directory en una red virtual de IaaS de Azure.

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

Las aplicaciones heredadas tienen dependencias como estas en Active Directory:

  • 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. Publicación de aplicaciones heredadas en la nube mediante el proxy de aplicación de Microsoft Entra o un asociado de acceso híbrido seguro.

  4. A medida que las aplicaciones heredadas se retiran por abandono, retirada final de la instancia de Microsoft Entra Domain Services que se ejecuta en la red virtual de Azure.

Nota:

Enfoque 2

Si no es posible usar el primer enfoque y una aplicación tiene una dependencia fuerte de Active Directory, puede ampliar Active Directory 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. Implementación de nuevos controladores de dominio para Active Directory local como máquinas virtuales en la red virtual de Azure.

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

  4. Publicación de aplicaciones heredadas en la nube mediante el proxy de aplicación de Microsoft Entra o un asociado de acceso híbrido seguro.

  5. Con el tiempo, retire la infraestructura de Active Directory local y ejecute Active Directory en la red virtual de Azure por completo.

  6. A medida que las aplicaciones heredadas se retiran por abandono, con el tiempo eliminan la instancia de Active Directory 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 fuerte de Active Directory, podrá implementar una nueva instancia de Active Directory 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 Active Directory existente para reducir el área expuesta. Se recomienda que lo considere solo como último recurso.

  1. Implementación de una nueva instancia de Active Directory como máquinas virtuales en una red virtual de Azure.

  2. Migración mediante lift-and-shift de las aplicaciones heredadas a VM de la red virtual de Azure, que están unidas a un dominio de la nueva instancia de Active Directory.

  3. Publicación de aplicaciones heredadas en la nube mediante el proxy de aplicación de Microsoft Entra o un asociado de acceso híbrido seguro.

  4. A medida que las aplicaciones heredadas se retiran por abandono, con el tiempo eliminan la instancia de Active Directory que se ejecuta en la red virtual de Azure.

Comparación de estrategias

Estrategia Servicios de dominio de Microsoft Entra Extensión de Active Directory a IaaS Instancia independiente de Active Directory en IaaS
Desacoplamiento de Active Directory local Sí No Sí
Permitir extensiones de esquema No Sí Sí
Control administrativo completo No Sí Sí
Posible reconfiguración de las aplicaciones necesarias (por ejemplo, ACL o autorización) Sí No Sí

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:

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. Debe realizar más operaciones para desacoplar completamente la aplicación de Active Directory.

Microsoft Entra Domain Services permite migrar servidores de aplicaciones a IaaS en la nube y desacoplarlos de Active Directory, 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 DS.

Pasos siguientes