Azure AD joined devices: Comparing device identities in Active Directory and Azure AD

When Microsoft designed Azure Active Directory (Azure AD), they modernized the concept of device identity by introducing new device trust types of Azure AD joined, Azure AD registered, and hybrid Azure AD joined.

These device identities can be managed in Azure AD similar to user, group, and application identities; however, there are unique features and benefits of each trust type that determines which ones best meet the use cases present in your environment. All three scenarios can, and more than likely will, coexist in a single organization.

Figure 1: Device Identities in Azure AD

If you don’t yet have a solid understanding of these new trust types, then you might be hesitant to start adopting and investing in these newer technologies, including deciding when to convert from traditional AD-joined devices to Azure-AD-joined devices.

In this blog, we’ll work on untangling this web of new trust types for binding end-user devices to Azure AD, help clarify the benefits and differences between each, and examine how they compare to traditional on-premises domain joins.

What is hybrid Azure AD join?

Let’s begin with a very common use case, hybrid Azure AD joined. These devices are simply AD-joined Windows endpoints that have been synchronized from on-premises Active Directory to Azure AD. They rely on the traditional on-premises Active Directory Domain Services (AD DS) for Identity and Access management (IAM) and are also registered with Azure AD (see figure 2).

Figure 2: Hybrid Azure AD Device

Chances are if you already have Azure AD Connect (AADC) installed and are synchronizing your on-premises AD DS to Azure, you most likely already have hybrid Azure-AD-joined devices in your environment because they were auto-provisioned with the Windows Autojoin feature. For more information about hybrid provisioning options like Autojoin, you can view Microsoft’s documentation here.

Modernizing endpoint management

Since the devices are AD-joined, they can continue to be managed with traditional Group Policy and SCCM, along with any newer management tools like Microsoft Endpoint Manager (MEM) that you might have started deploying. Since they also have a device identity in Azure AD, they will also support some of the expanded Azure AD management and security features that we will touch on later.

Microsoft states that hybrid Azure AD join is an interim step on the road to Azure AD join. This may be true for some organizations but is not necessarily the case for everyone. The hybrid trust type exists for a couple of reasons. One is to support older operating systems like Windows 7 and Windows Server 2008, which cannot be Azure-AD-joined. Another is to support existing computers already managed by on-premises systems like GPOs or other methods and cannot currently be switched to a different management system.

Transitioning all endpoint management to the cloud is an expensive and complicated event that may take months or even years to complete, depending on the size of your organization’s infrastructure. So to state that adopting hybrid Azure-AD-joined devices is only an interim step prior to adopting an Azure-AD-only model is not totally accurate.

What is Azure AD registration?

Azure-AD-registered devices fulfill the needs for a growing use case amongst enterprises, which is to provide support for end-users who take advantage of “bring your own device” (BYOD) policies. These devices are neither AD-joined nor Azure-AD-joined but are simply registered with your Azure AD so that you can deploy and manage device settings and software (see figure 3). This device identity is primarily used for mobile device management, where devices are owned by either the organization or the user, with multiple sign-in options, allowing the organization to apply settings and policy via cloud-based services that focus on Mobile Device Management (MDM) and Mobile Application Management (MAM) such as Microsoft Intune or third-party unified device management tools like KACE.

Figure 3: Azure AD Registered Devices

It is also possible to use Azure AD registration for other devices such as BYOD computers, where you may encounter the term Workplace Join. This usually identifies a Windows 8.1 that is Azure-AD-registered, but you will also see this term when retrieving the Azure AD join status of any Windows machine using the command dsregcmd /status. A workplace join value of Yes indicates that the device is a registered BYOD.

Pro Tip:  This value should be NO for a domain-joined computer that’s also hybrid Azure-AD-joined. If the value is YES, a work or school account was added before the completion of the hybrid Azure AD join. In this case, the account is ignored when you’re using Windows 10 version 1607 or later.

Note that Azure AD registration for non-mobile devices is not very common, since companies usually prefer to use one of the other trust types for computers, requiring devices to either be Azure-AD-joined or hybrid Azure-AD-joined.

What is Azure AD join?

Azure-AD-joined devices help fulfill the needs of cloud-only environments, allowing organizations to manage corporate-owned devices by joining the device directly to their Azure AD and enabling logins with the users Azure AD account.

You can instruct end-users to perform an Azure AD join on an existing device by opening Start > Settings > Access work or school > Connect, at which point they can authenticate using their Azure AD credentials. Alternately, administrators can automate device joins via bulk enrollment with Intune, a third-party endpoint management tool or by using Windows Autopilot. You can also deploy fresh or reallocated laptops, ship them to an end-user somewhere in the world, and then have the user Azure AD join the device themselves using the initial Windows Out of Box Experience (OOBE) setup process.

Similar to Azure AD registered devices, Azure-AD-joined devices can be managed using Microsoft Intune, allowing organizations to provide users with access to the Intune Company Portal app, which helps employees securely manage access to their corporate apps, data, and resources.

Figure 4: Azure AD Joined Device

Comparisons: Active Directory vs. Azure Active Directory

Now that you understand what trust types are available with Azure Active Directory, we will attempt to reduce a bit of the confusion by examining the differences between the various infrastructure types, so you don’t have to spend the time compiling it yourself.

There are some core differences between traditional Active Directory and Azure AD to consider first before getting into the more detailed comparisons between each of the Azure AD device trust options, including Azure-AD-joined, Azure-AD-registered, and hybrid Azure-AD-joined.

Authentication

When a device is joined to a local Active Directory, an object is created in your on-premises AD DS, which is used for Identity and Access management (IAM) of your organization’s accounts, user devices and servers.  This configuration provides users with transparent access to resources using Kerberos Single Sign-On (SSO).

For a user to logon and authenticate to an AD joined device, that device needs to have network access to a domain controller. For remote users, this means they must utilize a VPN or similar means to authenticate and connect to the organization’s on-premises resources. Users can still logon locally if they have previously cached credentials but cannot access on-premises corporate resources without network access.

When a device is Azure-AD-joined, then the device only needs access to authenticate against Azure AD in the cloud instead of requiring access to a domain controller. You can issue Primary Refresh Tokens (PRT’s) to devices that are Azure-AD-joined or hybrid Azure-AD-joined to add device-specific claims and provide additional Seamless Single Sign-on (SSO) functionality to Azure AD resources.

Azure AD authentication has some challenges of its own that need to be considered, and you should ensure that it supports all your critical business applications. Kerberos/NTLM authentication and lightweight directory access protocol (LDAP) connections are not supported by Azure AD and will entail additional resources and possible server migrations to Azure. You can also consider Azure AD Domain Services (Azure AD DS), which provides managed domain services such as domain join, group policy, LDAP, and Kerberos/NTLM authentication without the need to deploy, manage, and patch domain controllers.

Management

Active-Directory-joined devices primarily rely on Group Policy for managing and deploying policies and settings to ensure that your user devices meet company and regulatory requirements. One of the challenges with this setup is that it can be more difficult to manage and secure devices for remote users. As cloud applications become more common for performing daily activities, remote users might connect to the VPN less frequently, causing them to miss out on receiving timely updates.

By registering or joining device identities to Azure AD, you can start managing security features using device-based Conditional Access policies. If you haven’t already started using Microsoft Endpoint Manager (MEM), Intune or third-party tools to assist with the management and monitoring of your traditional AD-joined devices, you will find that it has many features to assist with managing and provisioning Azure-AD-joined, hybrid Azure-AD-joined, and Azure-AD-registered devices, including mobile devices. You can determine which components of MEM are appropriate for your environment, including device management using Configuration Manager and Intune.

Note that transitioning from Group Policy to MEM requires detailed training, planning, testing, and implementation. There are also tenant-wide licensing requirements for device-based Conditional Access, while Microsoft Endpoint Manager requires either an Enterprise Mobility + Security E3 or E5 license.

Provisioning

You will find that it can be easier to hand off Azure-AD-joined devices to end-users due to the broader provisioning options available for Azure device identities, including options to auto-configure devices using Autopilot or through an Out of Box Experience (OOBE) and the ability to deploy software through the Company Portal.

Depending on your organization’s needs, you can choose to utilize self-service options that no longer require an administrator’s password, or you can provision devices in a more controlled manner that administrators exclusively manage.

Operating Systems

One of on-premises Active Directory’s primary strengths is the support of legacy operating systems, which many organizations continue to maintain while they plan how to transition business-critical apps and servers to cloud VMs joined to Azure Active Directory Domain Services or while they upgrade to Windows 11.

There will be increased motivation to transition on-premises managed apps and services as these legacy operating systems reach end-of-support deadlines with Microsoft. Once this occurs, the cloud will lead the way for determining which operating systems will be supported on-premises.

Comparisons: AD join vs. hybrid Azure AD join vs. Azure AD join

The chart below (see Table 1) provides a side-by-side comparison between devices that are traditional AD-joined, hybrid Azure-AD-joined, and Azure-AD-joined.

Keep in mind that as with any subscription-based SaaS platform, some of the premium services that replace on-premises built-in features will come with additional licensing requirements. These services will also include brand new technologies that administrators need to learn, implement, and drive adoption by their organizations.

Always factor in how costs will shift with the adoption of new device management tools that require premium licensing. In the comparison chart below, services that have a premium cost associated with them are linked to the applicable licensing information from Microsoft.

Table 1: Active Directory Join VS Hybrid Azure AD Join VS Azure AD Join

Comparisons: Azure AD registration vs. Azure AD join

The chart below (see Table 2) focuses on the two cloud-only options that are available if you are ready to fully move away from on-premises infrastructure, providing a side-by-side comparison between devices that are Azure-AD-joined and Azure-AD-registered.

Remember that although the primary use case of Azure AD registration is to support mobile devices, it can be used for any BYOD and there are important differences to consider between Azure AD join and Azure AD registration, including different management and provisioning options and different supported systems.

Services that have a premium cost associated with them are linked to the applicable licensing information from Microsoft.

Table 2: Azure AD Registration VS Azure AD Join

Conclusion

It is most likely that you will observe a mix of Azure-AD-joined, hybrid Azure-AD-joined, and Azure-AD-registered devices in a modern enterprise environment. You may even encounter conflicts, duplicate registrations, and other pesky anomalies to chase down. Therefore, understanding and learning all the options and associated components to support each join type and the associated technologies and components needed for each is important, and the decision to utilize any of them should be determined by your organization’s requirements, priorities, and technical and business limitations.

Patch, secure, and manage every endpoint

Automate patch and endpoint management – including third-party applications from the cloud.

Try KACE Cloud

That said, there are some key takeaways that can help you make the best decision about the potential paths your organization can take to move towards adopting cloud endpoint management and cloud device identity.

1. If you manage devices on-premises now, then you should start by implementing Azure AD services for hybrid Azure AD devices, whether you decide to remain in a long-term hybrid state or plan to fully move to cloud-only. Hybrid can be a long-term strategy if maintaining some IAM systems on-premises is still required for your organization. It can also be a stepping stone that gives you time to plan and implement the new management methods and technologies before making a final transition to cloud-only.
2. If you don’t have any on-premises infrastructure, then use Azure AD join to get the best protections and the most value for your corporate-owned machines and devices, including new features, more robust management, and enhanced provisioning practices.
3. If you prefer a BYOD model for laptops or if you want to manage mobile devices, then Azure AD Registration is the option for those machines and devices. Keep in mind that some organizations have used this for corporate-owned BYOD devices that are never joined to Azure AD, but this may not be the wisest long-term strategy for the management and security of corporate-owned devices.

Microsoft is making a big push to encourage movement to the cloud through changes in technologies that boost adoption and by providing incentives to reduce cost in all areas of IT. When the time comes to begin implementation, make sure to conduct a proof of concept to learn the basics and then start a pilot program before fully launching new services to the global population. There is nothing worse than a disruptive roll-out that potentially impacts end-user’s access and productivity.

View the full comparison chart below a quick reference guide, which includes additional links and compares all four join options side-by-side. Remember to review all the Microsoft documentation linked in this blog to start familiarizing yourself with all the new Azure AD features and services and start planning your transition from AD-joined to Azure-AD-joined.

Table 3: Comparing four Join options