Problema

En entornos con varios controladores de dominio (DC) que ejecutan Windows Server 2019, la necesidad de actualizar a una versión más reciente (por ejemplo, Windows Server 2025) genera un patrón recurrente: agregar los nuevos servidores como DCs adicionales, validar la infraestructura y, finalmente, retirar los antiguos. Durante esta fase de coexistencia, administradores reportan fallos de inicio de sesión vinculados al servicio LocalKDC que queda en estado START_PENDING. El síntoma se manifiesta como errores de Kerberos, imposibilidad de autenticación y, en casos extremos, bloqueos de servicios dependientes (DFS Replication, Netlogon, etc.). El problema suele aparecer después de la promoción del nuevo DC y, a veces, después de la primera reinicialización.

Causa

Los incidentes de LocalKDC en una migración a Windows Server 2025 pueden rastrearse a varios factores comunes:

  1. Esquema de AD no actualizado – La promoción automática de un nuevo DC ejecuta adprep /forestprep y /domainprep. Si el proceso se interrumpe o se ejecuta con privilegios insuficientes, el esquema queda parcialmente actualizado y el KDC no puede cargar los controladores de cifrado requeridos.

  2. Actualizaciones acumulativas faltantes – Windows Server 2025 se lanza con un nivel de parche base que no incluye correcciones críticas para Kerberos (por ejemplo, mejoras en el algoritmo AES‑256 y compatibilidad con RC4 legacy). Un servidor recién instalado sin la última cumulative update (CU) puede quedar con un KDC que no reconoce los tickets de los DCs más antiguos.

  3. Desalineación de niveles funcionales – Si el nivel funcional del bosque o dominio se ha elevado recientemente (por ejemplo, de 2008 R2 a 2016) pero los controladores nuevos no heredan la configuración de cifrado adecuada, el KDC puede quedar atascado mientras intenta negociar algoritmos incompatibles.

  4. Configuración de DNS incompleta – Los DCs dependen de registros SRV y A correctos. Un registro faltante o un encaminamiento DNS circular provoca que el nuevo DC no pueda localizar los KDC de los controladores existentes, lo que lleva a que LocalKDC espere indefinidamente una respuesta.

  5. SYSVOL/DFSR desincronizado – Cuando el nuevo DC no replica correctamente SYSVOL mediante DFSR, el proceso de arranque del KDC falla al buscar políticas de grupo relacionadas con Kerberos.

  6. Roles FSMO en el servidor antiguo – Si se intenta transferir roles FSMO antes de validar la replicación completa, el KDC del nuevo DC puede quedar sin la información de dominio necesaria para generar tickets.

Solución

Una estrategia robusta para migrar DCs a Windows Server 2025 y evitar el bloqueo de LocalKDC combina preparación del esquema, actualización de parches, validación de DNS y una secuencia controlada de promoción y despromoción.

1. Preparar el esquema y aplicar parches

# Ejecutar adprep en el DC 2019 que posee los roles FSMO
adprep /forestprep /domainprep /gpprep
# Reiniciar el DC después de cada paso

Una vez completado, instale la última cumulative update disponible para Windows Server 2025 antes de iniciar la promoción. Use Windows Update o descargue el paquete manualmente desde el catálogo de Microsoft.

2. Configurar DNS antes de la promoción

  • Verifique que los registros SRV _ldap._tcp, _kerberos._tcp y _kpasswd._tcp existan para cada sitio.
  • Añada la IP del nuevo servidor como registro A en la zona forward del dominio.
  • En el nuevo servidor, configure la zona DNS para que use solo los servidores DNS internos (evite encaminamiento externo).
dnscmd /RecordAdd <Zona> <Nombre> A <IP_Nuevo_DC>
dnscmd /RecordAdd <Zona> _ldap._tcp.<Sitio> SRV 0 100 389 <Nombre_Nuevo_DC>

3. Promover el nuevo DC con PowerShell

Utilice Install-ADDSDomainController con los parámetros mínimos para evitar la ejecución automática de adprep (ya ejecutado en el paso 1).

Install-ADDSDomainController `
    -CreateDnsDelegation:$false `
    -DatabasePath "C:\Windows\NTDS" `
    -LogPath "C:\Windows\NTDS" `
    -SysvolPath "C:\Windows\SYSVOL" `
    -NoGlobalCatalog:$false `
    -SiteName "Default-First-Site-Name" `
    -InstallDns:$true `
    -Credential (Get-Credential) `
    -SafeModeAdministratorPassword (Read-Host -AsSecureString "SafeModePwd") `
    -Force:$true

Después del reinicio, compruebe que el servicio NTDS y DNS estén en estado Running antes de pasar a la validación.

4. Validar replicación y SYSVOL

repadmin /replsummary
dcdiag /test:replications
dfsrdiag ReplicationState /RGName:"Domain System Volume"

Los resultados deben mostrar 0 errores y 0 pending replication. Si aparecen fallos, revise los logs de DFSR y asegúrese de que el nuevo DC tenga los permisos de lectura/escritura en la carpeta SYSVOL.

5. Verificar Kerberos y LocalKDC

klist tgt
Get-Service -Name kdc, Netlogon | Format-Table Name, Status
  • El comando klist tgt debe devolver un ticket válido.
  • El servicio kdc (LocalKDC) debe estar en Running. Si está en START_PENDING, revise el registro de eventos bajo System y Directory Service para mensajes de “Kerberos Key Distribution Center failed to start”.

Solución al estado START_PENDING

  1. Reinicie el servicio: net stop kdc && net start kdc.
  2. Si persiste, elimine temporalmente la caché de claves:
certutil -delstore "Kerberos Authentication" *
  1. Reinicie el servidor. El KDC recreará la caché usando la información del AD actualizado.

6. Transferir roles FSMO

Una vez que la replicación y Kerberos funcionen sin errores, transfiera los roles FSMO con Move-ADDirectoryServerOperationMasterRole.

Move-ADDirectoryServerOperationMasterRole -Identity <Nuevo_DC> -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, DomainNamingMaster

Confirme con netdom query fsmo.

7. Despromover y retirar los DCs antiguos

Ejecute Uninstall-ADDSDomainController en cada servidor 2019 después de validar que todos los clientes pueden autenticarse contra el nuevo DC.

Uninstall-ADDSDomainController -DemoteOperationMasterRole:$true -Force:$true

Cuándo aplicar esta solución

  • Síntomas: tickets Kerberos fallan, errores de inicio de sesión, eventos 5719/5718, o el servicio kdc en START_PENDING después de agregar un DC Windows Server 2025.
  • Entorno: al menos un DC existente con Windows Server 2019 o versiones anteriores, y la intención de introducir Windows Server 2025 como controlador adicional.
  • No aplica: cuando la migración se realiza mediante upgrade in‑place (no recomendado) o cuando el dominio está en nivel funcional inferior a Windows Server 2008 R2, ya que los algoritmos de cifrado modernos pueden no estar soportados.

Verificación

  1. Replicación: repadmin /showrepl * /verbose /all – sin errores.
  2. DNS: nslookup -type=SRV _kerberos._tcp.<dominio> – debe listar todos los DCs, incluido el nuevo.
  3. Kerberos: klist tgt en una máquina cliente – ticket válido con hora de emisión reciente.
  4. Eventos: revisar los logs de System y Directory Service en busca de ID 5719, 5718 o 1008.
  5. Rendimiento: monitorizar la latencia de autenticación en el controlador nuevo mediante Get-ADUser -Filter * | Measure-Command.

Notas adicionales

  • Backup del AD antes de cualquier cambio es indispensable; use Windows Server Backup o wbadmin para crear una copia del estado del sistema.
  • Desactivar temporalmente RC4 en la política de dominio (Domain controller: LDAP server signing requirements) puede reducir conflictos de cifrado cuando se mezclan controladores con versiones distintas.
  • Documentar la versión exacta del CU aplicado al nuevo DC ayuda a reproducir la solución en futuros despliegues.
  • En entornos con controladores de solo lectura (RODC), asegúrese de que el nuevo DC tenga la misma configuración de réplica de contraseñas; de lo contrario, los clientes pueden recibir tickets incompletos.
  • Mantener los DCs antiguos al menos 7 días después de la validación brinda margen para detectar problemas intermitentes de replicación o DNS.