Windows rechaza una contraseña que aceptó en otro lugar un minuto antes, así que la cuenta parece rota cuando el intento nunca llegó a evaluarse. El error 691 significa que la conexión se rechazó durante la autenticación, y el cliente muestra el mismo texto tanto si el secreto era incorrecto, como si el nombre de cuenta se resolvió en una identidad inesperada, como si una directiva del servidor denegó la conexión. Tres reparaciones distintas comparten un solo mensaje, por eso un restablecimiento a veces ayuda y a veces no cambia absolutamente nada. Empiece por la parte que puede inspeccionar solo: la cadena exacta que envió el cliente y el almacén de credenciales del que la tomó. Luego pregunte al servidor qué decisión registró, porque el diálogo es una denegación y no un diagnóstico.

Tres formas de ser rechazado, un solo diálogo

Un secreto incorrecto es solo la primera forma de llegar a este diálogo. El nombre de cuenta puede resolverse en una identidad que usted no pretendía, la cuenta puede no tener permiso de marcado, o una condición del servidor puede denegar la conexión después de aceptar la contraseña. Cada uno de esos casos produce el mismo texto en el cliente, y cada uno tiene su propia reparación.

Por eso un restablecimiento parece funcionar el lunes y no hace nada el martes. Lea el diálogo como una denegación y no como un diagnóstico, y anote el nombre del perfil y la hora local del fallo antes de tocar la cuenta.

Las tres categorías también fallan en capas distintas. Un secreto incorrecto falla la prueba de identidad, una forma de cuenta incorrecta falla la búsqueda, y una condición de directiva falla la autorización una vez demostrada la identidad. Solo la primera se repara cambiando la contraseña. Las otras dos necesitan a alguien con acceso al registro de decisiones del servidor, por eso el siguiente paso es una solicitud de información y no otro restablecimiento.

Qué envió realmente el cliente

Confirme el formato de cuenta aceptado con quien administra la puerta de enlace, porque un nombre de usuario simple, un nombre cualificado por dominio y un nombre principal de usuario pueden resolverse en contextos de cuenta distintos. Solo uno de ellos puede ser la identidad que tiene el permiso. Pregunte qué forma espera la puerta de enlace antes del primer intento y no después del quinto, y compruebe si el cliente reutiliza una credencial almacenada en lugar de la que escribió.

Dos consultas de solo lectura en la máquina Windows muestran el perfil y cualquier credencial en caché que podría imponerse al diálogo. Ninguna de las dos marca al servidor:

Get-VpnConnection -Name 'Corp VPN' | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod
cmdkey /list | Select-String -Pattern 'corp' -SimpleMatch

Trate la contraseña como datos y no como texto copiado de un documento. Un valor que pasó por un script puede llevar caracteres de escape que nunca formaron parte del secreto, y una exportación de configuración puede haberlo entrecomillado. Quitar todos los caracteres especiales para que encaje es un cambio distinto de encontrar el valor real, así que establezca primero el valor real.

Obtenga la decisión de la directiva, no un restablecimiento

En una implementación de acceso remoto que usa un servidor de directivas de red, se ejecutan dos decisiones en secuencia. La autenticación establece qué cuenta pregunta, y la autorización decide si esa cuenta puede conectarse siquiera. Las condiciones y restricciones de la directiva se evalúan según sus propios criterios, así que un secreto correcto solo resuelve la primera mitad de la cuestión. El nombre de la directiva en el evento del servidor identifica qué decisión se ejecutó realmente.

Envíe al administrador el nombre del perfil, la cuenta intentada y la marca de tiempo. Pida el registro de decisión correspondiente y su motivo en lugar de otro restablecimiento de contraseña, y pida el nombre de la directiva que lleva el evento. La referencia de códigos de error de acceso remoto de Microsoft incluye el 691 entre los fallos de credenciales y autenticación, y es exactamente por eso que el diálogo no puede separar los tres casos.

Convertir una cuenta en un permiso incondicional transforma una decisión de autorización en una excepción permanente. También elimina la condición que hacía un trabajo útil, y la próxima persona que revise la directiva no sabrá por qué cambió. Haga que el propietario confirme la directiva prevista, para que la aceptación siga siendo deliberada.

Reintente una vez y luego compare

Repita el mismo perfil después de la única corrección que haya identificado. Si se acepta el acceso y un recurso interno sigue fallando, el fallo se ha trasladado a otra capa y ya no dice nada sobre la contraseña. Mantener el perfil sin cambios es lo que hace significativa esa comparación.

Resista la tentación de desactivar una familia de direcciones o de activar el seguimiento detallado antes de que se explique la denegación. El seguimiento produce volumen y no una decisión, y el primer resultado útil sigue siendo el componente que rechazó el intento y el motivo que registró. Una vez conocido, el reintento confirma la reparación o produce un síntoma nuevo y más estrecho.

Artículos relacionados