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.
PowerShell
Administrators can also implement this setting by running the following PowerShell command.
Set-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Control\Lsa’ -Name DisableDomainCreds -Value 1
Group Policy
Another option for implementing this setting is by enabling the following Active Directory Group Policy setting.
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network access: Do not allow storage of passwords and credentials for network authentication
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.
Scott
/ October 2, 2023Hi Richard, Been using all your resources extensively. The above issue is happening also with Windows 10 devices. I am running manual syncs as well letting Intune doing it’s automatic sync, and it does keep replacing the UseRasCredentials to 1. Are you aware of any fix?
Richard M. Hicks
/ October 3, 2023Yes. You can change this setting via GPO or the registry.
GPO: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network access: Do not allow storage of passwords and credentials for network authentication
Registry: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\DisableDomainCreds DWORD 1
Hope that helps!
Scott
/ October 3, 2023Thanks I will try that as part of a remediation script. Also I am thinking of using the Custom Profile and see if the new features are working, so I can just disable it from there instead.
Scott
/ October 8, 2023Hi Richard, I have created a Working Custom Profile, but the DisableRasCreds is not being applied. Guessing the current build of Windows (mine is 10.0.19045) does not support this yet. Do you know when this is being planned to be pushed to GA?
Also found out that setting either the UseRASCreds to 0 or setting the DisableDomainCreds to 1 breaks the “Always On” part of the VPN. It requires re-connecting the VPN since the Intune re-application of the VPN break the shared drives connection. So a lot of issues.
Richard M. Hicks
/ October 9, 2023I have no idea if/when Microsoft will release the DisableRasCredentials setting at this point. I wasn’t aware that setting UseRasCredentials to 0 breaks the “always on’ component, though. I don’t think I’ve encountered that problem before. I typically update this setting using Intune remediations and it seems to work reliably for me.
Scott
/ October 11, 2023Hi Richard,
I have set up the Custom Profile AOVPN. I have also set up the Remediation script to set “UseRasCredentials” to 0 and it is working (the rasphone.pbk does not revert back UseRasCredentials to 1). But after sometime the shared on-prem drives become inaccessible, I am unable to ping either the Short URL, FQDN or IP addresses of any on-prem resource. I then manually disconnect the AOVPN and re-connect it manually, and then everything works. Is it because my Custom profile is configured incorrectly? Or something else entirely?
Richard M. Hicks
/ October 12, 2023That’s unusual. I would expect if you have UseRasCredentials set to 0 it will continue to work. You might want to try enabling the following registry setting to see if it helps at all.
Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network access: Do not allow storage of passwords and credentials for network authentication = Enabled
Let me know if that helps at all!
Scott
/ October 12, 2023Hi Richard,
Thanks for update. Unfortunately that has not helped. The mapped drive for the on-prem resource gets broken. As soon as it did, I checked the event logs and noticed in Windows Logs > System, the following event ID 1014 with the error: “Name resolution for the name cath-file01.catholic.int timed out after none of the configured DNS servers responded.”
Richard M. Hicks
/ October 12, 2023Ok, that’s interesting. I have to assume it’s another DNS-related issue then. You’ve confirmed the DNS suffix for the VPN profile is configured correctly as well?
Scott
/ October 12, 2023Yes, as far as I know it is configured correctly. Because as soon as I disconnect and reconnect the VPN everything works perfectly.
Richard M. Hicks
/ October 13, 2023Ok, that’s quite unusual. Not sure why it start working after disconnect/reconnect. If it was a configuration issue I’d expect it to fail consistently.