Always On VPN and Autopilot Hybrid Azure AD Join

Always On VPN and Autopilot Hybrid Azure AD Join

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 Entra ID joined by default and managed using Microsoft Intune. Optionally, an administrator can enable hybrid Entra ID 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 Entra ID join might sound appealing, there are specific deployment scenarios that present some rather unique and challenging problems when using this option.

Offline Hybrid Entra ID 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 Intune device configuration policy. Certificates required to support the device tunnel can be deployed with Microsoft Intune and one of the certificate connectors for Intune.

Windows Professional

If a Windows 10 or 11 Professional device is configured using Autopilot, and hybrid Entra ID join 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/11 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.

  1. Open the Microsoft Endpoint Manager console and click on Devices > Configuration Profiles.
  2. Click Create profile.
  3. Select Windows 10 and later in the Platform drop-down list.
  4. Select Templates in the Profile type drop-down list.
  5. Select Edition upgrade and mode switch from the list of templates.
  6. Click Create.

Use the following steps to configure the settings for the configuration profile.

  1. Enter a descriptive name for the configuration profile in the Name field.
  2. Enter a description for the profile in the Description field (optional).
  3. Click Next.
  4. Expand the Edition Upgrade section and select Windows 10 Enterprise from the Edition to upgrade to drop-down list.
  5. Enter your multiple activation product key in the Product Key field.

    Always On VPN and Autopilot Hybrid Azure AD Join

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/11 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/11 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.

  1. Open the Microsoft Endpoint Manager console and click on Devices > Scripts.
  2. Click Add and select Windows 10.
  3. Enter a descriptive name for the configuration profile in the Name field.
  4. Enter a description for the profile in the Description field (optional).
  5. Click Next.
  6. Enter the location of the PowerShell script in the Script location field.
  7. 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 Enterprise Edition and allow the user to authenticate.

Subscription activation with a step-up upgrade to Enterprise Edition still requires that Windows Professional be activated first. To accomplish this, the embedded Windows 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 Professional edition. After activation is successful, subscription activation will once again upgrade the client to Windows Enterprise Edition.

Considerations

As you can see, the process of getting a Windows Professional edition client onboarded in a hybrid Entra ID 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/11 devices that are Entra ID joined only. Unless there is a specific requirement to manage client devices using on-premises Active Directory and group policy, consider choosing native Entra ID join with Autopilot and manage devices using Microsoft Intune exclusively.

Special Thanks

I would like to extend a special thank you to everyone in the Microsoft Intune community who provided valuable input and feedback for me on this topic, especially John Marcum, Michael Niehaus, and Sandy Zeng. Follow the #MsIntune hashtag on X to keep up on all things Microsoft Endpoint Manager.

Additional Information

Overview of Windows Autopilot

Windows 10 Subscription Activation

Windows 10 Always On VPN Class-Based Default Route and Microsoft Endpoint Manager

Windows 10 Always On VPN Device Tunnel and Custom Cryptography in Microsoft Endpoint Manager

Always On VPN IPsec Root Certificate Configuration Issue

Always On VPN Device Tunnel Status IndicatorWhen configuring a Windows Routing and Remote Access Service (RRAS) server to support Internet Key Exchange version 2 (IKEv2) VPN connections, it is essential for the administrator to define the root certification authority for which to accept IPsec security associations (SAs). Without defining this setting, the VPN server will accept a device certificate issued by any root certification authority defined in the Trusted Root Certification Authorities store. Details about configuring IKEv2 security and defining the root certification authority can be found here.

Multiple Root Certificates

Administrators may find that when they try to define a specific root certification authority, the setting may not be implemented as expected. This commonly occurs when there is more than one root certificate in the Trusted Root Certification Authorities store for the same PKI.

Always On VPN IPsec Root Certificate Configuration Issue

Certificate Selection

When running the PowerShell command Set-VpnAuthProtocol to define the root certification authority, PowerShell may ignore the administrator-defined certificate and choose a different one, as shown here. This will result in failed IPsec VPN connections from Windows 10 Always On VPN clients using IKEv2.

Always On VPN IPsec Root Certificate Configuration Issue

Certificate Publishing

This issue can occur when root certification authority certificates are published using Active Directory group policy. It appears that Windows prefers Active Directory group policy published certificates over those published directly in the Certification Authorities Container in Active Directory. To resolve this issue, remove any group policy objects that are publishing root certification authority certificates and ensure those root certificates are published in the Certification Authorities container in Active Directory.

PowerShell Script

A PowerShell script to configure this setting that can be found in my Always On VPN GitHub repository here. I have updated this script to validate the defined root certification authority certificate and warn the user if it does not match.

Additional Information

Set-Ikev2VpnRootCertificate.ps1 PowerShell script on GitHub

Windows 10 Always On VPN IKEv2 Security Configuration

Windows 10 Always On VPN IKEv2 Load Balancing and NAT

Windows 10 Always On VPN IKEv2 Features and Limitations

Windows 10 Always On VPN IKEv2 Fragmentation

Windows 10 Always On VPN IKEv2 Certificate Requirements

Always On VPN Device Tunnel Operation and Best Practices

Always On VPN Device Tunnel Operation and Best PracticesUnlike DirectAccess, Windows 10 Always On VPN settings are deployed to the individual user, not the device. As such, there is no support for logging on without cached credentials using the default configuration. To address this limitation, and to provide feature parity with DirectAccess, Microsoft later introduced the device tunnel option in Windows 10 1709.

Device Tunnel Use Cases

The device tunnel is designed to allow the client device to establish an Always On VPN connection before the user logs on. This enables important scenarios such as logging on without cached credentials. This feature is crucial for organizations who expect users to log on to devices the first time remotely. The device tunnel can also be helpful for remote support, allowing administrators to manage remotely connected Always On VPN clients without having a user logged on. In addition, the device tunnel can alleviate some of the pain caused by administrators resetting remote worker’s passwords, or by users initiating a Self-Service Password Reset (SSPR).

Device Tunnel Requirements

The device tunnel requires Windows 10 Enterprise edition 1709 or later, and the client device must be joined to the domain. The device tunnel must be provisioned in the context of the local system account. Guidance for configuring and deploying a Windows 10 Always On VPN device tunnel can be found here.

Device Tunnel Authentication

The device tunnel is authenticated using a certificate issued to the client device, much the same as DirectAccess does. Authentication takes place on the Routing and Remote Access Service (RRAS) VPN server. It does not require a Network Policy Server (NPS) to perform authentication for the device tunnel.

Always On VPN Device Tunnel Operation and Best Practices

CRL Checking

Eventually an administrator may need to deny access to a device configured with an Always On VPN device tunnel connection. In theory, revoking the client device’s certificate and terminating their IPsec Security Associations (SAs) on the VPN server would accomplish this. However, Windows Server RRAS does not perform certificate revocation checking for Windows 10 Always On VPN device tunnel connections by default. Thankfully an update is available to enable this functionality. See Always On VPN Device Tunnel and Certificate Revocation for more details.

Configuration Best Practices

As the device tunnel is designed only to support domain authentication for remote clients, it should be configured with limited access to the on-premises infrastructure. Below is a list of required and optional infrastructure services that should be reachable over the device tunnel connection.

Required

  • All domain controllers
  • Enterprise DNS servers (if DNS is running on servers other than domain controllers)

Optional

  • All issuing certification authority (CA) servers
  • All certificate services online HTTP responders
  • All certificate services Online Certificate Status Protocol (OCSP) servers
  • System Center Configuration Manager (SCCM) distribution point servers
  • Windows Server Update Services (WSUS) servers
  • Management workstations

Limiting Access

Limiting access over the Always On VPN device tunnel can be accomplished in one of the following two ways.

Traffic Filters

The administrator can configure traffic filters on the device tunnel to restrict access only to those IP addresses required. However, be advised that when a traffic filter is enabled on the device tunnel, all inbound access will be blocked. This effectively prevents any remote management of the device from an on-premises system over the device tunnel.

Host Routes

An alternative to using traffic filters to limit access over the device tunnel is using host routes. Host routes are configured with a /32 prefix size and define a route to a specific individual host. The following is an example of host route configuration in ProfileXML.

Always On VPN Device Tunnel Operation and Best Practices

Note: A PowerShell script that enumerates all enterprise domain controllers and outputs their IP addresses in XML format for use in ProfileXML can be found here.

Caveats

Some organizations may have hundreds or even thousands of domain controllers, so creating individual host route entries for all domain controllers in profileXML may not be practical. In this scenario it is recommended to add host routes only for the domain controllers that belong to the Active Directory site where the VPN server resides.

Supportability

Do not use the <DomainNameInformation> element in ProfileXML or enable force tunneling for the device tunnel. Neither of these configurations are supported.

Tunnel Coexistence

The device tunnel can be safely deployed in conjunction with the user tunnel whenever its functionality is required.

DNS Registration

If the device tunnel and user tunnel are both deployed, it is recommended that only one of the tunnels be configured to register in DNS. If the device tunnel is configured to register its IP address in DNS, be advised that only those devices with routes configured in the device tunnel VPN profile will be able to connect remotely to Always On VPN clients.

Additional Information

Windows 10 Always On VPN Device Tunnel with Azure VPN Gateway

Windows 10 Always On VPN Device Tunnel and Certificate Revocation

Windows 10 Always On VPN Device Tunnel Configuration with Microsoft Intune

Windows 10 Always On VPN Device Tunnel Does Not Connect Automatically

Windows 10 Always On VPN Device Tunnel Missing in Windows 10 UI

Deleting a Windows 10 Always On VPN Device Tunnel

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell