De Active Directory local a Azure AD (Microsoft Entra ID): guía completa para empresas

Resumen rápido: migrar de Active Directory local a Azure AD (Entra ID) en 10 puntos

1. Decidir el destino: híbrido (lo más habitual), cloud-only (cuando ya no se necesitan dominios) o mixto (por departamentos/sedes).
2. Inventario de dependencias: GPO, LDAP, NTLM/Kerberos, ficheros compartidos, apps heredadas, VPN, impresoras, RADIUS, ADFS y scripts.
3. Preparar identidades: limpiar AD (cuentas antiguas, UPN coherentes, grupos por rol, cuentas admin separadas), y definir estándar de nombres.
4. Configurar Entra ID: dominios verificados, roles, cuentas de emergencia (break-glass), registro de auditoría y línea base de seguridad.
5. Elegir sincronización: Entra Connect Sync o Cloud Sync según requisitos (writeback, multi-forest, personalización, Exchange híbrido, etc.).
6. Elegir autenticación: Password Hash Sync (PHS), Pass-through Authentication (PTA) o federación (ADFS/terceros) según necesidad real y riesgo.
7. Definir estrategia de dispositivos: Entra Join (recomendado para nuevos equipos), Hybrid Join (transición), Autopilot e Intune.
8. Modernizar el acceso: SSO a aplicaciones (SAML/OIDC), App Proxy para apps on-prem, y reducción gradual de protocolos heredados.
9. Seguridad y gobierno: MFA, Acceso Condicional, Identity Protection, PIM, Access Reviews, registros y alertas.
10. Operación y cierre: procedimientos, soporte, adopción, retirada de ADFS si aplica y plan de continuidad para sincronización/identidad.

Idea para situarse: el éxito no depende de “instalar un conector”, sino de encajar identidad, seguridad, dispositivos y aplicaciones en un plan con fases y validaciones.

Introducción: qué cambia al pasar de Active Directory local a Azure AD (Microsoft Entra ID)

Muchas empresas llevan años apoyándose en Active Directory Domain Services (AD DS) como núcleo de identidad: usuarios y grupos, PCs unidos a dominio, GPO, acceso a servidores y recursos internos, y aplicaciones que dependen de Kerberos/NTLM o LDAP. Ese modelo sigue siendo válido para determinados escenarios, pero hoy convive con una realidad clara: trabajo remoto, SaaS, dispositivos móviles, múltiples sedes y necesidad de controles de acceso más finos.

Azure AD (actualmente Microsoft Entra ID) no es “otro controlador de dominio en la nube”. Es un servicio de identidad cloud pensado para: autenticación moderna, SSO con aplicaciones, MFA, control por contexto (ubicación, dispositivo, riesgo), identidad de invitados (B2B) y gobierno de privilegios.

Por eso, “migrar de AD local a Azure AD” suele significar modernizar la forma de acceder a recursos y aplicaciones, y reducir dependencias que obligan a mantener un dominio tradicional para todo. En la práctica, el camino más sólido para empresas es: híbrido primero (sincronizar identidades y habilitar seguridad), y después avanzar hacia cloud-native donde tenga sentido.

Para conectar ideas: el resto de la guía se enfoca en decidir el destino, ordenar el AD actual, implementar sincronización y seguridad, y mover dispositivos y aplicaciones con el menor impacto posible.

1. Active Directory vs Azure AD (Entra ID): diferencias que afectan a la migración

Antes de planificar, conviene alinear expectativas. Muchas frustraciones vienen de asumir que Entra ID “hace lo mismo” que AD DS. Ambos gestionan identidades, pero su diseño y sus capacidades son distintas.

1.1 Qué hace bien Active Directory (AD DS)

• Unión a dominio de equipos Windows y administración tradicional de PCs y servidores.
• Kerberos/NTLM para autenticación contra recursos internos (file servers, apps heredadas).
• GPO como estándar histórico de configuración y endurecimiento.
• LDAP para aplicaciones antiguas y sistemas integrados.
• Estructura clásica (OUs), delegación granular y herramientas maduras de administración.

1.2 Qué hace bien Azure AD (Microsoft Entra ID)

• SSO y control de acceso para aplicaciones cloud y muchas on-prem modernizadas (SAML/OIDC/OAuth).
• MFA y Acceso Condicional con contexto (dispositivo, ubicación, riesgo, cumplimiento).
• Identidad de invitados (B2B) y colaboración con terceros con control y trazabilidad.
• Gobierno y privilegios con PIM, Access Reviews y políticas de roles.
• Integración nativa con Microsoft 365 y seguridad moderna (Identity Protection, Defender, etc.).

1.3 Implicación práctica

Resumen para respirar: Entra ID no sustituye automáticamente a AD DS. El proyecto consiste en decidir qué dependencias se mantienen, cuáles se modernizan y cómo se transita sin romper la operación.

2. Estrategias posibles: híbrido, cloud-only o modelo mixto por fases

No todas las empresas tienen el mismo punto de partida. El enfoque correcto depende de aplicaciones, dispositivos, sedes, requisitos regulatorios y del ritmo al que el negocio puede asumir cambios.

2.1 Identidad híbrida (lo más habitual)

La empresa mantiene AD DS para lo que todavía lo necesita (servidores, ciertos recursos internos, apps heredadas) y sincroniza identidades hacia Entra ID. A partir de ahí, Microsoft 365, SSO, MFA y Acceso Condicional se vuelven el estándar de acceso.

• Ventaja: permite avanzar sin “apagón” de lo heredado.
• Riesgo: si no se pone un plan de reducción de dependencias, lo híbrido se vuelve permanente “por inercia”.

2.2 Cloud-only (cuando ya no se necesita dominio para el día a día)

Suele ser viable cuando la mayoría de aplicaciones son SaaS, los equipos pueden gestionarse con Intune, y los recursos internos se han modernizado o están detrás de accesos controlados. En este modelo, los usuarios y dispositivos viven en Entra ID y la empresa reduce al mínimo infraestructura de identidad on-prem.

• Ventaja: simplifica operación y mejora seguridad con controles cloud.
• Riesgo: si existen dependencias “ocultas” (scripts, apps antiguas), el cambio se atasca.

2.3 Modelo mixto por fases (por áreas o por sedes)

Muy común en organizaciones con sedes o con equipos con necesidades distintas: por ejemplo, puestos de oficina cloud-native, pero entornos industriales o de planta con sistemas heredados que requieren AD DS.

• Ventaja: el negocio avanza donde hay más retorno, sin obligar a todo el mundo a cambiar a la vez.
• Riesgo: requiere gobernar bien para que no aparezcan “dos empresas” en identidad y soporte.

Resumen para conectar: una vez elegido el enfoque, el siguiente paso es ver “qué ata” hoy a la empresa a AD DS (GPO, LDAP, apps, ficheros). Sin ese inventario, la estrategia queda en teoría.

3. Assessment: inventario de dependencias (GPO, LDAP, apps, ficheros, VPN)

El assessment no es un documento bonito: es lo que evita sorpresas. El objetivo es responder a tres preguntas: qué identidades existen, qué depende del dominio y qué impacto tendrá cambiar el modelo.

3.1 Inventario de identidad

• Usuarios y atributos: UPN, mail, departamentos, ubicaciones, atributos inconsistentes y duplicados.
• Cuentas privilegiadas: Domain Admins, Enterprise Admins, cuentas de servicio, cuentas compartidas.
• Grupos: grupos por aplicación/rol, grupos anidados, uso real y grupos “históricos” sin dueño.
• Objetos obsoletos: cuentas sin inicio de sesión, equipos antiguos, cuentas de proveedor que nunca se cerraron.

3.2 Inventario de dispositivos

• Windows 10/11, versiones, compatibilidad con Autopilot/Intune, estado de cifrado (BitLocker).
• Equipos remotos: VPN, split-tunnel, dependencia de acceso a DCs para iniciar sesión.
• Dispositivos especiales: kioscos, equipos de planta, thin clients, VDI, etc.

3.3 Inventario de aplicaciones y autenticación

• Aplicaciones que autentican por LDAP o dependen de Kerberos/NTLM.
• Aplicaciones ya con SSO (SAML/OIDC) o con posibilidad de integrarse con Entra ID.
• Infra de federación: ADFS, proxies, certificados, dependencias y complejidad operativa.
• VPN, Wi-Fi empresarial, RADIUS/NPS: método de autenticación actual y modernización posible.

3.4 Inventario de políticas (GPO) y configuración

Aquí suele estar el “peso real” del dominio. No todas las GPO importan: muchas son históricas o redundantes. La clave es identificar cuáles son críticas (seguridad, hardening, proxy, certificados, scripts, drive mappings).

# Requiere RSAT ActiveDirectory
Import-Module ActiveDirectory

# Usuarios que no han iniciado sesión en 90 días (orientativo)
$cut = (Get-Date).AddDays(-90)
Get-ADUser -Filter * -Properties LastLogonDate |
  Where-Object {$_.Enabled -eq $true -and $_.LastLogonDate -lt $cut} |
  Select-Object SamAccountName,UserPrincipalName,LastLogonDate |
  Sort-Object LastLogonDate

Resumen de sección: el assessment define el “mapa de riesgos”. Con ese mapa, se puede preparar AD, preparar Entra ID y elegir sincronización/autenticación con criterio, sin descubrir dependencias en el peor momento.

4. Preparar Active Directory local antes de sincronizar (lo que ahorra problemas después)

Sincronizar un AD desordenado hacia Entra ID multiplica el desorden. Esta fase busca que identidad y grupos sean coherentes, que no existan duplicados y que el inicio de sesión en cloud sea predecible.

4.1 Unificar y corregir UPN (User Principal Name)

En Microsoft 365, el UPN suele convertirse en el identificador principal de inicio de sesión. Si la empresa tiene UPN antiguos (por ejemplo, “usuario@empresa.local” o dominios no públicos), conviene planificar el cambio a un dominio verificable.

• Definir dominio(s) UPN objetivo (normalmente el dominio corporativo público).
• Corregir usuarios con UPN duplicado, incompleto o incoherente con el correo.
• Planificar impacto: aplicaciones internas que dependan del UPN (pocas, pero existen).

4.2 Separar cuentas privilegiadas (y reducir exposición)

Una buena práctica es que los administradores tengan una cuenta de usuario normal y una cuenta administrativa separada. Además, conviene reducir pertenencias a grupos privilegiados y revisar delegación.

• Eliminar cuentas compartidas “admin” donde sea posible.
• Reducir grupos “super-admin” a lo mínimo.
• Documentar quién aprueba altas de privilegios y con qué criterio.

4.3 Revisar cuentas de servicio

En sincronizaciones híbridas, las cuentas de servicio suelen ser un punto débil. Se recomienda identificar:

• Servicios que usan credenciales antiguas o rotación inexistente.
• Servicios con permisos de dominio innecesarios.
• Aplicaciones que podrían moverse a autenticación moderna (service principals, certificados, managed identities en Azure, etc.).

4.4 Revisar estructura de grupos (pensando en cloud)

En Entra ID y M365, los grupos se usan para licencias, acceso a apps, políticas y, en general, para operar “por rol”. Conviene preparar grupos con sentido: por departamento, por función, por acceso a apps, por dispositivos, etc.

$allowedDomains = @("empresa.com","empresa.es")
Get-ADUser -Filter * -Properties UserPrincipalName |
  Where-Object {
    $_.UserPrincipalName -and ($allowedDomains -notcontains ($_.UserPrincipalName.Split("@")[1]))
  } |
  Select-Object SamAccountName,UserPrincipalName

Resumen para respirar: esta fase evita que Entra ID reciba identidades inconsistentes. Un UPN bien definido, cuentas privilegiadas ordenadas y grupos por rol hacen que la siguiente fase (tenant + sincronización) sea mucho más estable.

5. Preparar Microsoft Entra ID (Azure AD): tenant, dominios y línea base

Antes de sincronizar un solo usuario, el tenant debe estar preparado para operar con seguridad. Esto incluye dominios verificados, cuentas de emergencia, roles definidos y un mínimo de controles (auditoría, MFA, Acceso Condicional).

5.1 Verificar dominios y definir identidad principal

• Verificar el dominio corporativo (DNS) y decidir el dominio de inicio de sesión principal.
• Definir estrategia si existen varios dominios (por marca, por país, por unidad de negocio).
• Evitar “parches” temporales que luego se quedan años (por ejemplo, dominios onmicrosoft como login estándar).

5.2 Crear cuentas de emergencia (break-glass)

En identidades cloud, la empresa necesita al menos dos cuentas de emergencia independientes para recuperar acceso si: hay un problema con MFA, un error en Acceso Condicional o un incidente con el proveedor de identidad.

• Dos cuentas cloud-only, protegidas y con control de acceso estricto.
• Contraseñas robustas y custodia definida (procedimiento documentado).
• Exclusiones controladas de algunas políticas, pero con vigilancia y alertas.

5.3 Definir roles y administración

Conviene evitar que “todo el mundo sea Global Admin”. Se recomienda operar por roles: administración de usuarios, administración de dispositivos, seguridad, cumplimiento, etc.

• Roles mínimos por función.
• Uso de cuentas administrativas separadas.
• Plan para PIM (privilegios bajo demanda) si se dispone de licenciamiento.

5.4 Establecer línea base de seguridad

• MFA para administradores desde el día 1.
• Bloqueo o limitación de autenticaciones heredadas donde aplique.
• Registro y retención de logs: auditoría y sign-in logs (según licencias).

Resumen: con el tenant preparado, ya se puede elegir cómo sincronizar identidades y qué método de autenticación tendrá la empresa. Esa elección determina experiencia de usuario, riesgo y carga operativa.

6. Sincronización de identidades: Entra Connect Sync vs Cloud Sync (cómo elegir sin complicarse)

Para la mayoría de empresas, la sincronización es el puente entre AD local y Entra ID. No existe una única opción válida siempre: depende de la complejidad del entorno y de lo que se necesite “de vuelta” hacia on-prem (writeback).

6.1 Entra Connect Sync (clásico en entornos complejos)

Suele elegirse cuando se necesitan capacidades avanzadas: múltiples bosques, reglas de sincronización complejas, escenarios híbridos con Exchange, o ciertas necesidades de writeback. Es un componente instalado on-prem, con su motor de sincronización local.

6.2 Entra Cloud Sync (modelo más ligero y gestionado)

En Cloud Sync, el agente on-prem es más ligero y parte de la configuración y lógica se gestiona desde el cloud. Es una opción atractiva para entornos más simples o para empresas que quieren reducir complejidad operativa.

6.3 Comparativa práctica (lo que normalmente decide)

6.4 Requisitos y continuidad

La sincronización es un servicio crítico: si se para, altas/bajas y cambios de usuario se retrasan y pueden aparecer incidencias. Por eso se recomienda:

• Plan de continuidad (por ejemplo, staging mode en Connect Sync, o procedimientos equivalentes en Cloud Sync).
• Monitorización y alertas (salud de sincronización, errores de exportación/importación).
• Procedimientos de cambio: cuándo se actualiza, quién lo hace y cómo se valida.

Resumen: la sincronización mueve identidades, pero la experiencia del usuario la define el método de autenticación. El siguiente paso es elegir cómo iniciará sesión la organización (PHS, PTA o federación) y cómo se hará el cambio sin sustos.

7. Autenticación: Password Hash Sync (PHS), Pass-through Authentication (PTA) y federación (ADFS)

En términos sencillos: sincronizar usuarios no es lo mismo que autenticar usuarios. La empresa debe decidir dónde se valida el inicio de sesión y qué ocurre si los sistemas on-prem no están disponibles.

7.1 Password Hash Synchronization (PHS)

Con PHS, Entra ID recibe un hash (no la contraseña en claro) y puede validar el inicio de sesión en la nube. Es un enfoque muy extendido porque simplifica operación, reduce dependencias y da alta disponibilidad “por diseño” al estar la validación en el cloud.

• Cuándo encaja: mayoría de empresas que quieren reducir complejidad y dependencia de on-prem.
• Punto clave: la empresa debe gestionar bien el cambio cultural si existía federación (ADFS) y hábitos heredados.

7.2 Pass-through Authentication (PTA)

Con PTA, Entra ID redirige la validación a agentes on-prem que comprueban la contraseña contra AD DS. Suele elegirse cuando se quiere mantener validación local por requisitos internos, aunque implica dependencia de conectividad y de agentes.

• Cuándo encaja: organizaciones con requisitos específicos de validación on-prem.
• Riesgo: si los agentes fallan o hay problemas de red, el inicio de sesión puede degradarse.

7.3 Federación (ADFS u otros IdP)

La federación fue durante años el estándar en grandes organizaciones, pero también añade infraestructura, certificados, proxies, monitorización y puntos de fallo. Hoy muchas empresas revisan si realmente se necesita.

• Cuándo encaja: requisitos muy específicos o integraciones que dependen de federación.
• Enfoque recomendado: si se desea reducir complejidad, planificar migración de federación a autenticación cloud con pilotos y validación.

7.4 Migraciones controladas: staged rollout (cuando se viene de ADFS)

Cuando la empresa ya está federada, lo prudente es evitar un “todo o nada”. El staged rollout permite activar autenticación cloud para un subconjunto de usuarios (por grupos) y validar experiencia, políticas y aplicaciones antes del corte total.

Resumen: con sincronización y autenticación definidas, el siguiente gran bloque es dispositivos. Ahí se decide si la empresa sigue anclada al “PC unido a dominio” o si adopta Entra Join e Intune como estándar, manteniendo transición donde sea necesario.

8. Dispositivos: Entra Join, Hybrid Join, Autopilot, Intune y Windows Hello for Business

En muchas empresas, el punto que más “se nota” no es la sincronización: es el dispositivo. Cambiar de dominio clásico a un modelo cloud transforma el alta de equipos, el soporte y la seguridad.

8.1 Entra Join (Azure AD Join) para nuevos equipos

Para equipos nuevos, suele ser la opción recomendada: el dispositivo se une directamente a Entra ID y se gestiona con Intune. Se aplica configuración, hardening, aplicaciones corporativas y cumplimiento (compliance) desde MDM.

• Ventaja: reduce dependencia de DCs y VPN para el inicio de sesión.
• Impacto: GPO deja de ser el mecanismo, se reemplaza por políticas MDM (Intune).

8.2 Hybrid Join como transición

En organizaciones con dependencias fuertes de dominio, el híbrido permite que el equipo siga unido a AD DS y, a la vez, se registre en Entra ID para acceso cloud y Conditional Access. Es útil como fase intermedia, pero conviene que tenga una fecha de caducidad si el objetivo es cloud-native.

8.3 Autopilot: aprovisionamiento moderno

Autopilot permite estandarizar el alta de equipos: el usuario recibe un dispositivo, inicia sesión con su identidad corporativa y el sistema se configura solo. En empresas con alta rotación o con múltiples sedes, suele aportar un retorno muy rápido.

8.4 Windows Hello for Business (WHfB) y acceso a recursos on-prem

WHfB permite un modelo passwordless (PIN/biometría) y reduce exposición de contraseñas. En escenarios híbridos, existe el reto típico: “¿cómo accede un equipo Entra Joined a un recurso on-prem (file server) sin pedir credenciales constantemente?”.

Para ese caso, se suelen diseñar modelos como Cloud Kerberos trust, que ayudan a mantener acceso a recursos on-prem con una experiencia más fluida, siempre bajo diseño y validación.

Install-Script -Name Get-WindowsAutopilotInfo -Force
Get-WindowsAutopilotInfo -OutputFile .\AutopilotDevices.csv

Resumen: dispositivos listos significa que la empresa puede aplicar Conditional Access basado en “dispositivo conforme” y elevar seguridad sin frenar. El siguiente bloque es aplicaciones: integrar SSO, reducir credenciales y decidir qué hacer con apps heredadas.

9. Aplicaciones y SSO: modernizar acceso con Entra ID (SAML/OIDC), App Proxy y casos heredados

El valor inmediato de Entra ID suele verse en aplicaciones: un inicio de sesión con SSO, MFA cuando corresponde y control por contexto. La empresa reduce contraseñas repetidas y gana trazabilidad.

9.1 Clasificar aplicaciones por “tipo de modernización”

• SaaS con SAML/OIDC: integración directa con Entra ID y políticas CA/MFA por rol.
• Aplicaciones on-prem web: evaluar publicación segura con Entra Application Proxy y SSO.
• Aplicaciones heredadas: LDAP/NTLM, clientes pesados, integraciones antiguas: decidir si se mantienen con AD DS, se encapsulan o se modernizan.

9.2 Patrón recomendado: SSO primero, modernización después

Cuando el objetivo es reducir riesgo y fricción, suele funcionar bien:

1. Habilitar SSO en apps prioritarias (por impacto y criticidad).
2. Aplicar MFA/CA en accesos sensibles (administración, finanzas, acceso externo).
3. Revisar apps heredadas una por una, evitando “proyectos monstruo” sin entregas.

9.3 Apps heredadas con LDAP: opciones realistas

Si existen dependencias LDAP, hay tres caminos habituales:

• Mantener AD DS para esas apps (híbrido), mientras se planifica su modernización.
• Usar Microsoft Entra Domain Services en Azure para escenarios donde se necesita dominio gestionado para VMs/apps en Azure.
• Modernizar la app (ideal, pero no siempre posible por coste o proveedor).

Resumen: con identidades y aplicaciones en marcha, el siguiente gran reto es “sustituir GPO” sin perder seguridad ni control. Ese salto se hace mejor con método: analizar GPO, mover lo que aplica a Intune, y dejar solo lo imprescindible en dominio durante transición.

10. De GPO a Intune: trasladar políticas de dominio a MDM sin romper la configuración

Este punto separa los proyectos que avanzan de los que se estancan. Muchas organizaciones han acumulado GPO durante años: algunas son críticas, muchas son históricas. Migrar sin inventario suele terminar en “nadie se atreve a tocar nada”.

10.1 Método recomendado (práctico)

1. Inventariar GPO y agrupar por objetivo: seguridad, navegador/proxy, Windows Update, BitLocker, certificados, scripts.
2. Identificar lo crítico: lo que sin ello se pierde seguridad o operación (por ejemplo, hardening básico, certificados, proxy).
3. Buscar equivalentes en Intune: Settings Catalog, Security Baselines, Endpoint Security.
4. Probar en piloto: un conjunto de usuarios/equipos representativos antes de extender.
5. Documentar excepciones: lo que queda en dominio temporalmente y por qué.

10.2 Casos típicos y su “traducción”

Resumen: con dispositivos gestionados y políticas modernas, la empresa puede elevar seguridad con Conditional Access de forma efectiva. A partir de aquí, el foco pasa a seguridad avanzada (MFA/CA/Identity Protection) y a gobierno (PIM, revisiones, ciclo de vida).

11. Seguridad en Entra ID: MFA, Acceso Condicional, Identity Protection y endurecimiento

Este es uno de los motivos principales por los que las empresas dan el paso: reducir riesgo de acceso indebido. Entra ID permite políticas que en el mundo on-prem eran difíciles de aplicar de forma consistente.

11.1 MFA (por rol y por riesgo)

• MFA obligatorio para administradores desde el inicio.
• MFA para usuarios según contexto: acceso externo, apps sensibles, riesgo de inicio de sesión.
• Evitar “MFA para todo sin excepciones” sin plan: puede generar fricción si no hay preparación y soporte.

11.2 Acceso Condicional (Conditional Access)

El valor real llega cuando CA se diseña con escenarios:

• Acceso a Microsoft 365 desde fuera: exigir MFA y, si aplica, dispositivo conforme.
• Apps críticas (finanzas, ERP, administración): políticas más estrictas.
• Bloqueo de autenticación heredada y restricciones por ubicación/riesgo cuando aplique.

11.3 Identity Protection (cuando se dispone)

Permite detectar riesgos (por ejemplo, credenciales expuestas, inicios de sesión anómalos) y responder con políticas automáticas o revisiones. Es especialmente útil cuando la empresa quiere un enfoque “preventivo” en vez de solo reactivo.

11.4 “Higiene” de seguridad que suele mejorar resultados

• Bloqueo de protocolos obsoletos donde sea viable.
• Reducir el número de Global Admins.
• Separar cuentas administrativas y activar privilegios bajo demanda con PIM.
• Registro y alertas: auditoría, cambios de roles, accesos sospechosos.

Resumen: seguridad sin gobierno se degrada con el tiempo. El siguiente paso es poner orden en “quién tiene qué acceso”, cómo se aprueba, cómo se revisa y cómo se retira cuando cambia una persona o un proveedor.

12. Gobierno de identidad: PIM, Access Reviews, grupos y ciclo de vida (Joiner/Mover/Leaver)

En entornos híbridos o cloud-native, el reto no es crear usuarios: es mantener accesos correctos con el paso de los meses. Cuando no hay gobierno, aparecen privilegios permanentes, invitados eternos y accesos que ya no deberían existir.

12.1 PIM (Privileged Identity Management)

Permite que roles privilegiados se activen bajo demanda, con justificación, aprobación y duración limitada. Es una de las medidas que más reduce el riesgo de cuentas administrativas comprometidas.

12.2 Access Reviews y recertificación

Revisar accesos no es burocracia si se hace bien: es reducir superficie de exposición. Casos típicos:

• Revisión trimestral de grupos con acceso a apps críticas.
• Revisión periódica de invitados (B2B) por proyecto o por cliente.
• Revisión de grupos con permisos administrativos o de administración de dispositivos.

12.3 Grupos por rol y automatización de ciclo de vida

A nivel operativo, los accesos se gestionan mejor por grupos y roles. El objetivo es que “alta/baja” sea predecible:

• Altas: asignación automática a grupos por departamento/función cuando sea posible.
• Movimientos: cambio de rol = cambio de grupos, no permisos manuales dispersos.
• Bajas: retirada completa, revocación de sesiones, cierre de accesos externos y cuentas invitadas asociadas si aplica.

Resumen: una identidad moderna debe operar incluso en incidentes: caída de sincronización, error de CA, pérdida de acceso administrativo. Por eso el siguiente bloque se centra en continuidad, monitorización y operación diaria.

13. Continuidad y operación: monitorización, cuentas de emergencia y alta disponibilidad

En entornos de identidad, la continuidad es clave. Si algo se rompe, impacta en toda la empresa. Esta sección busca que el paso a Entra ID no cree una “caja negra” difícil de operar.

13.1 Alta disponibilidad de sincronización

En Connect Sync, es habitual preparar un servidor en staging mode como standby. En Cloud Sync, se planifica despliegue y resiliencia de agentes según recomendaciones.

• Procedimiento de failover: quién decide, qué se hace, cómo se valida.
• Calendario de actualizaciones y pruebas post-cambio.
• Alertas: fallos de sync, objetos con error, exportaciones bloqueadas.

13.2 Operación diaria: registros, auditoría y alertas

• Revisión de eventos relevantes: cambios de roles, creación de apps, consentimientos.
• Control de accesos anómalos: inicios de sesión desde ubicaciones extrañas, riesgo elevado.
• Integración con SIEM si aplica (para seguridad centralizada).

13.3 Cuentas de emergencia (break-glass) y simulacros

No basta con crear cuentas de emergencia: hay que definir un procedimiento y ensayar el uso en condiciones controladas.

• Custodia: quién guarda credenciales y cómo se accede.
• Auditoría: alertas si se usan, y revisión post-uso.
• Escenarios: bloqueo accidental por CA, caída de MFA, incidente de identidad.

Resumen: con operación estable, la empresa puede empezar a retirar dependencias que ya no aportan (o que añaden riesgo). La retirada no se hace “de golpe”: se hace por componentes y con puntos de control claros.

14. Retirada gradual de dependencias on-prem (ADFS, LDAP, NTLM) y “cierre” del proyecto

En proyectos híbridos, el error típico es quedarse “en mitad” para siempre. La retirada gradual evita mantener infraestructura innecesaria y reduce superficie de ataque.

14.1 Retirar ADFS (si aplica)

Si la empresa venía federada, conviene decidir si la federación sigue siendo necesaria. Si no lo es, se planifica migración a autenticación cloud con piloto, staged rollout y validación de aplicaciones.

14.2 Reducir autenticación heredada

NTLM, autenticación básica o integraciones antiguas suelen ser focos de riesgo. No se eliminan “a ciegas”: se identifican dependencias y se moderniza por prioridad.

14.3 LDAP y apps antiguas

Si hay apps con LDAP que no se pueden modernizar a corto plazo:

• Se mantiene AD DS para esas apps (y se endurece la exposición).
• Se evalúa moverlas a Azure y, si se necesita dominio gestionado, valorar Entra Domain Services.
• Se negocia con proveedor una ruta de modernización cuando sea viable.

Resumen: en lugar de un cambio único, la empresa llega a un modelo estable por fases. Para hacerlo tangible, a continuación se propone un plan por fases con puntos de control y entregables.

15. Plan por fases (ejemplo realista) para pasar de AD local a Azure AD (Entra ID)

Cada empresa ajusta fases y orden, pero este ejemplo refleja un camino común que reduce riesgo: estabilizar identidad, asegurar accesos, y luego mover dispositivos y aplicaciones.

Fase 0 — Preparación y diseño

• Assessment: dependencias, inventario de identidades, GPO, apps, dispositivos.
• Decisión de estrategia: híbrido/cloud-only/mixto y objetivos por trimestre.
• Diseño de seguridad: MFA/CA por escenarios, cuentas de emergencia, roles y gobierno.

Fase 1 — Tenant y sincronización

• Configurar tenant Entra ID, dominios, roles y línea base.
• Preparar AD: UPN, limpieza, cuentas privilegiadas, grupos por rol.
• Implementar Entra Connect Sync o Cloud Sync, con monitorización.

Fase 2 — Autenticación y seguridad

• Elegir PHS/PTA/federación y ejecutar transición (si aplica staged rollout).
• Aplicar MFA y CA por oleadas (primero admins, luego accesos externos, luego apps críticas).
• Validar operación: incidentes, soporte, logs y procedimientos.

Fase 3 — Dispositivos e Intune

• Piloto de dispositivos Entra Joined con Intune.
• Autopilot para altas nuevas y estrategia para equipos existentes.
• Traslado gradual de GPO críticas a Intune, con piloto y métricas.

Fase 4 — Aplicaciones y retirada de dependencias

• SSO en apps prioritarias (SaaS y on-prem publicables).
• Modernización de apps heredadas según impacto.
• Retirada de ADFS (si procede) y reducción de autenticación heredada.

Resumen: el plan por fases funciona cuando se acompaña de checklists claros. A continuación se incluyen checklists operativos para convertir la guía en tareas ejecutables.

16. Checklists operativos (preparación, despliegue y post)

16.1 Checklist de preparación

• Inventario de dependencias (apps, GPO, LDAP, ADFS, dispositivos, VPN, Wi-Fi).
• UPN objetivo definido y plan de corrección de inconsistencias.
• Cuentas privilegiadas separadas y roles definidos.
• Tenant preparado: dominios, break-glass, auditoría, línea base.
• Diseño de CA/MFA por escenarios y calendario de despliegue por oleadas.

16.2 Checklist de despliegue (sync + auth)

• Entra Connect Sync / Cloud Sync configurado y validado.
• Monitorización y alertas de sincronización activas.
• Método de autenticación elegido y probado con usuarios piloto.
• Aplicaciones críticas validadas con el método elegido.
• Procedimientos: rollback, soporte, comunicación a usuarios.

16.3 Checklist de despliegue (dispositivos)

• Piloto Autopilot/Intune completado con usuarios representativos.
• Políticas básicas: cifrado, hardening, actualizaciones, antivirus/EDR (si aplica), configuración de navegadores.
• Equivalencias GPO→Intune definidas para lo crítico.
• Soporte y guías para el usuario (inicio de sesión, acceso a recursos, autoservicio).

16.4 Checklist post-despliegue

• Revisión de accesos: roles, privilegios y grupos críticos.
• Revisión de invitados y accesos externos.
• Revisión de logs y alertas (incidencias, intentos anómalos).
• Plan de retirada de dependencias heredadas con fechas objetivo.

Resumen: con el plan y checklists, lo que suele quedar son dudas recurrentes (¿sustituye a un DC?, ¿qué pasa con servidores?, ¿qué pasa con LDAP?). Por eso se incluye una sección de FAQ ampliada.

17. Preguntas frecuentes (FAQ) sobre migración de Active Directory local a Azure AD (Entra ID)

18. Recursos oficiales y enlaces recomendados

• Microsoft Entra Connect (documentación)
• Microsoft Entra Cloud Sync (documentación)
• Elegir método de autenticación híbrida (PHS/PTA/Federation)
• Staged rollout (migración controlada desde federación)
• Concepto de Microsoft Entra hybrid join
• Configurar Microsoft Entra hybrid join
• Windows Hello for Business (guía de despliegue)
• Cloud Kerberos trust (WHfB) — guía
• Microsoft Entra Domain Services (documentación)
• LDAP en escenarios Entra (visión de arquitectura)
• Microsoft Intune (documentación)
• Acceso Condicional (documentación)
• Microsoft Entra ID Protection
• Identity Governance (PIM, Access Reviews)

Servicios relacionados de MSAdvance: Modern Workplace, Seguridad Microsoft 365 y catálogo de servicios.

19. Conclusión: cómo pasar de Active Directory local a Azure AD (Entra ID) sin improvisar

El paso de Active Directory local a Azure AD (Microsoft Entra ID) no es un “cambio de herramienta”: es una evolución del modelo de identidad. Funciona cuando se apoya en cuatro pilares: inventario realista (dependencias), identidad ordenada (UPN, grupos y privilegios), seguridad bien diseñada (MFA/CA/gobierno) y transición por fases (dispositivos y apps).

Como siguientes pasos, suele ser útil:

• Realizar assessment de dependencias (apps, GPO, LDAP, dispositivos) y definir el destino (híbrido o cloud-only).
• Preparar AD y el tenant Entra ID antes de sincronizar (UPN, cuentas privilegiadas, break-glass, roles).
• Elegir sync y autenticación con criterio (Connect Sync/Cloud Sync; PHS/PTA/federación) y pilotar.
• Planificar dispositivos e Intune por oleadas y trasladar políticas críticas desde GPO con método.
• Modernizar acceso a aplicaciones con SSO y retirar dependencias heredadas según prioridad.