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.
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
Zero Trust Network Access (ZTNA) is a term that administrators are likely familiar with, as it is one of the hottest marketing buzzwords in circulation today. ZTNA can mean different things depending on the deployment scenario. ZTNA is fundamentally about enforcing the principle of least privilege for endpoints connecting remotely to the corporate network when it comes to enterprise mobility and remote access.
Trusted Access
Historically, VPNs and even DirectAccess granted full, unrestricted network access to authenticated devices and users. Once the endpoint has an IP address, and in the absence of other controls (routing limitations, firewall access controls, etc.), the user could access any resource on the internal network. The rationale was that authenticated devices and users should be considered “trusted”.
Limitations
The Trusted Access model has some significant limitations. It assumes that all traffic from authorized users and devices is legitimate. However, if an endpoint is compromised, an attacker has broad access to the internal network, which is not ideal from a security perspective.
Zero Trust
Zero Trust Network Access is a concept where administrators define explicitly the minimum level of access required to support remote workers. Instead of granting full network access to the endpoint, controlling access using fine-grained policies is enforced on the VPN connection. Configuring limited network access for Always On VPN clients dramatically reduces exposure of the internal network to compromised endpoints.
ZTNA Management
There is a significant management burden associated with this approach, however. Administrators must identify each application requiring VPN access and determine all associated protocols and ports to be allowed, and internal resources to which they will communicate. Although this task isn’t difficult if clients require access to a small subset of internal resources, it can be a substantial undertaking if clients require access to many internal resources from numerous client applications.
Moving Targets
Making things more challenging is that application and network infrastructure often change constantly, requiring administrators to manage network access continually to ensure application availability. When adding new applications or changing the internal infrastructure, updating the configuration on all remote endpoints will be required.
Updating Always On VPN configuration for devices managed with Microsoft Endpoint Manager (formerly Intune) isn’t difficult. However, it can be more challenging when using PowerShell with System Center Configuration Manager (SCCM) or another endpoint management platform.
Traffic Filters
ZTNA can be configured with Always On VPN using Traffic Filters. With Traffic Filters, administrators can apply fine-grained access control for VPN traffic based on a combination of the following.
Source IP address (IP address, address range, or subnet)
Destination IP address (IP address, address range, or subnet)
Protocol (TCP, UDP, IP, etc.)
Source Port
Destination Port
Endpoint Manager Configuration
Configuring Traffic Filters for Always On VPN connections can be performed using Microsoft Endpoint Manager. Open the Endpoint Manager management console (https://endpoint.microsoft.com), navigate to the Always On VPN device configuration profile, then perform the following steps.
Expand App and Traffic Rules.
Click Add next to Network traffic rules for this VPN connection.
Enter a descriptive name in the Name field.
Select Split tunnel from the Rule type drop-down list.
Enter “6” in the Protocol field.
Enter “3389” in the Lower port and Upper port fields in the Remote port ranges section.
Enter an IPv4 address in the Lower IPv4 address field.
Enter an IPv4 address in the Upper IPv4 address field. Enter the same IPv4 address as the lower address to specify a single host.
Click Save.
The example above shows a traffic filter restricting access to TCP port 3389 (Remote Desktop Protocol) from all VPN clients to the 172.16.0.0/24 network.
Note: Repeat these steps to create as many traffic filters as required for any processes or applications that must communicate over the Always On VPN connection.
XML Configuration
Traffic Filters can also be configured using custom XML. To implement the same Traffic Filter described previously, add the following code between the <VPNProfile> and </VPNProfile> tags in your XML configuration file.
Note: Address ranges used in Traffic Filters can be defined using CIDR notation in XML, but they are not supported using Microsoft Endpoint Manager today.
Default Deny
When configuring a Traffic Filter for an Always On VPN profile, an implicit “deny all” rule is automatically enabled. Any traffic not explicitly defined in a Traffic Filter will be denied, including unsolicited inbound traffic, which has crucial implications for the device tunnel because it is used commonly for system management of remote devices.
Direction
Traffic Filters are enabled for the Outbound direction only, by default. Beginning with Windows 10 2004, Microsoft introduced support for Inbound traffic filters. Before Windows 10 2004, configuring a Traffic Filter on the device tunnel would break manage-out scenarios by denying all unsolicited inbound network access.
As of this writing, configuring inbound Traffic Filters using Microsoft Endpoint Manager is not supported. They are only configurable using custom XML.
To implement a Traffic Filter to allow inbound RDP access from the internal network over the device tunnel, add the following code between the <VPNProfile> and </VPNProfile> tags in your XML configuration file.
Note: When configuring inbound Traffic Filters, specify the port of the listening process or application using the LocalPortRanges field.
Application Filters
Administrators can combine Application Filters with Traffic Filters to control network access over the Always On VPN connection even more granularly. Applications can be defined by the following.
Package Family Name (PFN) – This is the unique name of a Microsoft Store application. Use the Get-AppxPackage PowerShell command to find the PFN for an application.
File Path – This is the full path to any executable on the file system. For example, c:\Windows\System32\mstsc.exe.
SYSTEM – This allows Windows kernel-mode drivers (such as ping.exe and net.exe) to send traffic over the Always On VPN connection.
As of this writing, configuring Application Filters using Microsoft Endpoint Manager is not supported. They are only configurable using custom XML.
Application Filter Examples
Below are three examples showing different Application Filters based on file path, Package Family Name, and SYSTEM.
File Path
This example shows a Traffic Filter configured to allow RDP access to an internal subnet using the native Windows Remote Desktop client (mstsc.exe).
Note: Ping uses ICMP (IP protocol 1), which is a network layer protocol. As such, defining ports for the filter is not required.
IPv6 Compatibility
Sadly, the filtering techniques described in this article do not work when also configuring IPv6 on the Always On VPN connection. As of this writing, enabling Traffic Filters when an IPv6 address is assigned to the VPN interface is not supported. More details can be found here.
Configuring Zero Trust Network Access (ZTNA) with Windows 10 Always On VPN is not trivial. Still, with attention to detail, it can be a highly effective tool to enforce fine-grained network access policies and reduce exposure of the internal network to compromised endpoints. Combining Traffic Filters with Application Filters allows administrators to tightly control Always On VPN access and ensure the principle of least privilege is applied.
Windows Autopilot is a cloud-based technology that administrators can use to configure new devices wherever they may be, whether on-premises or in the field. Devices provisioned with Autopilot are Azure AD joined by default and managed using Microsoft Endpoint Manager. Optionally, an administrator can enable hybrid Azure AD join by also joining the device to an on-premises Active Directory domain using a domain join configuration profile in conjunction with the offline domain-join connector. Although enabling hybrid Azure AD join might sound appealing, there are specific deployment scenarios that present some rather unique and challenging problems when using this option.
Offline Hybrid Azure AD Join
For field-based devices, the device must have connectivity to a domain controller to support the initial login when the user has no local cached credentials. The Always On VPN device tunnel can be deployed in this scenario to provide connectivity and allow the user to log in to a new device the first time without being on-premises. The Always On VPN device tunnel is easily deployed using a Microsoft Endpoint Manager configuration profile. Certificates required to support the device tunnel can be deployed with Microsoft Endpoint Manager and one of the certificate connectors for Microsoft Endpoint Manager.
Windows 10 Professional
If a Windows 10 Professional device is configured using Autopilot, and hybrid Azure AD joined is enabled, the Always On VPN device tunnel can still be provisioned, but it won’t start automatically because it requires Enterprise Edition to be fully functional. This prevents the user from being able to logon the first time. The device must be upgraded to Enterprise Edition before the first user logon. There are multiple ways to accomplish this depending on the deployment scenario and activation requirements.
Multiple Activation Key
The easiest way to upgrade Windows 10 Professional to Enterprise Edition is to obtain a Multiple Activation Key (MAK) and deploy that to clients using a Microsoft Endpoint Manager configuration profile. Follow the steps below to create a configuration profile to perform this upgrade.
Open the Microsoft Endpoint Manager console and click on Devices > Configuration Profiles.
Click Create profile.
Select Windows 10 and later in the Platform drop-down list.
Select Templates in the Profile type drop-down list.
Select Edition upgrade and mode switch from the list of templates.
Click Create.
Use the following steps to configure the settings for the configuration profile.
Enter a descriptive name for the configuration profile in the Name field.
Enter a description for the profile in the Description field (optional).
Click Next.
Expand the Edition Upgrade section and select Windows 10 Enterprise from the Edition to upgrade to drop-down list.
Enter your multiple activation product key in the Product Key field.
Once complete, assign the configuration profile to the appropriate groups and click Create.
KMS Activation
If Key Management Service (KMS) activation is required, follow the steps listed previously for MAK. Enter the KMS client setup key for Windows 10 Enterprise which is NPPR9-FWDCX-D2C8J-H872K-2YT43. The device will complete KMS activation when it can connect to the on-premises KMS host.
Subscription Activation
Windows 10 Enterprise Edition licensing is included in some Microsoft 365 subscriptions. This poses a unique challenge for hybrid Azure AD join scenarios, however. Specifically, subscription activation is a “step-up” process that requires Windows 10 Professional to have been successfully activated previously. Also, this occurs after the user logs on, but the user cannot log on unless the device tunnel is active. Catch 22!
Workaround
A multi-step process is required to address the limitations imposed by subscription activation. To begin, the device must be upgraded to Enterprise Edition, so the device tunnel is available for the initial user logon. This is a temporary, one-time upgrade to Enterprise Edition solely for the purpose of getting the device tunnel to connect and allow the user to authenticate.
To begin, download this PowerShell script and follow the steps below to deploy it to Windows 10 devices using Microsoft Endpoint Manager.
Open the Microsoft Endpoint Manager console and click on Devices > Scripts.
Click Add and select Windows 10.
Enter a descriptive name for the configuration profile in the Name field.
Enter a description for the profile in the Description field (optional).
Click Next.
Enter the location of the PowerShell script in the Script location field.
Click Next, then assign the script to the appropriate device group(s) and click Add.
The PowerShell script will automatically install the KMS client setup key for Windows 10 Enterprise Edition, then restart the network interfaces to ensure the device tunnel starts. This will immediately upgrade the client device to Windows 10 Enterprise Edition and allow the user to authenticate.
Subscription activation with a step-up upgrade to Enterprise Edition still requires that Windows 10 Professional be activated first. To accomplish this, the embedded Windows 10 Professional key must be re-installed on the client. To do this, download this PowerShell script and follow the same steps listed previously to deploy a PowerShell script with Microsoft Endpoint Manager. However, this script should be assigned to users, not devices.
Once this script is run on the client it will be downgraded (temporarily) to Windows 10 Professional edition. After activation is successful, subscription activation will once again upgrade the client to Windows 10 Enterprise Edition.
Considerations
As you can see, the process of getting a Windows 10 Professional edition client onboarded in a hybrid Azure AD joined scenario is somewhat complex. My advice is to avoid this scenario whenever possible. Access to on-premises resources with the Always On VPN user tunnel with full single sign-on support is still available for users on Windows 10 devices that are Azure AD joined only. Unless there is a specific requirement to manage client devices using on-premises Active Directory and group policy, consider choosing native Azure AD join with Autopilot and manage devices using Microsoft Endpoint Manager exclusively.
Special Thanks
I would like to extend a special thank you to everyone in the Microsoft Endpoint Manager community who provided valuable input and feedback for me on this topic, especially John Marcum, Michael Niehaus, and Sandy Zeng. Follow the #MEMCM hashtag on Twitter to keep up on all things Microsoft Endpoint Manager.
