Problema

En entornos con equipos Windows 11 unidos a dominio, es frecuente que al bloquear la sesión y volver a introducir las credenciales aparezca el mensaje “Your credentials could not be verified” o “You could not be signed in”. El bloqueo impide el acceso inmediato, obliga a reiniciar la máquina o a esperar a que el caché de credenciales se agote. El síntoma se reproduce tanto en equipos conectados directamente a la red corporativa como en usuarios que acceden mediante VPN.

El patrón típico es:

  • El usuario bloquea la pantalla (por inactividad, reunión, etc.).
  • Al intentar desbloquear, Windows muestra un error de validación de credenciales.
  • Un reinicio temporalmente restaura el acceso, pero el error reaparece tras 1‑2 horas o después de la próxima actualización de seguridad.
  • Los logs del cliente indican fallos de secure channel entre el equipo y el controlador de dominio.

Este comportamiento no es exclusivo de una actualización concreta; cualquier cambio que altere la forma en que el cliente valida la confianza del dominio puede desencadenarlo.

Causa

El Secure Channel es la relación de confianza que permite a un equipo validar su cuenta de máquina contra el controlador de dominio mediante el protocolo Netlogon/SMB. Cuando esa relación se rompe, el proceso de logon interactivo no puede confirmar que el equipo pertenece al dominio y, por tanto, rechaza las credenciales del usuario.

Causas habituales:

Causa Por qué ocurre
Contraseña de máquina desincronizada Cambios de política de contraseñas o restauraciones de imágenes que dejan la cuenta de equipo con una contraseña distinta a la almacenada en AD.
Actualizaciones que modifican la lógica de validación Algunas actualizaciones de Windows introducen cambios en la secuencia de verificación del Secure Channel, provocando que la validación falle si el canal ya está degradado.
Restricciones de red en VPN El túnel VPN suele permitir tráfico de Kerberos (88), LDAP (389) y DNS, pero bloquea o no enruta correctamente los puertos usados por Netlogon/SMB (445, 135). El cliente puede consultar al DC, pero no puede restablecer la contraseña de máquina.
Políticas de hardening que limitan el número de tickets o el algoritmo de cifrado Configuraciones que fuerzan algoritmos incompatibles pueden impedir que el cliente renueve el ticket de máquina.
Fallos intermitentes del controlador de dominio Un DC sobrecargado o con problemas de replicación puede devolver errores al intentar restablecer la cuenta de equipo.

En la práctica, la combinación de una actualización que intensifica la verificación del Secure Channel y una VPN que no transporta tráfico SMB es la que genera el error más visible.

Solución

1. Verificar el estado del Secure Channel

Test-ComputerSecureChannel -Verbose

Si el comando devuelve False, el canal está roto y necesita reparación.

2. Restaurar la confianza desde el controlador de dominio

Ejecutar la reparación desde el DC evita la necesidad de que el cliente atraviese el túnel VPN.

Reset-ComputerMachinePassword -Server <DC_FQDN>

Reemplaza <DC_FQDN> por el nombre completo del controlador (p. ej., vw-dc-01.domain.org). Este comando fuerza al DC a generar una nueva contraseña de máquina y a sincronizarla con el equipo objetivo.

3. Incrementar el caché de logons para mitigar el impacto

Aumentar CachedLogonsCount permite que los usuarios inicien sesión sin contactar al DC mientras se arregla el canal.

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount /t REG_SZ /d 50 /f

O mediante GPO: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Interactive logon: Number of previous logons to cache → 50.

4. Asegurar el paso de tráfico SMB/RPC por la VPN

Revisa la configuración del cliente y del concentrador VPN para que los siguientes puertos estén permitidos y enrutados:

  • 445 TCP (SMB)
  • 135 TCP (RPC Endpoint Mapper)
  • 139 TCP (NetBIOS Session Service) – opcional
  • 389 TCP/UDP (LDAP) – ya suele estar abierto
  • 88 TCP/UDP (Kerberos) – ya suele estar abierto

Si la política de la VPN bloquea 445, solicita al equipo de redes que lo habilite o crea una regla de excepción para el rango de IP de los DC.

5. Revertir temporalmente la actualización problemática (solo para diagnóstico)

wusa /uninstall /kb:5124008 /quiet /norestart
shutdown /r /t 60

Advertencia: La actualización puede contener parches críticos. Usa esta medida solo para confirmar la causa y no como solución permanente.

6. Automatizar la detección y reparación

Implementa una tarea programada que ejecute Test-ComputerSecureChannel cada hora y, si falla, invoque Reset-ComputerMachinePassword contra un DC de confianza.

$script = {
  if (-not (Test-ComputerSecureChannel -Quiet)) {
    Reset-ComputerMachinePassword -Server "vw-dc-01.domain.org"
  }
}
Register-ScheduledTask -Action (New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-Command & {$script}") -Trigger (New-ScheduledTaskTrigger -Hourly) -TaskName "RepairSecureChannel" -RunLevel Highest -User "SYSTEM"

Cuándo aplicar esta solución

Aplica cuando se presenten los siguientes indicadores:

  • Mensaje de error “Your credentials could not be verified” al desbloquear la pantalla.
  • Test-ComputerSecureChannel devuelve False.
  • El problema ocurre tanto en LAN como en VPN, pero es más frecuente en usuarios remotos.
  • Los logs del sistema contienen eventos 5719, 5722 o 5723 (fallos de Netlogon).

No aplica si:

  • El error se limita a credenciales de usuario (p. ej., expiración de contraseña) y Test-ComputerSecureChannel muestra True.
  • La red VPN ya enruta correctamente los puertos 445 y 135 y el problema persiste después de una reparación del canal desde el DC.

Código

# Verificar estado del canal
Test-ComputerSecureChannel -Verbose

# Reparar desde el DC (ejecutar en el controlador)
Reset-ComputerMachinePassword -Server vw-dc-01.domain.org

# Aumentar caché de logons (cliente)
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v CachedLogonsCount /t REG_SZ /d 50 /f

# Desinstalar actualización problemática (solo diagnóstico)
wusa /uninstall /kb:5124008 /quiet /norestart
shutdown /r /t 60

Verificación

  1. Antes de la reparación: Test-ComputerSecureChannel -Verbose → False. Evento 5719 en el registro de Sistema.
  2. Después de ejecutar la reparación: volver a ejecutar el comando. Debe devolver True y no aparecer nuevos eventos 5719/5722/5723.
  3. Prueba de desbloqueo: bloquear la pantalla, esperar unos minutos y desbloquear. El mensaje de error debe haber desaparecido.
  4. Validar tráfico VPN: usar Test-NetConnection -ComputerName <DC_FQDN> -Port 445 desde el cliente remoto. Resultado TcpTestSucceeded: True indica que el túnel permite SMB.

Notas adicionales

  • En entornos con múltiples controladores, especifica un DC que esté en la misma subred que el cliente para evitar latencias que puedan provocar timeouts de Netlogon.
  • Si la política de seguridad de la empresa prohíbe el uso de SMB sobre VPN, considera habilitar DirectAccess o Always On VPN que soportan túneles de capa 2 y transportan tráfico Netlogon sin restricciones.
  • Mantén una lista de actualizaciones que modifican la lógica de logon (KB5120998, KB5124008, etc.) y prueba su instalación en un OU piloto antes de desplegarlas a toda la flota.
  • Documenta cualquier excepción de firewall VPN en el Change Management para facilitar auditorías y evitar sorpresas en futuros parches.