Always start with Azure AD Join
So this has been an interesting debate for the past few years as I have worked with various customer working towards a modern approach to Windows 10. Whether modern means Hybrid or Full Azure AD Join. In this Blog I will talk about rational of Azure AD vs Hybrid and in future Blogs on how I achieve an Enterprise Ready Azure AD Join Configuration.
First of all I totally understand where many organizations are coming from, so much about Azure AD Join is "NEW" and new is sometimes scary especially when there is an option for "Hybrid". Which many would say its best of both? RIGHT! Well lets unpack that.
So what is Hybrid or Hybrid Azure AD Join in terms of Windows 10 Deployments? Hybrid means we are maintaining a legacy trust relationship to On Premise Active directory while creating a registered trust relationship in Azure Active Directory. This trust relationship we refer to as Hybrid Azure AD Join, don’t let the name fool you, this is not Azure AD Join, but only "Known" to Azure AD. The entire trust relationship still lives on premise and so the frustrating dependency of line of sight will always exists. So hybrid is still AD join just with a registration in Azure.
Azure AD Join means we are no longer creating or maintaining the trust relationship of the device to anything on premise, but instead creating the trust relationship directly into Azure AD. This is a modern approach.
So as we unpack this further I hear many objections when I say to customers "Before we jump strait into Hybrid, let's start with Azure AD join and talk about why this won't work for you?"
In most situation I get responses like the ones below:
We just aren't ready for Azure AD Join
We have too many on-premise applications
All of our SMB File Shares are On Premise
We are too invested in group policy
We just aren't ready for Azure AD Join? Huh! Of Course you aren't, you're talking to a consultant, but like all worthwhile projects you need to start somewhere. In terms of projects I have worked on when IO want to look at reducing complexity and ensuring a general high satisfaction from a solution Azure AD Join is the best place to start, and in the end we often find the effort of Azure AD join was far less intensive than attempting a Hybrid Join Adoption especially in terms of Autopilot and Modern Deployment Methods. We can unpack in a later Blog post. But in General Azure AD join is Quicker, Cleaner, and generally provides the best customer satisfaction in terms of end result. Much of that is because of the following:
NO Group Policy Processing Resulting in Faster Boot and better Performance
NO On Premise Infra no Line of Sight or Complicated AUTH Models (Device Kerberos)
Cloud Ready because its Cloud Native.
We have too many on-premise applications? This is an interesting statement and a common misconception. Just because our devices trust relationship is bound to Azure AD, Does NOT mean our users Identity is! (Though it could be for Native Azure AD Users) But in most Enterprises we have heavy on-premise dependencies and for this reason syncing your on-premise users account to Azure AD creates what we call Hybrid Azure AD Users, this means we maintain the users identity anchor On-Premise but AUTH to our Azure AD join Device and other Azure AD Services using our native Cloud Identity but for existing resources we can AUTH against On-premise Active Directory to provide really "The Best of Both Worlds"
What is hybrid identity with Azure Active Directory? | Microsoft Docs
All of our SMB File Shares are On Premise? So this is really a continuance to the previous statement. We are still maintaining our identity relationships in both on-premise and cloud, for this reason our user is still trusted in Active
Directory and that Kerberos challenge is still satisfied. Remember the trust is in the identity up to this point we really could care less about where the trust of the device is.
How SSO to on-premises resources works on Azure AD joined devices | Microsoft Docs
We are too invested in group policy? My Typical response when I hear this is, "Well then now is the time to move away from Group Policy" for any one working in windows Performance will tell you Active Directory Group Policy Management is only Second to most Security Stacks as the largest contributor to performance related user complaints, and in many Organizations Group Policy has been the Band-Aid that just keeps giving over the years turning into a mess many organizations don’t know how to address. My recommendation here is to "Leave it Behind" When I start with Azure AD join I don’t even look at existing Group Policy but start with a solid foundation focusing on customer needs, only referring to Group Policy for those one off application requirements. These have been replaced in Windows 10 with CSPs.
Configuration service providers for IT pros (Windows 10) - Configure Windows | Microsoft Docs
Custom Microsoft Intune OMA-URI Policy ins-and-outs – Jeff Gilbert's Cloud
Well I hope you find some value in this post. My Next will dive in Azure AD join Configurations, Just remember always START WITH AZURE AD JOIN, then work your way back!
