Offline Files Access Denied over VPN

I just tried taking a Windows 10 laptop on the road for the first time.  Everything was great until I tried the VPN for the first time.  Suddenly, I was getting Access Denied errors, and “You do not have permissions” errors for all files made available offline.  I confirmed the VPN tunnel and even browsed to other shared folders on the same server.  The offline files errors persisted after dropping the VPN.

When I returned to the domain Wi Fi, file synchronization completed normally and there were no errors at all.

Am I to believe that Windows 10 is completely incompatible with VPN synchronization?  I never had a problem with this on Windows XP, and I am dreading the months of research and experimentation normally involved in fixing this kind of Microsoft failure.

07/01/2016 Update

The small amount of spare time I’ve been able to invest in this problem so far yielded the following results:

Disabling the slow link mode by configuring local GPO settings doesn’t change anything.

Completely disabling Offline Files prevents any kind of offline access or online synchronization, as expected.  However, the permissions errors still appear within the same folders when connected through a VPN tunnel.  This is the most interesting development so far, because it is the first indication to suggest the Offline Files system is working normally in Windows 10, while the underlying problem is a more basic failure of network file sharing.

What do the different folders have in common that are generating permissions errors?  The first suspect is the permissions settings themselves.  Shared files that I can still access over the VPN are available read-only to all domain users, with administrators having full control.  Strangely, with my administrator account I am unable to gain anything more than read-only access to those shared files when connected by VPN.  Looking at the sharing rather than the folder permissions, everyone is granted full control.

In the folders where I have no access, permissions are restricted to specific users.  It’s as if I am authenticating to the file server as a different user when the VPN is established.

Just to satisfy my curiosity, I tried changing the VPN credentials.  Ever since the Windows XP days, I’ve been using a separate account for VPN authentication so that any compromise of those remote dial-in credentials would not result in any data theft.  So instead of using my dummy VPN username today I tried using an account that should have file access when connecting the VPN, and miraculously, I am now gaining file access as if I was logged in as that user (and I am definitely not logged in as that user).

I am so confused now, but I seem to have proven that the VPN itself is interfering with file sharing authentication.

Preferred Solution

Through some creative Googling, I was able to connect the various symptoms to a working solution.  And I can’t believe how arcane this solution looks.  This actually involves finding the one file representing the VPN adapter some 9 directories deep in Microsoft land, then changing a variable from a 1 to a 0.  On my Windows 10 laptop, I found the file at:

C:\Users\{username}\AppData\Roaming\Microsoft\Network\Connections\Pbk\_hiddenPbk\rasphone.pbk

The username in this path is the correct login account which created the VPN connection, not the username specified for authenticating that connection.

Within that file, find this line:

UseRasCredentials=1

Change it to this:

UseRasCredentials=0

For some further reading, try the CoNetrix Blog.

Alternative Solutions

Given the incredibly arcane nature of the above solution, I should also point out some simple alternatives.

If you can connect to the VPN using the same username as the logged in Windows user, then the problem should go away.

If you can bypass Microsoft RRAS technologies by installing a 3rd-party solution such as OpenVPN, then the problem created by the Windows VPN adapter should go away.

Leave a Reply

Your email address will not be published. Required fields are marked *