Active Directory: fallo de inicio de sesión tras cambiar la contraseña entre dominios en confianza (Kerberos/NTLM)

¿Tus usuarios no pueden iniciar sesión desde un dominio en confianza justo después de cambiar la contraseña? No necesitas “sincronizar contraseñas”. Aquí tienes un procedimiento completo de troubleshooting en Active Directory (Kerberos/NTLM) para que la autenticación entre dominios vuelva a funcionar.

Índice

Resumen del problema

Existen dos dominios con relación de confianza. Tras cambiar la contraseña de un usuario en su dominio de origen, el inicio de sesión hacia recursos del “dominio remoto” falla. Se solicita ayuda para que la “sincronización de contraseñas” funcione o, en su defecto, para que la autenticación vuelva a ser posible desde el dominio de confianza.

Idea clave: qué hace (y qué no hace) una confianza en Active Directory

Una relación de confianza (trust) en Active Directory no sincroniza contraseñas entre dominios. La confianza permite que el dominio de origen autentique al usuario y que ese resultado sea aceptado por el dominio recurso, normalmente mediante Kerberos (o NTLM si corresponde). En ningún momento las contraseñas se copian ni se “replican” al otro dominio.

Si, después de cambiar la contraseña, el inicio de sesión falla desde el dominio en confianza, lo más habitual es un problema de replicación, sincronización de hora, DNS, canal seguro o configuración de la confianza.

Cómo fluye la autenticación entre dominios

El usuario introduce credenciales en un equipo del dominio recurso (o desde una estación miembro confiada).
El equipo contacta con un DC “cercano” para solicitar un TGT o un ticket de servicio.
Si la cuenta no pertenece a ese dominio, el DC emite un ticket de referencia (referral) hacia el dominio de origen, siguiendo la información de la confianza.
El DC del dominio de origen valida la contraseña (o el secreto Kerberos) y, si todo está correcto, devuelve el ticket válido.
El dominio recurso confía en el resultado (porque existe una confianza establecida) y otorga acceso conforme a ACLs, grupos y políticas.

Por tanto, si el ticket válido no llega o no se confía en él, la autenticación falla aunque la contraseña sea correcta.

Diagnóstico rápido (checklist express)

¿La confianza funciona y está verificada en ambos sentidos según sea necesario?
¿El PDC Emulator del dominio del usuario ve el password last set actualizado y es accesible desde los DCs remotos?
¿La hora está correctamente sincronizada (<5 min de desviación)?
¿La resolución de DNS encuentra DCs y SRV del dominio remoto?
¿El canal seguro (Netlogon) de clientes y servidores está sano?
¿Se está usando el formato de inicio de sesión apropiado (UPN o DOMINIO\usuario)?
¿No hay cachés (Kerberos/DNS) obsoletas en el cliente?
¿Qué dicen los registros de eventos en DCs de ambos dominios?

Procedimiento recomendado paso a paso

Verificar la confianza

Asegúrate de que la confianza sea la adecuada al escenario (intra-bosque, entre bosques, externa), con la dirección requerida (bidireccional si el flujo de autenticación lo exige), transitiva cuando aplique, y con name suffix routing correcto (en trusts entre bosques).

Si usas Selective Authentication, debes otorgar en los equipos/servidores destino el permiso Allowed to authenticate a los principales del dominio de origen.

Comandos útiles:

netdom trust DOMINIOA /domain:DOMINIOB /verify
nltest /domain_trusts

PowerShell (equivalente):

Get-ADTrust -Filter * | Select Name,Direction,TrustType,ForestTransitive,SelectiveAuthentication

Comprobar replicación de AD y el rol PDC Emulator

Todo cambio de contraseña se replica prioritariamente al PDC Emulator del dominio del usuario. Si otros DCs aún no conocen la contraseña nueva y tampoco pueden consultar al PDC, habrá rechazos de autenticación en fronteras de dominio y bosque.

Verifica conectividad, topología de sitios y estado de replicación:

repadmin /replsummary
repadmin /showrepl
dcdiag /test:Replications /test:FSMOCheck

Para acelerar la convergencia, fuerza una replicación:

repadmin /syncall /APeD

PowerShell: confirma el PDC y el estado de replicación.

netdom query fsmo
Get-ADDomain | Select PDCEmulator

Consejo: si hay sitios remotos con DCs de lectura-escritura y enlaces WAN inestables, prioriza la salud de la replicación intersitios (puertos, firewalls, Bridge all site links, costos de sitio).

Sincronización de hora (Kerberos)

Kerberos es muy sensible al desfase horario. Con más de ~5 minutos de diferencia, las solicitudes se rechazan.

w32tm /query /status
w32tm /query /source

Establece una cadena clara de NTP: el PDC Emulator del bosque raíz debe sincronizarse con una fuente fiable; los demás siguen la jerarquía de AD. Corrige desfases y fuerza resinc:

w32tm /config /syncfromflags:domhier /update
w32tm /resync

DNS y resolución de SRV

Cada dominio debe resolver los registros SRV del otro para localizar DCs, KDC y GC. Configura Conditional Forwarders o zonas Stub (evita zonas secundarias innecesarias).

nslookup -type=SRV kerberos.tcp.dc._msdcs.DominioRemoto
nslookup -type=SRV ldap.tcp.dc._msdcs.DominioRemoto

Si no hay respuesta o es incorrecta, corrígelo antes de continuar. Un DNS defectuoso es causa raíz habitual de fallos de confianza y logon.

Canal seguro y descubrimiento de DC

Desde un equipo del dominio “consumidor” (el que accede a recursos del dominio remoto), verifica el canal seguro contra el dominio de origen y descubre DCs:

nltest /scverify:DOMINIO_ORIGEN
nltest /dsgetdc:DOMINIO_ORIGEN

En caso de problemas con el canal seguro, puedes repararlo (ejecutado como administrador local del equipo):

Test-ComputerSecureChannel -Repair -Verbose

Validar el método de inicio de sesión

Prueba con el UPN (usuario@dominioOrigen) y con DOMINIO\usuario. Diferencias en sufijos UPN o en el name suffix routing pueden provocar rechazos.

Para probar solo credenciales de red (sin cambiar el contexto local):

runas /netonly /user:DOMINIO_ORIGEN\usuario cmd

Limpiar cachés y tickets en el cliente

Evita usar entradas antiguas tras el cambio de contraseña:

klist purge
ipconfig /flushdns

Después, reinicia sesión e intenta de nuevo el acceso al recurso.

Revisar registros de eventos

En los DCs de ambos dominios, revisa:

Directory Service (replicación, topología).
DNS Server (resolución, delegaciones, SRV).
System (Netlogon, W32Time, LSASRV 40960/40961).
Security (4768/4769 emisión de tickets, 4771 preautenticación fallida, 4625 intentos fallidos, 4723/4724/4738 cambios de contraseña/cuenta).

Matriz de diagnóstico: síntoma → causa probable → acción

Síntoma	Causa probable	Acción recomendada
“Nombre de usuario o contraseña incorrectos” solo en recursos del otro dominio tras cambio	DC remoto sin replicación reciente y sin acceso al PDC Emulator	Ver repadmin, corregir replicación y conectividad hacia PDC; forzar `repadmin /syncall /APeD`
Errores Kerberos (KRBAPERR_SKEW)	Desfase de hora > 5 min o NTP mal configurado	Corregir NTP; `w32tm /query /status`; resinc y validar jerarquía
No se localizan DCs del dominio remoto	DNS sin SRV o forwarders/zonas mal configurados	Configurar Conditional Forwarders o Stub; validar con `nslookup -type=SRV`
Acceso denegado pese a credenciales correctas	Selective Authentication sin “Allowed to authenticate”	Conceder permiso en equipos/OU destino; volver a probar
“The trust relationship failed” o Netlogon 5719/5805	Canal seguro roto (máquina o DC)	`nltest /scverify:DOMINIO` y `Test-ComputerSecureChannel -Repair`
4769 fallido con “KDCERRSPRINCIPALUNKNOWN”	SPN ausente/duplicado o servicio mal apuntado	Revisar SPN con `setspn -X` / `setspn -Q`; corregir registros
Autenticación funciona con NTLM pero no con Kerberos	DNS/SPN/Delegación; restricciones al NTLM en GPO	Arreglar DNS y SPN; revisar políticas “Restrict NTLM”

Tipos de confianza y configuraciones clave

Tipo de confianza	Ámbito	Transitiva	Uso típico	Puntos de atención
Intra-bosque	Entre dominios del mismo bosque	Sí (automática)	Acceso entre dominios de un bosque	Sites/replicación; GC; DNS interno
Entre bosques (Forest Trust)	Dos bosques distintos	Sí (entre bosques)	Colaboración inter-organización	Name Suffix Routing, Selective Auth
Externa	Entre dominios sin relación de bosque	No	Casos heredados o específicos	Más dependiente de NTLM y DNS

Comandos de referencia (copiar/pegar)

Confianza

netdom trust DOMA /domain:DOMB /verify
netdom trust DOMA /domain:DOMB /quarantine:yes
netdom trust DOMA /domain:DOMB /namesuffixes:display

Replicación y FSMO

repadmin /replsummary
repadmin /showrepl
repadmin /syncall /APeD
dcdiag /test:Replications /test:FSMOCheck
netdom query fsmo

DNS y SRV

nslookup -type=SRV kerberos.tcp.dc._msdcs.dom.remoto
nslookup -type=SRV ldap.tcp.dc._msdcs.dom.remoto
ipconfig /flushdns

Hora

w32tm /query /status
w32tm /query /source
w32tm /resync

Kerberos y canal seguro

klist
klist purge
nltest /dsgetdc:DOM_ORIGEN
nltest /scverify:DOM_ORIGEN

Puertos y conectividad mínimos

Servicio	Puerto/Protocolo	Descripción
Kerberos	88/TCP, 88/UDP	Autenticación
LDAP/LDAPS	389/TCP,UDP y 636/TCP	Directorio/seguro
DNS	53/TCP,UDP	Resolución de nombres y SRV
SMB/RPC	445/TCP, 135/TCP + 49152–65535/TCP	Netlogon, replicación y RPC dinámico
Global Catalog	3268/TCP y 3269/TCP	Búsquedas de bosque

Guía práctica: reproduce la avería y confirma la solución

En el dominio de origen, cambia la contraseña de la cuenta afectada. Verifica PasswordLastSet: Get-ADUser usuario -Properties PasswordLastSet | ft SamAccountName,PasswordLastSet
En un DC remoto del otro dominio, antes de probar el acceso, comprueba si puede contactar al PDC del dominio origen: nltest /dsgetdc:DOM_ORIGEN /Force /KDC
Desde un cliente del dominio recurso: klist purge runas /netonly /user:DOM_ORIGEN\usuario cmd \\servidor.recurso\share
Si falla, ve a los DCs y revisa Security (eventos 4768/4769/4771) correlacionando hora/cliente. Ajusta hora/DNS/replicación según los hallazgos.
Una vez corregido, repite la prueba y confirma que el ticket de servicio se emite sin errores.

Selective Authentication: errores típicos

La confianza está OK, pero el acceso sigue en “Acceso denegado”.
Solución: en Active Directory Users and Computers, habilita Advanced Features, localiza el equipo/servidor destino y otorga a los usuarios/grupos del dominio de origen el permiso Allowed to authenticate. Para verificar: dsacls "CN=SERVIDOR,OU=Equipos,DC=dom,DC=local" | findstr /I "Allowed to Authenticate"

NTLM y políticas de restricción

En confianzas externas o escenarios heredados, puede intervenir NTLM. Si existen GPOs endureciendo NTLM (“Restrict NTLM”), verifica auditorías y excepciones. Útil en clientes/servidores:

gpresult /h c:\temp\gp.html
wevtutil qe Security /q:"*[System[EventID=4625]]" /f:text /c:10

RODC y sitios remotos

Si hay RODC en sitios remotos, recuerda que solo cachean contraseñas permitidas. Si la red está caída y el RODC no tiene la contraseña nueva en su caché, la autenticación puede fallar. Solución: permitir el caché de esa cuenta, revisar conectividad hacia DCs de escritura, o redirigir la autenticación temporalmente.

Si de verdad necesitas “la misma contraseña” en cuentas duplicadas

No es una función nativa de AD DS entre dominios/bosques locales. Opciones:

Microsoft Identity Manager (MIM) + PCNS para sincronizar cambios de contraseña de manera continua (conector y filtrado).
ADMT + Password Export Server solo para migraciones (uso puntual, no continuo).
Soluciones de terceros de gestión de identidades y sincronización de credenciales.

Nota: Azure AD Connect con Password Hash Sync no sincroniza contraseñas entre dominios locales; su ámbito es hacia/desde Azure AD.

Buenas prácticas para evitar regresiones

NTP: define una jerarquía clara y comprueba periódicamente la deriva.
DNS: usa Conditional Forwarders o Stub entre bosques; monitoriza la caducidad de SRV.
Replicación: vigila repadmin /replsummary, latencia y errores por vínculo WAN.
Supervisión: recopila 4768/4769/4771, Netlogon y LSASRV; crea alertas ante patrones de fallos.
Documenta las confianzas: dirección, transividad, name suffix routing, SID filtering, Selective Auth.
Control de cambios: cuando se tocan DNS, GPO de seguridad o firewalls entre dominios, planifica pruebas cruzadas.

Preguntas frecuentes

¿Por qué el inicio de sesión a veces funciona con la contraseña vieja?

Tras un cambio reciente, un DC remoto que no ve la nueva contraseña puede consultar al PDC Emulator del dominio de origen. Si no logra alcanzarlo, puede rechazar el logon hasta que la replicación converja o el PDC sea accesible.

¿Puedo acelerar que todos los DCs “vean” la contraseña nueva?

La ruta crítica es la conectividad hacia el PDC Emulator y la salud de la replicación. Usa repadmin /syncall /APeD y corrige errores de topología o firewall.

¿Qué formato de usuario debo usar?

Recomendado: UPN (usuario@dominioOrigen), especialmente en confianzas de bosque. También puedes usar DOMINIO\usuario, asegurando que el nombre NetBIOS sea resoluble en el entorno.

¿La confianza copia grupos o permisos?

No. La confianza solo establece quién puede ser autenticado; los permisos dependen de ACLs del recurso y de la traducción de grupos/identidades aceptada a través de la confianza.

Ruta de solución recomendada (resumen accionable)

Confianza: verificar, bidireccional si es necesario, y Selective Auth correctamente concedida.
Replicación y PDC: sin errores; conectividad garantizada; forzar repadmin /syncall.
Hora: desfase < 5 min; jerarquía NTP correcta.
DNS: SRV resueltos; forwarders o stub entre bosques.
Canal seguro: nltest /scverify OK; reparar si es necesario.
Cliente: purgar tickets y DNS; probar con UPN y DOMINIO\usuario.
Logs: revisar eventos clave para afinar la causa raíz.

Resultado esperado

Tras corregir confianza, replicación, hora y DNS, el usuario debería poder autenticarse en recursos del otro dominio de forma inmediata después del cambio de contraseña, sin “sincronizar” contraseñas entre dominios.

Si el requisito es mantener contraseñas idénticas en cuentas separadas de varios dominios, aplica una solución de sincronización dedicada (MIM/PCNS u otra) diseñada para ese propósito.

Apéndice: comandos rápidos de validación integral

:: 1) Salud de confianza
nltest /domain_trusts
netdom trust DOMA /domain:DOMB /verify

\:: 2) Replicación y PDC
repadmin /replsummary
repadmin /showrepl
netdom query fsmo

\:: 3) Hora/NTP
w32tm /query /status
w32tm /query /source

\:: 4) DNS/SRV
nslookup -type=SRV \kerberos.\tcp.dc.\msdcs.DOM\B
nslookup -type=SRV \ldap.\tcp.dc.\msdcs.DOM\B

\:: 5) Canal seguro
nltest /dsgetdc\:DOM\_A
nltest /scverify\:DOM\_A

\:: 6) Cliente (limpieza y prueba)
klist purge
ipconfig /flushdns
runas /netonly /user\:DOM\_A\usuario cmd

Ejemplo de plan de prueba posterior a cambios

Cambia la contraseña de un usuario de prueba en el dominio origen.
Desde un servidor del dominio recurso, accede a: \\servidor-origen\recurso$ y a un sitio web integrado con Kerberos en el dominio origen.
Valida en los DCs:
- Eventos 4768/4769 exitosos sin 4771.
- Sin alertas de LSASRV 40960/40961.
- Sin errores de Netlogon 5719/5805.
Repite con UPN y con DOMINIO\usuario.

Notas de arquitectura y seguridad

Las confianzas amplían la superficie de ataque: habilítalas solo cuando sea necesario y con el mínimo privilegio (Selective Auth, auditoría).
Prefiere Kerberos con cifrados modernos; limita NTLM donde sea posible y documenta las excepciones entre dominios.
Monitorea latencia de replicación entre sitios; evita “islas” donde el PDC no sea alcanzable.
Evita almacenar credenciales de servicio con cuentas de usuario; usa cuentas gestionadas (gMSA) cuando sea posible.

Conclusión: la clave está en comprender que la confianza no replica contraseñas. Si alineas confianza + replicación + hora + DNS + canal seguro, la autenticación interdominios funcionará tan pronto como cambie la contraseña, sin ninguna “sincronización de contraseñas” entre dominios.