The Case for Azure AD Join

There’s no dispute that the direction of IT travel is toward the public cloud. However, there’s still a lot of on-premises – dare I say “legacy” – infrastructure that remains in place for various reasons, not positioned to migrate any time soon. 

For instance: file servers mapped to network drives, and Group Policies running on a Windows server that controls devices and applications are the most common examples.  For around two decades, Active Directory Domain Services has been the backbone of that infrastructure.

A Brief History

Then, around 2010 Azure came on to the scene and started to disrupt things.  There was this new thing called Azure Active Directory, which was sort of like our old on-premises friend and even synchronized with it.  However, it didn’t speak the same protocols (out went Kerberos, in came OAuth), it didn’t have the same hierarchical nature, and it didn’t provide a way of controlling device policies. 

For many, Azure initially existed as a gateway to Office 365.  As time went on, IT professionals began to realize it provided so much more – from Single Sign-On (SSO) to Software-as-a-Service (SaaS) applications; easy deployment of multi-factor authentication (MFA) and guest users, even a self-service password reset.  Adoption boomed.

But despite the growing acceptance of Azure AD to manage identities, one of its main advantages as a platform that manages and secures identities is Azure AD join (AADJ) – still a bit controversial, eliciting hesitation amongst many IT professionals. 

In this article, I will delve into the justifications for switching to Azure AD join, break down some myths around it, and explain why your default position should be Azure AD join.

Read more: Azure Active Directory Premium – Where to Start

What is Azure AD join, and why bother?

When a Windows device is Azure AD joined, its computer object is no longer stored in the on-premises Active Directory Domain Services environment.  Instead, it’s in Azure AD. 

This represents a fundamental change in how IT teams have dealt with computers for the past twenty years, partially explaining the aversion around Azure AD join rather than on-premises domain join. Any change to a well-established process must be fully understood and justified.

One of the main differences is, instead of Windows sign-ins authenticating against domain controllers and requiring line of sight to them, Azure AD joined devices authenticate against Azure AD in the cloud.  A device is issued with a Primary Refresh Token (PRT) which enables SSO to Azure AD resources such as Office 365. This brings instant benefits, magnified because of the pandemic and global adoption of remote work.

With this, dependencies on VPNs and connections to on-premises servers (and the management overhead associated with them) begin to matter less.  While it’s true that credentials are cached for offline sign-in in both join scenarios, the massive advantage Azure AD join has is for provisioning new devices with services like Autopilot when straight-to-user drop shipping – you don’t need to factor in pre-logon VPNs, for example.

Security

There’s a strong security case for Azure AD join as well.  Securing Active Directory Domain Services is no simple task.  Lateral movements in on-premises domains are one of the most common methods attackers use to escalate their privileges and establish dominance in your infrastructure. 

In terms of a long-term roadmap, phasing out an on-premises Active Directory significantly reduces the attack surface by removing Kerberos and New Technology LAN Manager (NTLM) along with their associated pass-the-hash exploits.

Myths about Azure AD join

Azure AD join clearly makes sense if your organization has made the cloud-only technological transition, or if they were “born-in-the-cloud”.  Unfortunately, many organizations are not in the position to make this jump yet and still need Windows devices to access things such as:

• File servers / mapped network drives
• Network printers
• Internal applications
• Internal certificate authorities

Basically, a bunch of important stuff using an Active Directory user account for authentication with Kerberos or NTLM.

The Reality

This is where things get interesting, but also misconstrued.  While it’s a fair statement that Azure AD doesn’t “talk Kerberos” or “talk NTLM”, your Azure AD joined devices can, allowing SSO resources that need them and assuming a few prerequisites are met.

First, you’ll need line of sight to both the resource and your on-premises domain.  Azure AD joined devices don’t possess magical capabilities, and are still constrained to the rules of how these protocols and basic networking operate. 

Second, the user account must be synchronized to Azure AD with Azure AD Connect.  This is what “marries” the authenticated Azure AD user account with the on-premises AD account the resource needs for authentication.  When Azure AD Connect synchronizes users to the cloud, it includes information identifying their source domain and account. 

What this enables for the Azure AD joined device is the ability to engage in Kerberos and NTLM ticket gathering, assuming that the first prerequisite of domain controller line of site is satisfied.  Practically speaking, this means SSO still works for services using that user account for authentication and authorization, such as a mapped network drives and apps using Integrated Windows Authentication.

Group Policy

Group Policy is an integral part of Active Directory, and while it’s true that it does not exist for Azure AD joined devices, Mobile Device Management (MDM) policies can largely replicate what it does.  There are even tools within Intune to analyze your existing Group Policy and how it can be replicated within MDM, though best practice is usually to start from scratch and only introduce what you really need, rather than “lift and shift”. 

Because MDM via Intune is driven from cloud-based internet resources, you can rapidly deploy changes and apps to clients with no reliance on making sure users connect to a VPN or manage the infrastructure of something like Configuration Manager Cloud Management Gateway. 

If you use Microsoft Defender Antivirus, an additional bonus to going MDM-only for device management is the enablement of ‘Tamper Protection’, a security benefit to protect the device’s security suite against accidental or malicious changes.  This feature is not compatible with Group Policy, and such compatibility positions are likely to be seen more and more.

When Azure AD join may not be appropriate

There are two different lenses from which to view this topic: technical reasons, and non-technical reasons. 

From a technical perspective, since Azure AD joined devices aren’t storing computer objects in on-premises AD, any services that rely on the presence of the computer – not the user – may result in object(s) having problems.  This can sometimes include trust relationships, Remote Authentication Dial-In User Service (RADIUS) services, and other network authentication and authorization processes. 

There is also no first-party equivalent of a security mainstay in Active Directory environments like the Local Administrator Password Solution (LAPS).  While there are community-driven alternatives and third-party options, many internal governance processes won’t allow those, and IT pros generally like having the fallback of only working with services supported by their trusted vendors. 

Before using Azure AD join, if you currently use LAPS, only compare the pros of Azure AD join to the cons of not having LAPS.  Think about what scenarios you use LAPS for, and what could be done instead, such as the use of Azure AD groups and services like Azure AD Privileged Identity Management.

From a non-technical perspective, the main blockers for Azure AD join tend to be resource-based.  For instance – finding staff skilled in the new Azure AD and Intune services; upskilling existing team members; allocating time to assess your Group Policy and what should be configured in Intune to replicate it, as well as assessing your on-premises dependencies to confirm nothing will break. 

While these are all valid concerns, the point is they’re resource-based, and can be overcome with time, training, and proper management.

What about hybrid Azure AD join?

A third option does exist – hybrid Azure AD join.  In this scenario, devices are still homed as computer objects in Active Directory Domain Services but are also synchronized by Azure AD Connect to Azure AD as computer objects.  Like Azure AD joined devices they get a PRT token for SSO, can retrieve policies over the internet from Intune, and ensure backwards compatibility with services that need a computer object in on-premises AD. 

Doesn’t this sound great, and why not just use this approach to begin with, since it has the best of both worlds?

So, for existing devices that aren’t going to be reprovisioned any time soon, I agree with this approach: hybrid Azure AD join is a great solution you can roll out without too much time or risk, allowing you to use services like Intune for cloud management. 

However, we should take a step back and consider the problems that will persist if you continue to use hybrid Azure AD join for all new user accounts. The user will still need to authenticate to an on-premises domain controller; the computer is still part of that chain in lateral movement attacks; and at the point of provisioning, your Autopilot approach is going to be considerably longer and challenging, with the need to establish VPNs and wait on devices to synchronize to the cloud. 

Conclusions and a call to action

There is no simple migration tool to jump devices from on-premises joined to Azure AD joined.  Devices must either leave the domain and re-join to the cloud or be reprovisioned entirely.  Therefore, a common (and encouraged) approach is to only Azure AD join new devices or those being reset anyway during things like upgrades or troubleshooting. 

Co-existence of Azure AD joined, and on-premises joined devices is perfectly normal with organizations making the transition. Using the hardware refresh cycle to your advantage makes sense in order to avoid user disruption, and ensure you are not biting off more than you can chew.

The great news is, you don’t need to take my word for it – Azure AD join is gaining traction and momentum across the IT community.  Through articles like this, the myths and incompatibilities are constantly being dispelled.  It’s a great way to reduce the complexity of your device deployments while getting the ball rolling to eliminate on-premises dependencies.

Additionally, you can very easily start to test Azure AD join yourself.  Simply spin up a Windows 10 (or 11) virtual machine or physical device, and during the out-of-box experience, join Azure AD instead of the on-premises domain. 

There’s little configuration needed in Azure AD and Intune to enable this. You simply verify that the user’s permissions allow it, and if you have Intune, ensure it’s properly enabled for the user too. 

From there, you start installing apps and accessing resources.  Punch in your network paths and confirm that Explorer loads network locations; open Edge and try to SSO into any internal web apps; connect to network printers, and so on. 

It’s not as daunting as it might seem, but if you encounter any problems, just know that you aren’t the first! If you have questions, please comment below.