Guía para migrar autoridad de identidad de AD a Entra ID y desmantelar controladores de dominio

Problema

Muchas organizaciones que iniciaron su transformación digital con un modelo híbrido (on‑premises AD + Azure AD) llegan a un punto donde la gestión completa de identidades en la nube es más rentable y ágil. El reto consiste en trasladar la autoridad de identidad a Microsoft Entra ID (Azure AD) y, una vez confirmada la operatividad, retirar los controladores de dominio locales, AAD Connect y los servicios que todavía dependen de AD. La dificultad radica en que los pasos no están estandarizados: distintas fuentes (Copilot, Google AI, documentación oficial) pueden sugerir órdenes diferentes, y una acción prematura (por ejemplo, desactivar la sincronización antes de limpiar atributos de Exchange) puede dejar usuarios sin acceso o romper flujos de correo.

Causa

Los escenarios que generan confusión suelen compartir varios factores:

Sincronización unidireccional sin write‑back – Cuando AAD Connect solo replica objetos de AD a Entra ID, los cambios posteriores en la nube no vuelven a on‑premises. Desactivar la sincronización antes de migrar atributos críticos (proxyAddress, mail, etc.) deja datos desactualizados en AD.
Dependencias ocultas – Servicios como Exchange on‑premises, GPOs, scripts de login o aplicaciones que consultan atributos de AD pueden seguir activos aunque los usuarios ya estén en la nube.
Servicios de infraestructura (DHCP/DNS) todavía en los DC – Si la red sigue usando los servidores DNS de los DC, la eliminación prematura de los controladores puede provocar fallos de resolución de nombres internos.
Falta de pruebas de “cloud‑only” – Sin validar que todos los dispositivos están Azure AD Joined o Hybrid Azure AD Joined y que las políticas de Intune funcionan, la retirada del dominio local puede generar problemas de inscripción y acceso a recursos.
Orden de operaciones – Algunas guías recomiendan desactivar atributos de Exchange antes de cortar la sincronización, otras lo hacen después. La causa es que Exchange sigue leyendo atributos de AD para la gestión de buzones on‑premises; si esos atributos desaparecen antes de que la replicación a la nube sea completa, los buzones quedan “huérfanos”.

Solución

A continuación se describe un proceso paso a paso que funciona en la mayoría de los entornos híbridos con Windows Server 2012 R2, Exchange 2013 y AAD Connect. El objetivo es transferir la autoridad de identidad a Entra ID y desmantelar los DC sin interrumpir usuarios ni servicios críticos.

1. Auditoría de dependencias

Ejecuta un inventario de objetos que todavía dependen de AD (usuarios, grupos, equipos, contactos, objetos de Exchange). Herramientas útiles: Get-ADObject, Get-ADUser -Properties * | Where-Object {$_.ProxyAddresses -match "SMTP:"} y los reportes de AAD Connect.
Verifica que todos los dispositivos estén Azure AD Joined o Hybrid Azure AD Joined y gestionados por Intune. Usa dsregcmd /status en una muestra representativa.
Confirma que DHCP/DNS pueden migrarse a otro equipo (por ejemplo, al firewall UniFi) sin perder resolución interna.

2. Preparar Exchange para “cloud‑only”

En Exchange 2013, desactiva la sincronización de atributos que ya están en Entra ID. Ejecuta:
```
Set-RemoteMailbox -Identity <User> -EmailAddresses @{Remove="SMTP:<oldaddress>"}
```
Migra los buzones restantes a Exchange Online usando el asistente de migración (cut‑over o staged). Asegúrate de que el atributo mail y proxyAddresses estén presentes en Entra ID después de la migración.
Una vez que todos los buzones estén en la nube y los usuarios tengan licencias de Exchange Online, desconecta el conector híbrido:
```
Remove-HybridConfiguration
```

3. Consolidar atributos en Entra ID

Habilita Password Writeback (opcional, pero recomendado) para que los cambios de contraseña en la nube se reflejen en AD mientras los DC siguen activos.

Ejecuta una sincronización completa:

# PowerShell en el servidor AAD Connect
Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Initial

Verifica que todos los atributos críticos (mail, proxyAddresses, userPrincipalName, SID) estén presentes y correctos en Entra ID mediante Azure AD PowerShell:
```
Get-AzureADUser -ObjectId <UPN> | Select DisplayName,UserPrincipalName,ProxyAddresses
```

4. Desactivar AAD Connect

Cuando la auditoría confirme que no hay objetos pendientes y que los usuarios pueden autenticarse directamente contra Entra ID, detén la sincronización:
```
Set-ADSyncScheduler -SyncCycleEnabled $false
```
Desinstala el servicio de AAD Connect desde Programas y características o mediante PowerShell:
```
Uninstall-Module -Name ADSync
```

5. Migrar servicios de infraestructura

DNS: Exporta zonas desde los DC y crea zonas equivalentes en el firewall UniFi o en un servidor DNS dedicado en la nube (Azure DNS). Cambia los forwarders de los clientes para que apunten al nuevo DNS.
DHCP: Exporta el alcance con netsh dhcp server export C:\dhcp.txt all y reimporta en el nuevo servidor DHCP (puede ser el firewall o una VM ligera).
Verifica que los clientes reciban la nueva configuración reiniciando sus interfaces de red.

6. Desmantelar los controladores de dominio

Despromociona cada DC de forma ordenada. En Windows Server 2012 R2:
```
dcpromo /unattend /ForceRemoval /AdministratorPassword:<pwd>
```
Después de la última despromoción, elimina la zona AD DS del DNS y borra los metadatos restantes con ntdsutil.
Mantén una copia de seguridad de los SYSVOL y del AD por al menos 30 días por si surge algún problema inesperado.

7. Validación post‑migración

Confirma que todos los usuarios pueden iniciar sesión en sus equipos con Azure AD Join y que Intune entrega políticas sin errores.
Revisa los logs de Azure AD Sign‑in para detectar intentos fallidos que apunten a controladores inexistentes.
Prueba el acceso a recursos críticos (SharePoint, OneDrive, aplicaciones SaaS) con cuentas recién creadas en Entra ID.

Cuándo aplicar esta solución

Aplicable cuando la organización ya tiene la mayor parte de los datos de usuario en Entra ID, los dispositivos están gestionados por Intune y no existen aplicaciones que requieran Kerberos o LDAP on‑premises.
Señales de que es momento de actuar:
- 100 % de los usuarios aparecen en Azure AD con UserType=Member.
- No hay buzones on‑premises activos.
- Todos los GPO críticos han sido replicados a Intune (Configuration Profiles).
No aplicar si existen aplicaciones heredadas que dependen de LDAP/Kerberos, o si la red interna todavía necesita la resolución de nombres de los DC para servicios críticos (por ejemplo, servidores de archivo que no se han migrado a SharePoint/OneDrive).

Código

# 1. Desactivar sincronización programada
Set-ADSyncScheduler -SyncCycleEnabled $false

# 2. Ejecutar sincronización completa (última vez)
Start-ADSyncSyncCycle -PolicyType Initial

# 3. Desinstalar AAD Connect
Get-WmiObject -Class Win32_Product -Filter "Name='Microsoft Azure AD Sync'" | ForEach-Object { $_.Uninstall() }

# 4. Despromocionar DC (ejemplo en PowerShell)
Import-Module ADDSDeployment
Uninstall-ADDSDomainController -ForceRemoval -Credential (Get-Credential) -DemoteOperationMasterRole:$true

Verificación

Inicio de sesión – En una máquina de prueba, desconecta la red, vuelve a conectarla y verifica que el login usa Azure AD (no solicita controlador de dominio).
Azure AD Sign‑ins – En el portal, revisa el reporte “Sign‑ins” y filtra por “Client app = Browser” para asegurarte de que no aparecen errores de “Domain controller not reachable”.
Intune compliance – En la consola de Intune, confirma que el dispositivo muestra estado “Compliant” y que las políticas de configuración se aplican.
DNS/DHCP – Usa nslookup y ipconfig /renew en varios equipos para validar que reciben la nueva configuración y que la resolución funciona.
Exchange Online – Envía y recibe correos desde una cuenta migrada; verifica que no aparecen atributos “LegacyExchangeDN” faltantes.

Notas adicionales

Backup: Antes de despromocionar el último DC, crea una copia de seguridad del estado del sistema (wbadmin start systemstatebackup -backuptarget:D:). Restaurar un controlador de dominio después de haber eliminado la zona AD es mucho más complejo que volver a importar una zona DNS.
Tiempo de propagación: Después de cambiar DNS, permite al menos 30 min para que la caché de los clientes se actualice; usa ipconfig /flushdns en los equipos críticos.
Licenciamiento: Asegúrate de que todas las cuentas que migras a Entra ID tengan la licencia adecuada (Azure AD Premium P1/P2 o Microsoft 365) para habilitar características como Password Writeback o Conditional Access.
Documentación interna: Registra cada paso en un wiki interno con fechas y responsables. En caso de que necesites revertir alguna fase, la trazabilidad ahorra horas de diagnóstico.

Problema#

Causa#

Solución#

1. Auditoría de dependencias#

2. Preparar Exchange para “cloud‑only”#

3. Consolidar atributos en Entra ID#

4. Desactivar AAD Connect#

5. Migrar servicios de infraestructura#

6. Desmantelar los controladores de dominio#

7. Validación post‑migración#

Cuándo aplicar esta solución#

Código#

Verificación#

Notas adicionales#

Si te interesa esto, también revisa...