Why Windows Offers the VPN Password to a File Server

Windows can bring up a tunnel and then offer the same account to a file server that has never heard of it. The gateway accepted the login; the share did not, and retyping the password changes nothing. Turning off credential storage for the whole computer looks like the fix and is not one. A native RAS connection carries a per-profile switch that states exactly this intent.

Identify Which Account Got Rejected

Read the prompt instead of dismissing it. The server name in the dialog, the domain printed beside the user name, and whether the prompt arrived before or after the tunnel formed each point somewhere different. A failure that names a share is not the same failure as one that names a host.

Confirm the resource answers at all before you argue about identity. A missing route, a typo in the server name and an account without share permissions produce three different symptoms, and only the last one concerns the identity Windows offered. Check whether the rejected account is the gateway account. If the VPN login is a remote-access identity owned by the gateway rather than a directory account, the file server has no reason to recognise it, and retyping the same password only repeats the same rejection. That distinction decides whether the next section applies to you at all.

Set UseRasCredentials on One Profile

The field is UseRasCredentials, and a value of zero stops that one connection from offering its RAS credentials to network resources. The change is scoped to a profile, which is the whole point: it has one documented meaning and it touches nothing else on the machine.

The security policy that blocks stored credentials for network authentication does the opposite, applying to every connection on the computer. Using it here would change behaviour for every resource the user opens next week, which is why it belongs outside this repair. UseRasCredentials is a RAS feature as well, so a third-party client with its own credential handling will ignore it. For those clients the vendor documentation is the only authority on whether the behaviour can be changed. Check which client owns the connection before editing a file that client never reads.

Edit the Phonebook That Owns the Connection

Find the phonebook that owns the connection before you open an editor. A connection created by the user lives in the roaming application data path, and one created for all users lives under the program data directory; the two files are independent. Editing the wrong one changes nothing, and the failure looks identical afterwards.

List both locations and confirm the full path of the file you intend to edit. A file under the wrong profile will be ignored even after you change it correctly, and the second failure looks exactly like the first.

Get-ChildItem "$env:APPDATA\Microsoft\Network\Connections\Pbk"
Get-ChildItem "$env:PROGRAMDATA\Microsoft\Network\Connections\Pbk"
Copy-Item "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk.bak"
Select-String -Path "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" -Pattern "UseRasCredentials"

Inside the section that carries the exact connection name, the switch is one line. Change only that value, and leave every other section as it was.

UseRasCredentials=1   becomes   UseRasCredentials=0

A file-wide replacement across every connection in the phonebook is not a single-profile change, and it surfaces weeks later when someone debugs an unrelated tunnel. Keep the backup beside the file until the change has been verified. If the device is managed, the owning deployment is where the setting should change, not a file under the user profile. Supported Windows versions expose a per-profile equivalent through the VPNv2 configuration service provider, and its version requirements need checking separately from those of the provider as a whole.

Verify With a Fresh Attempt

Disconnect, close the session that was open, and try again. An existing mapped drive or open file handle can keep using the identity it already authenticated with, so anything that works through an old session proves nothing about the change. Confirm the edited value first, with enough context to show the section it belongs to.

Select-String -Path "$env:APPDATA\Microsoft\Network\Connections\Pbk\rasphone.pbk" -Pattern "UseRasCredentials=0" -Context 4,0

Then confirm which identity the resource actually received. A share that still refuses access with the correct account is an authorisation problem, and the file server's own log is where that answer lives. The documented description of this setting covers the deployment where the VPN identity differs from the directory identity, and it is worth reading before you assume the field applies to your client. Record the change, the phonebook path and the account the resource now sees, because the next person to hit this starts from the same confusion.