Azure AD join vs Hybrid Azure AD join

When transitioning from traditional management to modern management for Windows 10, the hardest part is deciding the device join state – whether to go with Azure AD join or Hybrid Azure AD join?

This decision about the device join state is critical. Ask me why?

Because it determines how your IT for Windows environment will be designed going forward. A change in the device join state for existing devices will require reset/re-image and re-provisioning.

As such, if you are transitioning to modern management at present and choose to stay Hybrid with Hybrid Azure AD join, but down the line, you change your decision and decide to move completely to the cloud, then that would be another project in itself for changing the device join states of your existing devices.

The important factor that contributes heavily towards making the decision on the device join state is the requirements of the particular environment.

But before you can decide to either go cloud-native or the hybrid way, you need to know what works and what does not works for each of the approaches.

In this blog post, let us dive into the two different approaches via which you can embrace Windows 10 modern management, trying to understand the advantages and disadvantages that each approach will have.

This should help you to take a better shot at deciding which way you would want to go ahead with your Windows 10 modern management journey.

Windows Autopilot with Azure AD Join

This is the cloud-native approach where the device is “cloud-domain joined” to Azure AD as part of the Autopilot provisioning. The device also gets auto-enrolled to Intune (subject to auto-enrollment configuration), thereby receiving the applicable configured config policies and apps.

The below image outlines the device provisioning process of Windows Autopilot with Azure AD Join, from a high-level perspective.

Adopting cloud-only is not only a transition from traditional windows management to modern windows management but also a philosophical decision that you make about how your IT will be designed going forward. And the most important part of it is to let go of the thought of “keeping control of the endpoints” by virtue of traditional domain join.

Advantage of this approach

• Being cloud-native, no on-premises dependency makes this solution easy to configure, deploy, maintain and support in production.

• Deployment can be done from any location without any additonal configuration. User only needs to have an Internet connection with adequate bandwidth to support the deployment.

For those who would still prefer going the domain join route over the cloud-only Azure AD join path, I just need to mention here that you can do all the below-mentioned things on an AADJ Windows 10 endpoint as well.

• Drive letter mapping with Intune using ADMX and CSP and some powershell.
• Deploy printer drivers with Intune.
• Access on-premise file shares yet to be migrated to SPO by virtue of SSO.

You might need to spend a considerable amount of time analyzing and planning GPO migration to equivalent MDM settings. But eventually, that should be the way forward.

However, you also need to be aware of things that will just not work if you take down the cloud-only AADJ path.

Disadvantages of this approach

• Existing business critical “old-school” applications which requires hardcoded AD connectivity won’t work here. This is because these application uses LDAP to get required information from AD. Now Azure AD doesn’t supports LDAP as it isn’t a cloud-alternative of Active Directory.

• Scenarios which requires device authentication will fail. Check this example of NPS unable to Authenticate AAD Windows 10 Devices for Wireless Network (IEEE 801.X) access

• The native ways that are currently available to manage Local Admin passwords on the endpoints cannot match upto LAPS that’s only available with on-premises, as of now. However, there are many other solutions you can get from the community or you can checkout 3rd party products like AdminByRequest for the same.

• Conditional Access, an important part of your Zero-Trust strategy, does not have Azure AD joined option as a condition. As such, if security requires Hybrid Azure AD joined as a condition to pass through, this is not your option.

If the disadvantages listed above do not make up the “typical requirement”, then you should consider going the cloud-native path with Azure AD join.

However, if you still wish to go the hybrid way, then continue reading…

Windows Autopilot with Hybrid Azure AD Join

This is the hybrid approach where the device first gets enrolled to Intune during the autopilot process to receive the ODJ blob to complete the “domain join” process post which it waits for AAD Connect to sync the on-prem device object to Azure AD resulting in the creation of the 2nd device object with join state as Hybrid Azure AD join.

Note that the process requires a line-of-sight to the Domain Controller, as such the devices must be connected to the corporate network for the provisioning to happen. AD connectivity can also be made possible via VPN for device provisioning over the Internet.

Note that there was already a device object in Azure AD for the device with join state as Azure AD join which gets created due to the Autopilot registration. Once the HAADJ device object is created, Intune switches from the AADJ device object to the HAADJ device object for policy targeted to the device group.

A hybrid joined computer is joined to both the local AD and Azure AD (technically though, I would say it’s automatic registration in reality), but the AD join is primary because the device uses AD authentication.

A cloud-only user (created in Azure AD) who has no presence in the on-premise AD (no AD account) won’t be able to do a Windows login to a hybrid Azure AD joined computer.

Before we go into the advantages and disadvantages of this approach, I would want to clarify one thing here.

Hybrid AADJ and co-management are entirely different things and not co-related in anyways. You can have an AADJ device co-managed as well.

Advantages of this approach

• Flexibility to “keep control” over the endpoints using existing Group Policies and as well as taking benefits of MDM.

However, this exact advantage can turn into a disadvantage when you get yourself in a position where a particular GPO breaks the solution.

Example - When using WSUS for update management, you may have a group policy configured which sets the particular policy Do not connect to any Windows Update Internet locations. When enabled, it not only disables the Windows Update agent on the endpoint to retrieve information from the public Windows Update service, but also breaks the connection to public services such as the Windows Store. As such, you may encounter that your MSfB apps are failing to install.

For conflicting configuration where a particular setting is being targeted by both GPO and MDM with different settings value, control the policy conflict using MDMWinsOverGP.

Disadvantages of this approach

• If you are transitioning from traditional management (Current Mode of Operation) and choose the hybrid path as a stepping stone (Intermediate Mode of Operation) to modern management (Future Mode of Operation) which is cloud-only, then the move from HAADJ (IMO) to AADJ (FMO) is not that seamless as change in join state will require a reset/wipe operation.

• The architecture of HAADJ is complex enough in itself and the added components required to pull it off adds in more breakpoints to the process. As such, your IT support team might not be really happy with you deciding to go HAADJ.

At the end…Azure AD join vs Hybrid Azure AD join?

I won’t conclude that AADJ is better over HAADJ or vice-versa.

Though I would take AADJ over HAADJ anytime, in the end, it all boils down to your environment and the requirement.

As a modern management enthusiast, I would prefer the AADJ approach for net-new devices while going the HAADJ way for existing domain-joined devices (GPO Enrollment, and not Autopilot with HAADJ as it would imply for a fresh device provisioning).

This way, I can quickly enroll my existing devices to Intune and take benefit of modern management, while getting enough time to plan, analyze and migrate the current GPO config to MDM equivalent for consistency across the environment.

With every device refresh cycle, I can add more new devices to the environment provisioned via Autopilot with AADJ  (cloud-only) while reducing the HAADJ devices gradually.

Well, that was my thoughts on the topic. Hope it helps you to decide the device join state that you should go with when moving to the modern management of Windows 10.