In my previous post, I talked about the new VPN support for user-driven Hybrid Azure AD Join. I described the key VPN requirements:
- The VPN connection either needs to be automatically established (e.g.
“always on”) or it needs to be one that the user can manually initiate from the
Windows logon screen. For the “manually initiate” case, that typically means a VPN client that leverages the RAS capabilities and pre-logon authentication hook (PLAP) capabilities that has been in Windows for several years.
- The needed VPN configuration needs to be applied during device ESP. Usually this means a Win32 app delivered by Intune. The configuration of those Win32 VPN clients varies by vendor, but often this configuration is bundled into the installer itself (not delivered separately).
As the official docs don’t get into the specifics for what third-party VPN clients can be used, I thought it would be useful to review what will and won’t work. In many cases, that really means what we think will work, because we don’t happen to have environments available to try out all of these VPN solutions ourselves. But we can read their public documentation, looking for specific capabilities.
First though, let’s talk about what we know won’t work today:
- Third-party UWP VPN plug-ins. There are some UWP-based VPN plug-ins available in the Microsoft Store, but these cannot be installed and used prior to the user signing into the device. Hence you need to use a “fat” VPN client, a Win32 app that can be deployed to the device, or alternatively the in-box Windows VPN client.
- User certificate authentication. You can’t deliver a user cert to a device before the user signs in, and if the user can’t sign in before getting that user cert, then you can see the obvious chicken-and-egg problem.
- DirectAccess. While we can provision the offline domain join blob over the internet, the ODJ Connector doesn’t have the ability to deliver the needed certificates and polices as part of that ODJ blob. (You can provision DirectAccess later if you want, since the GPOs can be applied with VPN connectivity.)
So let’s do a quick run-through of the third-party VPN clients that we believe will work, either based on customer reports during the private preview process or on our reading of the available documentation.
- Cisco AnyConnect. This supports a feature called “Start before logon” (SBL) that integrates with the Windows logon screen using PLAP. This feature needs to be explicitly enabled as described in the Cisco docs.
- Pulse Secure. As described in the Pulse Secure documentation, the “Credential provider for Windows” feature enables users to establish a VPN connection prior to signing into Windows.
- Palo Alto Global Protect. The “Pre-logon” feature described in the Global Protect documentation also enables users to establish a VPN connection prior to signing into Windows.
- Checkpoint. While I don’t seem to be able to access the Checkpoint documentation around this any more, it did describe the “Auto Connect / Always Connected” feature that enables the device to automatically establish a VPN connection.
- Citrix NetScaler. The “AlwaysON” feature described in the NetScaler documentation describes the available option for establishing a VPN connection (although the authentication requirements are not clear).
- SonicWall NetExtender. The “NetExtender On Startup” feature as described in the SonicWall documentation enables a VPN connection prior to the Windows logon process.
- F5 BIG-IP Edge Client. The F5 documentation describes a “Dialup Entry/Windows Logon Integration” feature that enables the user to establish a VPN connection from the Windows logon page.
For those of you who have already set up one of these VPN clients to be deployed via Intune for the Autopilot VPN scenario, if you are willing to share the specifics of the configuration (e.g. the Win32 app setup and any related device configuration profiles), let me know.
It’s also possible to use Windows Always On VPN device tunnels. As I noted in a past blog post, this is a little tricky to set up, but once it is set up it works well. As noted in the Intune “In Development” documentation, there is work being done to make the device tunnel profile easier to create:
When you create a VPN profile using the IKEv2 connection type, there are new settings you can configure (Devices > Configuration profiles > Create profile > Windows 10 and later for platform > VPN for profile > Base VPN):
- Device Tunnel: Allows devices to automatically connect to VPN without requiring any user interaction, including user log on. This feature requires you to enable Always On, and use Machine certificates as the authentication method.
- Cryptography suite settings: Configure the algorithms used to secure IKE and child security associations, which allow you to match client and server settings.
So that is coming soon.
If you have questions about which VPN clients will work, please see the second part of this post: Windows Autopilot user-driven Hybrid Azure AD Join: Which VPN clients work?
Categories: Windows Autopilot
I managed to get this working on Sunday Night (5th July), as well as my other tests on Monday and Tuesday (6th & 7th July).
– Created Windows Autopilot Deployment Profile with the new feature: Skip AD connectivity check (Preview): Yes
– Created Enrollment Status Page (ESP) with Win32 App: Cisco AnyConnect Secure Mobility Client v4.8.01090 + SBL (Start Before Login) to get installed.
– Already had an existing Configuration Profile to join domain that targets the OU in Active Directory.
– Created a pilot Azure AD Group
As per my tests, everything worked fine as it loaded to the ‘Login Screen’ with the domain. The thing that annoyed me that I had to wait between 1 1/2 to 3 hours for the ‘Network Sign-In’ to show up on the Login Screen. Once I click on ‘Network Sign-In’, it loads to the Cisco AnyConnect Secure Mobility Client v4.8.01090 + SBL, asks me to enter my credentials then once connected, it will show up with two more icons (one is ‘Network Sign-in’ and the other is ‘Disconnect’.) I can then login to the machine with my credentials.
Is there any reason why I have to wait 1 1/2 to 3 hours for the ‘Network Sign-In’ to appear on logon?
No, there shouldn’t be. The Windows login page checks for two things to display the network sign-in icon: Is the device AD-joined, and is there a per-machine RAS/VPN connection defined.
I actually managed to get this working instantly, it was just after I posted my reply. The ‘Network Login’ Shows up fine both in Hybrid Azure AD Join as well as Azure AD Join.
The Citrix Always On (VPN) Service works pretty well for Device-level VPN tunnel, check out for more details https://hmaslowski.com/home/f/windows-autopilot-hybrid-azure-ad-join-via-citrix-always-on-vpn
I was able to make it work with L2TP pre-shared key against Meraki VPN and Azure AD MFA.
Wrapped VPN deployment in a IntuneApp via w32.
Love to share more!
LikeLiked by 1 person
Thanks Michael, I currently have FortiClient configured successfully with this method. The configuration is set to ‘Enable VPN before logon’ and the user has to manually initiate before logon
I would love to get some assistance with your above offer to share how you setup Meraki VPN with Intune. Are you able to reach me or advise on best way to reach you?
Thank you Michael for the good news.
I am currently trying to setup a test with Palo Alto Global Protect.
Having an issue with applying the device certificate in advance to be able to make the connection.
It is stuck on the ESP page with message : Certificates (0 of 1) applied.
We usually have the device certificate after the user logs in.
Is there a good article around this for setup or troubleshooting?
Similar setup than Bernard Mah . i had machine successfully hybrid joined over vpn using cisco 4.7.04056.
I used LOB app however just being curious and not win32 apps.
just using regular switch /qn /norestart .
Device preparation and Device Setup phase went very fast .
Was proposed immediately to use network login and vpn in . now waiting on the account setup part to do its job …