Migración de Entra ID / Azure AD (2025): estrategia integral — sincronización, federación, tenant-to-tenant, aplicaciones, seguridad y zero trust

1) Migración Entra ID / Azure AD: contexto, zero trust y cuándo conviene

La identidad es un pilar clave en una empresa. Migrar Entra ID no es trasladar usuarios de una lista a otra: es rediseñar cómo las personas y las aplicaciones se autentican, se autorizan y se auditan en un modelo de zero trust. Una buena migración simplifica la vida del usuario, reduce dependencias on-prem y sienta las bases para autenticación moderna (passkeys/FIDO2) y gobierno continuo.

• Cuándo conviene: fusiones o escisiones, consolidación de tenants, retirada de AD FS/STS, modernización de MFA/SSPR, multi-forest complejos, estandarización de seguridad entre filiales.
• Beneficios esperables: menos incidencias de acceso, menos prompts innecesarios, menor superficie de ataque, trazabilidad clara para auditoría y mejor adopción de M365/Azure/Teams.
• Qué toca: sincronización, autenticación, aplicaciones, dispositivos, políticas, red, operaciones y cumplimiento.

2) Descubrimiento y evaluación: dominios, UPN, apps, riesgos y licencias

Antes de decidir la ruta hay que conocer el terreno. El descubrimiento evita sorpresas, reduce re-trabajos y acelera la toma de decisiones. Es donde se gana o se pierde la migración.

2.1 Inventario de identidad

• Dominios: verificados/predeterminado, sufijos UPN, SIP/Teams y alias heredados; plan de limpieza y de verificación.
• Autoridad: AD DS, HRIS, SCIM, altas manuales; reglas de alta/cambio/baja (JML) y matching de identidades.
• Roles y grupos: propietarios claros, grupos administrativos, uso de PIM (activación JIT) y segregación de funciones.

2.2 Aplicaciones y dependencias

• Mapeo: protocolo (SAML/OIDC/WS-Fed), endpoints, certificados, reply URLs y claims especiales por app.
• Permisos Graph: diferenciar delegados vs application; localizar dependencias de APIs antiguas (Azure AD Graph, EWS básico).
• Workload identities: Service Principals y Managed Identities que usan automatizaciones/DevOps, y dónde residen.

2.3 Riesgos y cumplimiento

• Conditional Access: inventario de políticas, exclusiones “temporales” que llevan años, ubicaciones con confianza, named locations.
• Protocolos legados: POP/IMAP/EWS Básico, SMTP Auth; decidir bloqueos y excepciones transitorias con fecha de fin.
• Residencia/privacidad: requisitos UE, sectoriales y contractuales (ver EU Data Boundary).

2.4 Licenciamiento y costes

• Entra ID P1/P2: CA, Identity Protection, Access Reviews y Lifecycle Workflows.
• External ID: B2B/Direct Connect; modela consumo si hay colaboraciones masivas.
• Intune/Defender/Sentinel: si incluirás gestión de dispositivos, protección avanzada y observabilidad con KQL.

3) Plan de proyecto: gobierno, pilotos, oleadas, comunicaciones y KPIs

Un plan sólido reduce el estrés del día D. Define quién decide, qué se prueba, cómo se cortan dependencias y cómo se mide el avance. Menos improvisación, más previsibilidad.

3.1 Gobierno y RACI

3.2 Piloto (2–4 semanas)

• Incluye perfiles “difíciles”: VDI, viajeros, sedes con latencia, apps legacy y usuarios influyentes.
• Métricas útiles: tasa de inicio de sesión, prompts MFA por día, éxito SSO, latencia, tickets por 100 usuarios, apps críticas OK.
• Define criterios de salida: si no se cumplen, ajusta antes de escalar.

3.3 Oleadas y calendario

• Oleadas homogéneas por unidad/región para predecir soporte.
• Ventanas fuera de pico; evita cambios paralelos (ERP, DNS, red).
• Criterios por oleada: éxito > 98%, prompts controlados, CA sin bloqueos, apps validadas, reversibilidad documentada.

3.4 Comunicaciones “cortas y claras”

• T-7: qué cambia, por qué y beneficios (menos contraseñas, más seguridad).
• T-1: primeros pasos (registrar passkey/Authenticator), horarios y soporte.
• T0: acceso a portal, “qué hacer si…”, canal de ayuda en Teams/Service Desk.
• T+7: hábitos modernos (passwordless, compartir por vínculo, coautoría).

3.5 KPIs

• Tiempo a primer acceso productivo (minutos).
• Prompts MFA por usuario/día (debe bajar tras estabilizar CA).
• % de sesiones con SSO y % de sesiones passwordless.
• Tickets T0/T+7/T+30 y tiempo medio de resolución.

4) Sincronización híbrida Entra ID: Cloud Sync vs Connect (comparativa y decisión)

La sincronización es el “tornillo” que sostiene el resto. Elige el motor que simplifique la operación sin perder lo que necesitas: writebacks, reglas avanzadas o Exchange híbrido.

4.1 Diferencias clave

• Connect Sync: servidor on-prem con base y reglas; soporta password/device writeback y escenarios complejos.
• Cloud Sync: agentes ligeros; orquestación en Entra. Alta disponibilidad sencilla, multi-forest desconectado, ciclos rápidos y menos servidores.

4.2 Novedades que mueven la aguja

• Group writeback: escribir grupos de seguridad desde la nube a AD con Cloud Sync.
• Recomendación actual: priorizar Cloud Sync si no dependes de device writeback o personalizaciones muy específicas.

4.3 Cuándo usar cada uno

5) De AD FS a la nube: staged rollout paso a paso sin interrupciones

Pasar de federación a autenticación en la nube reduce complejidad, mejora resiliencia y habilita autenticación moderna (passkeys/FIDO2, TAP, CBA en la nube). Con staged rollout puedes pilotar, ampliar por grupos y cortar sin sobresaltos.

5.1 Estrategia de ejecución

1. Preparación: habilita PHS o PTA + Seamless SSO; verifica ciclos de sincronización e inicios de sesión de prueba.
2. Piloto por grupos: activa staged rollout para colectivos representativos; valida SSO, Outlook/Teams y apps SAML/OIDC (certificados y claims).
3. Corte final: convierte el dominio federado a administrado en ventana controlada; define rollback y checklist de validación.

5.2 Limitaciones y focos rojos

• Protocolos básicos POP/IMAP y clientes muy antiguos que no soportan flujos modernos.
• VDI no persistente sin PRT; quizá necesites excepciones temporales de CA.
• Integraciones con suposiciones rígidas de federación; revisa endpoints y claims.

6) Migración tenant-to-tenant y multitent: cross-tenant sync y Direct Connect

Fusiones, escisiones y grupos multinacionales exigen identidad que atraviese tenants sin duplicar personas. El objetivo: colaboración fluida con control central y reglas claras.

6.1 Modelos operativos

• Consolidación total: todo converge a un tenant “hub”.
• Multitent gobernado: cada compañía mantiene su tenant pero colabora bajo reglas comunes (B2B + Direct Connect).

6.2 Cross-tenant synchronization

• Provisiona usuarios B2B automáticamente en el tenant destino con atributos filtrados; evita altas manuales y errores.
• Auto-redemption para aceptación automática de invitaciones y experiencia sin fricción.

6.3 Cross-tenant access

• Confianzas de entrada/salida (MFA, dispositivo conforme, claims específicos) por organización y por aplicación.
• Direct Connect para Teams (canales compartidos) con experiencia nativa.

7) Migración de aplicaciones y workload identities (Microsoft Graph, SPN, RBAC)

La parte menos visible suele ser la que más impacta si se olvida. Trata cada aplicación como un mini-proyecto con su dueño, plan de certificados/secretos y pruebas firmadas.

7.1 App registrations y enterprise apps

• No existe “mover app” entre tenants: hay que recrear (manifest, permisos), volver a consentir y rotar secretos/certificados.
• Revisa reply URLs, audience, scopes y app roles; elimina dependencias de APIs en retirada y migra a Microsoft Graph.

7.2 Workload identities y Azure RBAC

• Si mueves suscripciones: recrea SPN/Managed Identities y reasigna roles mínimos necesarios.
• Automatiza rotaciones y revisa permisos excesivos con periodicidad.

8) External ID (B2B) y cross-tenant access: colaboración segura

La colaboración con partners y filiales debe ser fluida, pero gobernada. External ID centraliza políticas, excepciones y controles de entrada/salida.

• Define políticas por defecto y excepciones por organización.
• Usa plantillas de confianza: MFA requerido, dispositivo conforme y claims específicos para apps críticas.
• Activa expiración y Access Reviews periódicos para invitados.

9) Dispositivos, Microsoft Intune y Autopilot: re-registro y mínima fricción

Las identidades de usuario pueden “viajar” entre tenants; los dispositivos no. Planifica su re-registro para que la transición sea limpia y predecible.

• Ruta habitual: wipe/re-enroll o reset con Autopilot pre-registrado en el tenant destino.
• Minimiza fricción: Enrollment Status Page, cadena de apps crítica y drivers/firmware listos.
• CA y cumplimiento: exige dispositivo conforme/híbrido solo cuando el parque esté listo para ello.

10) Authentication Methods Policy: MFA, passkeys FIDO2 y certificate-based auth

Unifica la configuración heredada de MFA/SSPR y acelera el paso a passwordless. La migración es el momento idóneo para elevar el nivel sin castigar la experiencia.

1. Inventaria métodos en políticas antiguas y mapea grupos.
2. Activa “Migration in progress” y replica la configuración por grupos.
3. Valida, comunica y pasa a “Migration complete”.
4. Promueve FIDO2/passkeys y Authenticator resistente a phishing; evalúa CBA si encaja con tus casos.

11) Conditional Access e Identity Protection: políticas base y excepciones

El “mínimo razonable” protege sin romper. Menos políticas, mejor diseñadas, suelen valer más que muchos parches superpuestos.

11.1 Paquete base sugerido

• MFA por etapas (roles privilegiados y usuarios de riesgo primero; luego, toda la organización).
• Bloqueo de protocolos heredados (IMAP/POP/EWS básicos), con excepciones temporales y fecha de fin.
• Requisito de dispositivo conforme/híbrido para aplicaciones críticas.
• Control por ubicación (named locations) con moderación para no generar dependencias rígidas.

11.2 Identity Protection

• Políticas de riesgo de usuario/sesión con acciones “requerir MFA” o “bloquear”.
• Alertas de credenciales expuestas y compromised sign-ins con remediación documentada.

12) Red y rendimiento para identidad (endpoints Entra ID, TLS, proxies, split-tunnel)

Una red mal configurada puede arruinar un gran diseño de identidad. Prioriza salida directa a servicios de Microsoft y evita inspecciones que rompan TLS.

• No interceptes TLS (SSL break/inspect) hacia Entra/Exchange/Graph: causa fallos intermitentes difíciles de diagnosticar.
• Salida directa para dominios de Microsoft 365 (considera split-tunnel en VPN).
• Evita hairpinning entre sedes y ajusta DNS locales para latencias bajas.

openssl s_client -connect login.microsoftonline.com:443 -quiet -crlf

13) EU Data Boundary y residencia de datos en Entra ID

Si operas en la Unión Europea, la identidad forma parte del alcance de residencia. Documenta dónde se procesan y almacenan los datos y las salvaguardas aplicadas.

• Confirma regiones del tenant y servicios dependientes (logs, SIEM, copias).
• Describe flujos transfronterizos y medidas contractuales/técnicas.
• Coordina con DPO/Legal y refleja políticas internas de privacidad.

14) Suscripciones de Azure y directorios: mover sin perder el control

Cambiar una suscripción de directorio es posible, pero no “transparente”: perderás RBAC, custom roles y managed identities. Recréalo en destino y planifica una ventana.

• Valida dependencias (reservas/ahorros, acuerdos EA/MCA/CSP, políticas/guardrails).
• Controla la capacidad de mover con políticas y revisiones.
• Ten un plan de reversión si algo no aplica en el directorio de destino.

15) Telemetría y auditoría: Sign-in logs, KQL, alertas y reporting

Sin datos vuelas a ciegas. Mide éxito de inicios de sesión, prompts MFA, adopción de passwordless, uso de SSO y excepciones. La telemetría te permite corregir a tiempo.

• Sign-in logs: éxito, prompts MFA, métodos usados, ubicaciones y aplicaciones.
• Audit logs: cambios en CA, altas/bajas de apps, roles y credenciales.
• Detecciones: riesgo de usuario/sesión, credenciales expuestas, anomalías.

// Prompts MFA por app en la última semana SigninLogs | where TimeGenerated > ago(7d) | summarize Prompts=countif(AuthenticationRequirement == "multiFactorAuthentication") by AppDisplayName | order by Prompts desc

// Fallos de inicio de sesión por motivo (24h)
SigninLogs
| where TimeGenerated > ago(24h)
| summarize Count=count() by ResultType, ResultDescription
| order by Count desc

// Sesiones sin SSO (posible fricción)
SigninLogs
| where TimeGenerated > ago(7d)
| summarize NoSSO=countif(AuthenticationDetails has "singleFactorAuthentication") by AppDisplayName
| order by NoSSO desc

16) Operación tras la migración: runbooks, roles y mejora continua

Tras el día D llega la estabilización. Ajusta políticas, elimina excepciones temporales y profesionaliza el día a día con runbooks y responsabilidades claras.

16.1 Runbooks mínimos

• JML: Lifecycle Workflows + checklist de accesos (alta, cambio, baja).
• Invitados: expiración, Access Reviews y eliminación automática.
• Credenciales de apps: rotación de secretos/certificados y alertas previas a caducidad.
• Revisión de CA: cada 30/90 días (exclusiones, políticas inactivas, superposiciones).

16.2 Roles y soporte

• Soporte L1 con guías de passwordless/MFA y reinicio de apps.
• PIM para roles privilegiados (JIT + aprobación + tiempo limitado).
• Canal de champions para feedback de negocio y adopción.

16.3 Mejora continua

• Reduce prompts con SSO y PRT; elimina paquetes “legacy”.
• Audita workload identities y permisos excesivos; automatiza least privilege.
• Racionaliza aplicaciones duplicadas; mide impacto en soporte.

17) Apéndices: scripts (Graph/PowerShell), KQL, plantillas y checklists

Aquí tienes artefactos prácticos para ejecutar, medir y auditar tu proyecto.

17.A Script base — Microsoft Graph PowerShell (inventario rápido)

# Requiere Microsoft.Graph


Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Organization.Read.All","Domain.Read.All","Policy.Read.All","Application.Read.All","Directory.Read.All"

Get-MgOrganization | Select-Object Id, DisplayName, VerifiedDomains
Get-MgDomain | Select-Object Id, IsVerified, IsDefault, AuthenticationType

Políticas de CA (solo lectura)

Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State

Apps con permisos application

Get-MgServicePrincipal -All | Where-Object {$_.AppRoleAssignments -ne $null} | Select-Object DisplayName, AppId

17.B Checklist de corte — federado → nube

1. PHS/PTA + Seamless SSO habilitados y estables.
2. Staged rollout validado (grupos piloto, apps críticas, VDI si aplica).
3. Ventana de corte y plan de rollback documentado.
4. Convertir dominio a administrado; validar inicio de sesión, CA, apps y clientes.

17.C Plantillas de comunicación (3 × 3 líneas)

17.D Riesgos típicos y mitigación

• Aplicaciones rotas tras el corte: claims/certificados desalineados → matriz por app + pruebas firmadas.
• Prompts excesivos: políticas superpuestas → simplificar CA y usar una base común.
• VDI sin PRT: sesiones no persistentes → excepciones por ubicación + plan de modernización.
• Dispositivos: re-registro lento → Autopilot precargado y cadena de apps mínima.

18) Enlaces externos relacionados — documentación oficial y guías técnicas

Seleccionamos documentación oficial y guías técnicas para ampliar cada tema clave.

Sincronización híbrida (Cloud Sync vs Connect)

• Qué es Microsoft Entra Cloud Sync
• Qué es Microsoft Entra Connect (Azure AD Connect)
• Topologías y planificación de sincronización híbrida

De federación a autenticación en la nube (staged rollout)

• Staged rollout a autenticación en la nube
• Password Hash Sync (PHS): conceptos
• Pass-through Authentication (PTA): implementación
• Seamless SSO: habilitación y pruebas

Tenant-to-tenant y colaboración entre organizaciones

• Cross-tenant synchronization — visión general
• Cross-tenant access settings (External ID)
• B2B collaboration en Microsoft Entra External ID
• Organizaciones multi-tenant en Entra ID

Aplicaciones, Microsoft Graph y workload identities

• Migrar de Azure AD Graph a Microsoft Graph
• Microsoft Graph PowerShell — guía de inicio
• Managed identities para recursos de Azure
• Control de acceso basado en roles (Azure RBAC)

Métodos de autenticación, MFA y passwordless

• Migrar a Authentication Methods Policy
• Passwordless con FIDO2 / passkeys — despliegue
• Autenticación basada en certificados (CBA)
• Retirada de módulos AzureAD/MSOnline PowerShell

Seguridad: Conditional Access e Identity Protection

• Microsoft Entra Conditional Access — visión general
• Directivas comunes de CA
• Microsoft Entra ID Protection — visión general

Gobernanza de identidad

• Access Reviews — revisiones de acceso
• Entitlement Management — paquetes de acceso
• Lifecycle Workflows — automatización JML

Dispositivos, Intune y Autopilot

• Métodos de inscripción en Intune (Windows)
• Windows Autopilot — conceptos y requisitos

Red, DNS y endpoints

• URLs e intervalos IP de Microsoft 365
• Filtrado de tráfico y diagnóstico en Azure

Residencia de datos y cumplimiento

• Microsoft EU Data Boundary

Suscripciones de Azure y cambios de directorio

• Mover una suscripción de Azure a otro directorio

19) Preguntas frecuentes sobre migración Entra ID / Azure AD

Respuestas breves a dudas que suelen aparecer en comités de proyecto y con usuarios.

20) Glosario rápido de identidad

Términos que verás a lo largo del proyecto y conviene alinear con todos.

• PHS: Password Hash Sync. Sincroniza los hashes de contraseñas para autenticar en Entra.
• PTA: Pass-through Authentication. Valida contraseñas contra AD on-prem mediante agentes.
• PRT: Primary Refresh Token. Habilita SSO en dispositivos unidos a Entra/AD híbrido.
• SPN: Service Principal. Identidad de aplicación en un tenant.
• JML: Joiner–Mover–Leaver (alta, cambio, baja).
• CA: Conditional Access (políticas de acceso condicional).

21) Cierre: identidad como plataforma y siguientes pasos

El éxito no se mide en “usuarios migrados”, sino en riesgo reducido, operación simplificada y usuarios sin fricción. Si además avanzas hacia passwordless, gobiernas invitados y automatizas JML, tu identidad se convierte en la base de productividad y seguridad.