Por qué un portátil de dominio acepta la contraseña antigua sin conexión

Un cambio de contraseña llega a todas partes a la vez, excepto al único portátil que ha estado una semana sin conexión. El correo web acepta la contraseña nueva, un equipo de escritorio de la oficina también, y la máquina remota sigue iniciando sesión con la antigua cuando la VPN está caída. No es una segunda contraseña ni un fallo de sincronización del directorio. Es el verificador de inicio de sesión en caché haciendo lo que se diseñó para hacer, y la solución es una secuencia, no un restablecimiento.

El portátil comprueba un verificador en caché

Windows unido al dominio guarda un verificador local de los inicios de sesión interactivos recientes correctos, para que el equipo pueda arrancar cuando ningún controlador de dominio responde. Ese verificador se deriva de la contraseña tal como estaba en aquel inicio de sesión. Cambiar la contraseña en otro sitio actualiza el directorio, no la copia de un portátil que no ha hablado con él desde entonces.

Por eso la contraseña antigua todavía puede abrir la sesión local aunque no sirva para ninguna autenticación de dominio nueva. Son dos observaciones distintas, y mezclarlas lleva a restablecimientos repetidos.

Confirme qué credencial se está usando realmente antes de cambiar nada más. Un PIN de Windows Hello, un inicio de sesión con Entra ID y una contraseña de dominio tradicional son mecanismos separados, y el PIN en particular no es la contraseña del dominio aunque desbloquee el mismo escritorio.

La autenticación de red no es un inicio de sesión interactivo

Abrir un recurso compartido con la contraseña nueva demuestra que la ruta de red funciona. No refresca la caché del inicio de sesión interactivo, porque Windows trata la autenticación de red y la interactiva como operaciones separadas con estado separado.

El verificador solo se refresca cuando un inicio de sesión interactivo contacta de verdad con un controlador de dominio; una unidad asignada o un aviso de Outlook no lo hacen.

Esa distinción explica el informe habitual: el usuario puede leer el correo y abrir la intranet, pero la pantalla de bloqueo sigue pidiendo la contraseña antigua. También explica por qué una VPN iniciada después del inicio de sesión no puede ayudar al inicio inicial, ya que el túnel llega después de que la decisión ya se haya tomado localmente.

Consiga un inicio de sesión en línea en el momento adecuado

La caché se refresca cuando el usuario inicia sesión de forma interactiva mientras el dominio es accesible. En una máquina remota, eso significa que el túnel debe existir antes de que se evalúe la credencial, no después de que aparezca el escritorio.

Compruebe si el despliegue admite conectividad previa al inicio de sesión o un túnel de dispositivo. Están diseñados para ese momento, y un túnel de usuario no los sustituye:

nltest /dsgetdc:corp.example
klist

Si el punto final no tiene una ruta previa al inicio de sesión, use el proceso de recuperación compatible que documente la organización. Algunos entornos emplean una secuencia de conectar, bloquear y desbloquear con el túnel abierto en la pantalla de bloqueo; otros envían el dispositivo a un paso de recuperación gestionado. Siga el que corresponda al cliente y, antes de confiar en él, confirme que el túnel sobrevive a la pantalla de bloqueo.

Proteja el camino de vuelta

Antes de cerrar la sesión de una máquina remota, decida cómo llegará el siguiente inicio de sesión al dominio. Un túnel de usuario que cae con la sesión puede eliminar el único camino con el que contaba, y entonces ni la contraseña antigua ni la nueva le harán pasar la pantalla de bloqueo. Mantenga una cuenta administrativa local o una consola fuera de banda como alternativa. Escriba el paso de recuperación donde el usuario pueda alcanzarlo sin iniciar sesión.

Para soporte, reúna cuatro datos: dónde se cambió la contraseña, qué credencial sigue funcionando sin conexión, si se llega a un controlador de dominio por el túnel y qué método de inicio de sesión usa el portátil.

Esos cuatro separan un verificador obsoleto de un bloqueo de cuenta o de un inicio de sesión VPN rechazado, que en un ticket parecen iguales y tienen soluciones distintas. Una cuenta bloqueada rechazará la contraseña nueva también en línea, así que pruébelo antes de culpar a la caché.

Cierre el círculo con un inicio de sesión en línea

El objetivo es un inicio de sesión interactivo compatible mientras el dominio es accesible, seguido de un estado sin conexión conocido. Ese único evento refresca el verificador y termina con el ciclo de cambiar la contraseña en cada dispositivo.

Verifique el estado después con el recuento de inicios de sesión en caché y una consulta al controlador de dominio:

reg query "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" /v CachedLogonsCount
nltest /sc_verify:corp.example

Si el recuento es cero, el inicio de sesión en caché está desactivado por directiva y el comportamiento sin conexión no cambiará por muchas veces que se restablezca la contraseña. Es una decisión de directiva que hay que plantear al propietario, no una solución alternativa para aplicar localmente.