As a consultant, I want to share with you why Hybrid Azure AD Join ensures digital success. I’ve recently been working with a client around Windows Autopilot and Hybrid Azure AD Join. Here are my thoughts on the process.
Autopilot gives administrators the capability to deploy Windows 10 devices in the wild. Meaning a device can be purchased off the shelf and built to corporate standards without the need for the device being given to the administrator (there is a need to get some additional information before it can be enrolled into Intune but we will skip over that for now!).
Now, Autopilot works well when the device is just registered to Azure Active Directory (AAD) and accessing services through Microsoft’s Cloud Directory. However, what happens when that device needs access to services on-premises, and these services are not published through AAD? Well, that’s when Hybrid Azure Active Directory (AD) Join comes along.
Hybrid Azure AD Join
Hybrid Azure AD Join ensures success as it allows devices to join both AAD and AD at the same time. This will allow access to on-premises services as well as benefiting from cloud-based features. Windows devices joined to AD can automatically be configured to join AAD through AAD Connect and a Service Connection Point (SCP) in AD.
But what about devices not built on the network? The scenario earlier whereby a device is built off the network but requires access to on-premises resources and so must be joined to AD. What about those devices? Well, they can be joined to AD and configured as Hybrid Azure AD Joined through the use of Autopilot Profiles and Work Profile Configuration Policies in Intune. However, they still require connectivity to a Domain Controller to complete the process and allow users to log on to the device.
But why does Hybrid Azure AD Join ensure success?
With the client I worked with recently this was the scenario, and we had to use a VPN client that could be connected to from the Windows 10 logon screen. Once the VPN was connected, we could log in on the device and access resources available through on-premises.
Now, this as a solution works OK. It does have some tricky bits to get through though:
- The VPN client must be installed through Intune. I’ve had to package the client up as a Win32 app with a script that installs some MSIs, copies file to the local C Drive, and edit the registry so the connection can be established.
- The VPN client must be established before the users log in. If your VPN client cannot be established before login, then this solution will not work.
- Users may have to sign in twice before logging in the first time. Once to the VPN and again to Windows. If a VPN client can establish a connection based on certificates (hello Always On VPN) then it would avoid this.
In the end, the client I was working with was able to get devices built, joined to AD and AAD and have users log in. We did have some issues with application deployment thereafter, but that’s for another time.
I should note that for this solution to work, a minimum of Windows 10 1903 with the December 2019 CU update is required. If using 1909, the same update is required. Windows 10 2004 works without an additional update.
Recommendation
I would recommend that if you have a requirement for remote device builds using Autopilot, look to have those devices Azure AD Registered only. I’m aware that this may not be possible for many organisations, but it should be something to aspire to. I would recommend the following when planning on using Autopilot:
- For applications that require access to on-premises resources, look to use the Azure AD Application Proxy to publish them to clients not joined to the local domain. This works very well for web-based clients but can also work for other client types if developed for Azure AD.
- Move to SaaS-based applications where possible. SaaS applications are typically web-based and can be integrated with Azure AD for SSO and secure access to the platform.
- Move email and files to Office 365. Exchange Online and SharePoint Online can be accessed on devices that are enrolled in Intune and Conditional Access policies can help secure access to devices within Intune only if required.
If you can achieve all the above it means that the device will have no requirement to be AD joined, making the Autopilot build process much simpler to use. I’m aware that this can all take time to achieve, and that is why solutions like the Hybrid Azure AD Join process through Autopilot with VPN support exist. But in my opinion, spending effort on moving applications and services to integrate through Azure AD is effort well spent, rather than trying to get Hybrid Azure AD Join working.
Don’t forget to keep up to date with all of our latest happenings through Facebook, Instagram, Twitter, and LinkedIn, or get in touch with us today!
