• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint Online
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Videos
    • Interview Videos
    • How To Guide Videos
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Azure Active Directory / The Case for Azure AD Join

The Case for Azure AD Join

September 17, 2021 by Ruairidh Campbell 6 Comments

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.

Table of Contents

  • A Brief History
  • What is Azure AD join, and why bother?
  • Security
  • Myths about Azure AD join
  • The Reality
  • Group Policy
  • When Azure AD join may not be appropriate
  • What about hybrid Azure AD join?
  • Conclusions and a call to action

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.

Azure Active Directory, Blog Group Policy, Kerberos, Microsoft Defender Antivirus, Mobile Device Management, Multi Factor Authentication, New Technology LAN Manager, OAuth, Primary Refresh Token, Single Sign-On

About Ruairidh Campbell

Ru Campbell is a Public Cloud Technical Consultant, helping customers with security, compliance, and modern device management.  Specializing in Microsoft 365 Enterprise Mobility + Security and Microsoft Defender, you can connect with Ru on Twitter @rucam365.

Comments

  1. Jesse says

    September 23, 2021 at 7:56 pm

    If we intend to go this route and are currently on the Hybrid system would we continue to create the users in on prem AD or switch to creating them in Azure AD?

    Reply
    • Ru Campbell says

      September 26, 2021 at 4:22 pm

      Hi Jesse,

      AAD join supports either hybrid or cloud only users. Hybrid users created on prem will be required if you still need to SSO to on prem resources like file shares.

      Reply
  2. Ru Campbell says

    September 21, 2021 at 8:28 pm

    Hey Simon,

    Thanks for the feedback 🙂

    I see the hesitation of moving to Intune + Azure AD joined only too. Some of it is with good reason (no LAPS, huge custom images, air-gapped networks, etc) but to your point about fear of losing jobs, if that is the concern (and sometimes I see it too), it’s not a well-thought-out one. Our industry is not very forgiving to those who dig their heels into the ground.

    Reply
  3. Chris Johnston says

    September 18, 2021 at 4:24 pm

    Hey Ruairidh, I appreciate your post!

    We are on the path to migrate to Azure AD Joined devices, for all the reasons listed above (But it was great to see it so succinctly put) but the lack of LAPS is causing us a bit of a headache for our early deployment of a handful of devices. By default no user is an admin on their own box and we used LAPS to provide temporary access to the user for driver/software/personal printer installs.

    We have been playing with PIM to mitigate by allowing privileged IT users to support users by escalate their own privilege into the Azure AD Joined Device Local Administrator role, but we’re finding that doesn’t always ‘work’ and is one of the few roles not supported for PIM (https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-roles) .

    Right now I’m trialing a setup with Privileged Groups by adding a group and adding and removing members from that group, but still a work in progress there.

    Any guidance you might have on supporting non-admin remote users in an AAD Joined environment would be appreciated.

    Thanks!

    Reply
    • Ru Campbell says

      September 21, 2021 at 8:25 pm

      Hey Chris.

      Until we get native Azure AD LAPS, there’s some nice software out there that can let your end-users temporarily be local admins. I like Admin By Request for this, but there are others out there too. You could also look into some of the community-created Azure AD LAPS solutions out there, such as CloudLAPS Community Edition.

      Reply
  4. SIMON BURBERY says

    September 18, 2021 at 3:52 pm

    Hi Ruairidh, great post! I link to the Practical 365 RSS feed from my blog https://www.howdoiuseacomputer.com. There is no doubt any company can go ‘full cloud’, it should be thought of as a ‘journey’, ending in Azure AD joined workstations and infrastructure in the cloud. There may be some technology changes required, but with Azure Active Directory Domain Services we have fully usable GPO for servers, and with Intune the same for workstations (even if via registry entries or scripts). I feel many organisations are hesitant due to the seemingly overwhelming tasks of getting there, or perhaps the change in administration and fear of losing jobs? That is the main challenge to overcome; to get Admins on board and let them know they will still be needed after a full cloud migration, but they need to be keen to learn and do things in differnet ways.

    Cheers,
    Simon

    Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • Turn On MFA: Real-World Example of Fraud, Domain Stealing, and the Nearly Lost House Deposit
  • Changes in Microsoft 365 Apps Channels and Why You Should Care
  • A New Tool to Manage Exchange-related Attributes Without Exchange Server
  • Microsoft Launches Group Ownership Governance Policy
  • Making the Case for Identity Governance in Azure Active Directory

Copyright © 2022 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland