La replicación entre controladores de dominio de Active Directory puede detenerse con errores como “Access is denied” y “The target principal name is incorrect (0x80090322)”. Esta guía práctica explica cómo diagnosticar y corregir el problema con pasos seguros y verificables.

Resumen de la pregunta y contexto

Se observa un fallo de replicación entre controladores de dominio (DC) con síntomas como:

• repadmin /syncall /AdeP devuelve: Network error: 5 (0x5) Access is denied.
• En repadmin /showrepl y repadmin /replsum aparecen errores persistentes 0x80090322 “The target principal name is incorrect” y, en algunos contextos, 1256 “The remote system is not available”.
• Incidencia sostenida desde 17‑12‑2024.

La causa más probable es un canal seguro de equipo (Machine Account) roto entre DCs o incoherencias en SPN/DNS, agravadas por desfase horario o puertos bloqueados.

Señales técnicas y cómo leerlas

• 0x80090322: suele indicar que el nombre principal de destino no coincide con el SPN esperado por Kerberos. Frecuente si hay SPN duplicados o si el canal seguro del DC está dañado.
• 0x5 Access is denied: credenciales insuficientes o autenticación fallida por canal seguro roto.
• 1256 The remote system is not available: problemas de conectividad, DNS, puertos RPC, o servicio remoto no disponible.

En combinación, estos códigos apuntan a que la autenticación Kerberos no puede establecerse correctamente entre controladores de dominio.

Diagnóstico rápido antes de cambiar nada

1. Abra la consola como Administrador.
2. Use una cuenta con privilegios suficientes: Domain Admins o Enterprise Admins.
3. Verifique conectividad y DNS entre DCs (FQDN y NetBIOS):

ping <DC-Remoto-FQDN>
ping <DC-Remoto-NetBIOS>
nslookup <DC-Remoto-FQDN>

4. Compruebe hora y sincronización NTP (Kerberos tolera poco desfase, típicamente ±5 min):

w32tm /query /status
w32tm /resync /nowait

Comando	Qué validar	Resultado esperado
ping FQDN	Resolución DNS y latencia	Resuelve a la IP correcta y responde
nslookup FQDN	Registros A/AAAA	Devuelve el FQDN y la IP del DC
w32tm /query /status	Source y Skew	Fuente válida y desfase mínimo

Solución principal: restablecer el canal seguro del DC

Cuando aparece “The target principal name is incorrect”, a menudo el problema es el canal seguro de la cuenta de equipo del DC o SPN incoherentes. Procédase así:

1. En el DC afectado que NO es el PDC Emulator, ejecute:

netdom resetpwd /s:<DCsanoo_PDC> /ud:<DOMINIO\Administrador> /pd:*

• /s: es el DC de referencia (idealmente el PDC Emulator o un DC sano).
• Se le pedirá la contraseña de /ud:.

2. Reinicie el DC cuyo password se cambió.
3. Valide el canal seguro y localización de DCs:

nltest /sc_verify:<dominio.fqdn>
nltest /dsgetdc:<dominio.fqdn>

4. Fuerce y revise la replicación:

repadmin /syncall /AdeP
repadmin /replsum
repadmin /showrepl

Si la salida de nltest /sc_verify indica “The secure channel is in good condition” y repadmin /replsum muestra 0% de errores, el problema ha quedado resuelto.

Si persiste el error: SPN y DNS

Cuando el canal seguro ya fue restablecido pero el error 0x80090322 continúa, revise SPN y DNS.

Revisión y limpieza de SPN

setspn -X                 & rem Buscar SPN duplicados en el bosque
setspn -Q /<NombreDC>   & rem Revisar SPN del DC afectado
setspn -L <NombreDC>      & rem Listar todos los SPN del DC

Si encuentra duplicados, elimine el SPN del objeto erróneo (no del DC correcto):

setspn -D <SPN> <ObjetoProblemático>

Buen criterio: no modifique SPN generados por el sistema salvo para retirar duplicados manifiestos. Documente cada cambio y vuelva a probar replicación tras cada ajuste.

Re-registro de DNS y pruebas

ipconfig /registerdns
nltest /dsregdns
dcdiag /test:dns /v

Compruebe que el DC publica registros SRV bajo las zonas msdcs.<forest> y sites, así como sus registros A/AAAA. Si hay zonas divididas o reenviadores, valide coherencia de nombres internos.

Puertos imprescindibles y cómo probarlos

Active Directory depende de RPC, Kerberos, LDAP, DNS y SMB. Verifique que los firewalls permiten el tráfico entre DCs.

Servicio	Protocolo	Puerto	Uso	Comprobación rápida
Kerberos	TCP/UDP	88	Autenticación	Test-NetConnection <DC> -Port 88
RPC Endpoint Mapper	TCP	135	Negociación de RPC	Test-NetConnection <DC> -Port 135
LDAP / LDAPS	TCP	389 / 636	Directorio	Test-NetConnection <DC> -Port 389
Global Catalog	TCP	3268 / 3269	Consulta GC	Test-NetConnection <DC> -Port 3268
SMB	TCP	445	SYSVOL/NETLOGON	Test-NetConnection <DC> -Port 445
DNS	TCP/UDP	53	Resolución de nombres	Test-NetConnection <DC> -Port 53
RPC Dinámicos	TCP	49152–65535	Canales RPC	Verificar al menos algunos puertos aleatorios

Comandos de ejemplo para validar puertos clave:

PowerShell
Test-NetConnection <DC-Remoto> -Port 135
Test-NetConnection <DC-Remoto> -Port 389
Test-NetConnection <DC-Remoto> -Port 445

Kerberos tras cambios

Cuando ajuste SPN o restablezca el canal seguro, puede ser útil limpiar la caché Kerberos del equipo y de la sesión:

klist purge

Luego cierre y vuelva a abrir sesión administrativa antes de repetir las pruebas.

Revisión de SYSVOL y replicación de archivos

Si la replicación del directorio vuelve a la normalidad pero aún hay problemas de directivas o scripts de inicio de sesión, confirme que SYSVOL está compartido y que el servicio de replicación de DFS (DFSR) funciona. Una verificación rápida es explorar \<DC>\SYSVOL desde otro DC y observar resultados consistentes. Si no, fuerce una sondeo de Active Directory en DFSR:

dfsrdiag PollAD

Checklist ejecutable para cada DC

Use la siguiente lista para marcar cada paso. Repítala en cada controlador de dominio afectado.

• Consola elevada y cuenta con privilegios adecuados
• Conectividad y DNS correctos (ping/nslookup por FQDN/NetBIOS)
• Horario sincronizado con w32tm
• Ejecutado netdom resetpwd con referencia a PDC/DC sano
• Reinicio del DC tras el reset de contraseña
• nltest /sc_verify correcto
• Replicación forzada y revisada con repadmin
• SPN verificados y sin duplicados (setspn -X)
• DNS re-registrado y dcdiag /test:dns sin errores
• Puertos abiertos entre DCs (RPC/Kerberos/DNS/LDAP/SMB)
• Caché Kerberos purgada tras cambios
• SYSVOL accesible y consistente

Matriz de síntomas a causas probables

Síntoma	Causa probable	Acción recomendada
0x80090322 The target principal name is incorrect	Canal seguro roto o SPN incoherente/duplicado	Ejecutar netdom resetpwd, revisar setspn -X/-Q
0x5 Access is denied en repadmin	Credenciales o fallo de autenticación Kerberos	Usar cuenta de Domain Admins, restablecer canal seguro
1256 The remote system is not available	Ruta de red bloqueada, DNS mal resuelto, servicio apagado	Ver puertos, firewall, resolver DNS, revisar estado de servicios
Fallo sostenido desde 17‑12‑2024	Contraseña de máquina no rotó correctamente o cambios de DNS	Restablecer canal, re-registrar DNS, validar horarios

Comandos clave para recopilar evidencia

Guarde salidas para auditoría y soporte. Útiles especialmente antes y después de aplicar cambios:

repadmin /showrepl > C:\rep1.txt
repadmin /replsum > C:\rep2.txt
repadmin /showrepl * /csv > C:\repsum.csv
dcdiag /v /test:replications

Buenas prácticas y advertencias

• Cambios uno a la vez: tras cada acción (p. ej., netdom resetpwd), reinicie, valide nltest y solo entonces pase al siguiente paso.
• Horarios exactos: asegure que el PDC Emulator sincroniza con una fuente fiable y que el resto de DCs hereda esa jerarquía de tiempo.
• Evite SPN “creativos”: los SPN de DC son gestionados por el sistema. Limítese a eliminar duplicados o corregir asignaciones erróneas.
• Planifique ventanas: aunque el restablecimiento de canal es rápido, programe el reinicio del DC fuera de horas pico.
• Documente: capture salidas y anote hora de cada acción; esto facilita correlacionar con registros de seguridad y de sistema.

Ejemplo de sesión de recuperación

:: En DC afectado (no PDC), con cmd elevado:
whoami /groups | find "Domain Admins"

\:: Comprobaciones rápidas
ping DC-SANO.dominio.local
nslookup DC-SANO.dominio.local
w32tm /query /status

\:: Restablecer canal seguro con referencia al PDC
netdom resetpwd /s\:PDC-EMULATOR /ud\:DOMINIO\Administrador /pd:\*

\:: Reinicio
shutdown /r /t 0

\:: Validaciones tras el arranque
nltest /sc\_verify\:dominio.local
nltest /dsgetdc\:dominio.local

\:: DNS
ipconfig /registerdns
nltest /dsregdns
dcdiag /test\:dns /v

\:: Replicación
repadmin /syncall /AdeP
repadmin /replsum
repadmin /showrepl 

Interpretación de resultados esperados

• Replicación: repadmin /replsum con 0% fails; en repadmin /showrepl, líneas del tipo “Last attempt @ <fecha> was successful.”
• Canal seguro: nltest /sc_verify:<dominio> devuelve “The secure channel is in good condition.”
• DNS: dcdiag /test:dns /v sin eventos críticos; SRV y A/AAAA presentes.

Soluciones alternativas y consideraciones

Para servidores miembros no-DC (por ejemplo, si observa errores Kerberos similares en aplicaciones), una alternativa es PowerShell:

Reset-ComputerMachinePassword -Server <DC-Referencia> -Credential (Get-Credential)

No use este método para un controlador de dominio; en DCs utilice netdom resetpwd como se indica en la solución principal.

Preguntas frecuentes rápidas

¿Por qué “Access is denied” si soy Domain Admin?
Porque repadmin depende de autenticación Kerberos y RPC. Si el canal seguro o los SPN están dañados, Kerberos falla antes de aplicar sus privilegios, devolviendo denegación de acceso.

¿El desfase horario realmente importa?
Sí. Kerberos valida validez temporal de los tickets. Un desfase de minutos puede invalidar autenticaciones y provocar errores como 0x80090322.

¿Necesito tocar el PDC?
En general, use el PDC como referencia en /s: para netdom resetpwd de los demás DCs. Solo si el PDC es el afectado, elija como referencia un DC sano.

Flujo recomendado de principio a fin

1. Confirmar privilegios, conectividad, DNS y hora (w32tm).
2. Restablecer el canal seguro en el DC afectado con netdom resetpwd contra PDC/DC sano.
3. Reiniciar el DC y validar nltest.
4. Re-registrar DNS y ejecutar dcdiag /test:dns /v.
5. Forzar repadmin /syncall /AdeP y revisar /replsum y /showrepl.
6. Si persiste, auditar SPN con setspn -X/-Q y corregir duplicados; volver a probar.
7. Verificar puertos y firewall en ambos sentidos entre DCs.
8. Comprobar SYSVOL/DFSR si las GPO no se actualizan.

Resultado final esperado

• repadmin /replsum sin fallos (0%) y repadmin /showrepl con intentos exitosos recientes.
• nltest /sc_verify:<dominio> con “The secure channel is in good condition.”
• Registros DNS coherentes y sin duplicidad de SPN.

Notas rápidas de causa probable

• Canal seguro roto entre DCs (resuelto con netdom resetpwd + reinicio).
• SPN duplicado/incorrecto o registros DNS desactualizados.
• Desfase de tiempo o puertos bloqueados en firewall entre DCs.

Plantillas de comandos para equipos de campo

Copie y pegue según convenga en sus runbooks:

:: Hora
w32tm /query /status
w32tm /resync /nowait

\:: Red y DNS
ping \ -n 3
nslookup \
ipconfig /registerdns
nltest /dsregdns

\:: SPN
setspn -X
setspn -Q /\
setspn -L \

\:: Canal seguro
netdom resetpwd /s:\ /ud:\ /pd:\*

\:: Replicación
repadmin /syncall /AdeP
repadmin /replsum
repadmin /showrepl

\:: Puertos
PowerShell
Test-NetConnection \ -Port 135
Test-NetConnection \ -Port 389
Test-NetConnection \ -Port 445

\:: Evidencia
repadmin /showrepl > C:\rep1.txt
repadmin /replsum > C:\rep2.txt
repadmin /showrepl \* /csv > C:\repsum.csv
dcdiag /v /test\:replications 

---