Windows VPN Error 691: Which Check Actually Failed?

Windows rejects a password it accepted elsewhere a minute earlier, so the account looks broken when the attempt was never evaluated. Error 691 means the connection was refused during authentication, and the client prints the same text whether the secret was wrong, the account name resolved to an unexpected identity, or a server-side policy declined the connection. Three different repairs share one message, which is why a reset sometimes helps and sometimes changes nothing at all. Start with the part you can inspect alone: the exact string the client submitted and the credential store it drew from. Then ask the server which decision it recorded, because the dialog is a refusal and not a diagnosis.

Three ways to be refused, one dialog

A wrong secret is only the first way to reach this dialog. The account name can resolve to an identity you did not intend, the account may hold no dial-in permission, or a server condition may decline the connection after the password is accepted. Every one of those produces the same client text, and each has its own repair.

That is why a reset appears to work on Monday and does nothing on Tuesday. Read the dialog as a refusal rather than as a diagnosis, and note the profile name and the local time of the failure before touching the account.

The three categories also fail at different layers. A wrong secret fails the identity proof, a wrong account form fails the lookup, and a policy condition fails authorization after the identity is proven. Only the first is repaired by changing a password. The other two need someone with access to the server's decision record, which is why the next step is a request for information rather than another reset.

What the client actually sent

Confirm the accepted account format with whoever runs the gateway, because a bare user name, a domain-qualified name and a user principal name can resolve to different account contexts. Only one of them may be the identity that holds the permission. Ask which form the gateway expects before the first attempt rather than after the fifth, and check whether the client is reusing a stored credential instead of the one you typed.

Two read-only queries on the Windows machine show the profile and any cached credential that could win over the dialog. Neither one dials the server:

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

Treat the password as data rather than as text copied out of a document. A value that passed through a shell script may carry escape characters that were never part of the secret, and a configuration export may have quoted it. Removing every special character to make it fit is a different change from finding the real value, so establish the real value first.

Get the policy decision, not a reset

On a remote-access deployment that uses a network policy server, two decisions run in sequence. Authentication establishes which account is asking, and authorization decides whether that account may connect at all. Policy conditions and constraints are evaluated on their own terms, so a correct secret settles only the first half of the question. The policy name in the server event identifies which decision actually ran.

Send the administrator the profile name, the attempted account and the timestamp. Ask for the matching decision record and its reason rather than another password reset, and ask for the policy name that the event carries. Microsoft's remote-access error code reference lists 691 among the credential and authentication failures, which is exactly why the dialog cannot separate the three cases.

Converting an account to an unconditional allowance turns an authorization decision into a permanent exception. It also removes the condition that was doing useful work, and the next person to review the policy will not know why it changed. Have the owner confirm the intended policy instead, so acceptance stays deliberate.

Retry once, then compare

Retry the same profile after the single correction you identified. If access is accepted and an internal resource still fails, the failure has moved to a different layer and no longer says anything about the password. Keeping the profile unchanged is what makes that comparison meaningful.

Resist disabling an address family or enabling verbose tracing before the rejection has been explained. Tracing produces volume rather than a decision, and the first useful result remains the component that refused the attempt and the reason it recorded. Once that is known, the retry either confirms the repair or produces a new and narrower symptom.