Using Microsoft Endpoint Manager (Intune), administrators can provision Always On VPN to devices that are Azure AD joined only. Users accessing on-premises resources from these devices can still use seamless single sign-on, making this deployment option popular for organizations moving to the cloud.
Short Names
After deploying Always On VPN to Windows 10 devices that are Azure AD joined only and configured to use client certificate authentication, administrators may find that users cannot access on-premises resources by their short name, such as \\app1. The connection fails and returns the following error message.
“Windows can’t find <servername/sharename>. Check the spelling and try again.”
FQDN
Interestingly, on-premises resources are accessible using their fully qualified domain name (FQDN), such as \\app1.corp.example.net.
Troubleshooting
Testing name resolution using the short name works as expected, and the resource is reachable at the network layer, as shown here.
Workaround
This issue is related to how Windows performs authentication when connected via VPN. To resolve this issue, edit the rasphone.pbk file and change the value of UseRasCredentials to 0. Rasphone.pbk can be found in the $env:AppData\Microsoft\Network\Connections\Pbk folder.
After updating this setting, restart the VPN connection for the change to take effect.
Proactive Remediations
While helpful for testing, editing rasphone.pbk manually obviously does not scale well. To address this, consider using Intune Proactive Remediations. Intune Proactive Remediations allows administrators to deploy detection and remediation PowerShell scripts to monitor specific settings and update them if or when they change. Proactive Remediations will ensure the setting is applied consistently across all managed endpoints.
GitHub Repository
I have created a new GitHub repository dedicated to PowerShell scripts for Endpoint Manager Proactive Remediations for Always On VPN. There you will find detection and remediation scripts for the UseRasCredentials settings change described in this article.
Additional Information
Always On VPN Endpoint Manager Proactive Remediation Scripts on GitHub
James Hawksworth
/ September 20, 2021Great, thank you! I’d noticed this, but being the only person using AzureAD-only in my company I didn’t put too much thought in to it. Excellent use of proactive remediation too 🙂
Bkd80
/ September 23, 2021We have discovered this issue during a 1000+ laptop deployment and fixed it with scheduled task editing the rasphone.pbk file, with a couple of other parameters (interfaces metrics, etc).
However, this is not a perfect solution as Intune now considers the VPN configuration policy as in error. I imagine that it detects that the pbk file was altered.
Sean Kenny
/ September 28, 2021More accurately whats broken,
1. Short name
2. non AD domain name suffix (AD=contoso.local, SPN=blah.contoso.com)
3. Any SPN with a port number at the end, like MSSQL by default
It also is broken on AD machines, its just a lot of domains now have the policy I mention below already configured. You can flip the key back and forth while already connected to the vpn, refreshing credential manager in control panel and running klist get commands and see it all in real time. Look at the Windows credentials and certificate based credentials section for ‘disabled by policy/admin’ vs entries added by ras dialing.
Fix you mention is per VPN profile as it relates to some horribly old code path for LSA to override the primordial credentials the user logged in with to authenticate, in this case to the KDC for kerberos. The system side fix is here, https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication
This equates to the ‘disabledomaincreds’ dword in SYSTEM\CurrentControlSet\Control\Lsa
The alternate credentials in SSO within the vpnv2 CSP are only any good if you have cert trust, or another cert that can be used for KDC auth, either of which is suboptimal compared to just having it use the strong credential the user logged into the system with, protected by hvci/cred guard etc etc.
Richard M. Hicks
/ September 28, 2021Thanks for the additional clarification, Sean!
Ronald Oosterloo
/ September 30, 2021Dear Richard,
We have a user-based AO VPN. So the script cann’t find the rasphone.pbk in the remediation file. do you know if we can change the script to a user-based one?
Greetz!
Richard M. Hicks
/ October 2, 2021The script I posted looks for rasphone.pbk in the current user’s profile, so it should work unless you have configured the user tunnel to run in the all users context. Also, be sure to run the script in the context of the user, not SYSTEM.
Sebastian Engel
/ June 27, 2023Once again, thank you Richard for providing such informations.
Just expirienced this described behaviour on multiple test clients. VPN profiles are deployed via PowerShell in SYSTEM context (via PSExec). Within the xml profiles the “UseRasCredentials” switch is set to “false”, nevertheless the rasphone has an entry of “UseRasCredentials=1”. As soon as I changed this setting to “0” it worked like a charm.
Clients are “only” onPrem AD joined, running Windows 10 21H2 atm.
Roger
/ September 11, 2023Thanks Richard! While I’ve applied the fix and believed it was running well for awhile. I noticed that userascredentials kept resetting back to 1. If the user tunnel was applied via a configuration profile in Intune, would this be causing it to reset back to 1? I’ve dug around in the VPN profile and couldn’t find anything.
Richard M. Hicks
/ September 12, 2023Yes. If the setting keeps reverting back to 1 it’s likely caused by Intune replacing the VPN profile during device sync. This is a bug that affects Windows 11. It’s been fixed for some scenarios with the August updates. Make sure you are fully updated and see if the issue persists.