Device Management Methods with Active Directory & Azure AD

Last Modified: 07/06/2022 

Intro

We are all familiar with Active Directory and with the introduction of Office365 we should now be familiar with Azure Active Directory. However, both of these systems have a few differences when it comes to device management and hopefully this article will help explain the different methods that can be used when it comes to management of devices.

When it comes to Windows 10/11 device management, there are a number of options to choose from when considering either Active Directory or Azure Active Directory. Which method you choose to use, will depend on a number of factors, including:

• Who is Managing the Device?
• Who owns the device?
• Where is authentication of the Device taking place?
• What’s the desired user experience?
• What existing systems do we have in place already?

We have 2 systems to play with when it comes to managing devices and the associated device identity. We have Active Directory and Azure Active Directory, these 2 options however give us 4 main methods to choose from. These are: 

• Domain Joined Devices via Active Directory
• Hybrid Joined Devices via Active Directory and Azure Active Directory
• Azure AD Joined Devices
• Azure AD Registered Devices

Each of these options have their merit and usage will be dependant on what you want to achieve. Lets look at these 4 methods in a bit more detail. 

Domain Joined

This is the traditional method of managing devices that are configured and connected to an on-premise Active Directory. Devices using this method will more than likely be corporate owned and will be managed and configured using Group Policy. Authentication to the device is via a corporate issue identity (located in AD) and authentication happens against the Active Directory. Applications located on the network or installed locally will be able to leverage AD as an identity provider for authentication. This enables the use of protocols like Kerberos and NTLM. 

This model has minimal support for cloud based applications and is very much suited to an on-premises environment.

Azure AD Join

This method is at the opposite end of the spectrum. It looks to use Azure Active Directory only and is fully cloud based. It is still ideal for corporate owned devices. In this method, device authentication occurs only through Azure AD and uses identities that are also located in Azure AD. Management of the device is done via an MDM solution like Intune. This method allows the seamless sign-on to cloud based applications from the device and allows you to leverage protocols like Oauth and SAML.

This method is directed at cloud-only environments, so for small businesses and start-ups this is ideal to gain a foothold in the management of devices without having to deploy on-premises infrastructure.

Hybrid Azure AD Joined

This method is a hybrid between the two previous methods we have gone through. This is a hybrid between Active Directory and Azure Active Directory to give a blend of each. Similar to the last 2 methods, it is directed at corporate owned devices that are managed by the business. Authentication to the device is done via a corporate issued identity that is located on both the Active Directory and Azure Active Directory. Authentication can happen against either of these systems. 

Devices can be managed with Group Policy, however you could also use an MDM provider. It is recommended to only use one of these for management as one system will generally overall the other. 

This method also gives local apps the ability to leverage the AD for Kerberos and NTLM, as well as giving cloud applications the ability to use SAML and Oauth. Giving it the best of both worlds. 

This method is more suited to businesses that want to leverage their existing deployment of Active Directory. Its important to note that it can be difficult for a business to move toward an Azure AD only model as a number of on-premises applications will still rely on AD, therefore this model is suited to give support to existing apps, but also allows you to leverage the newer apps and technology of Microsoft.

Azure AD Registered Devices 

This method is a bit of a black sheep, as its different from the other 3 methods. This method focuses on personal devices that will be accessing corporate applications and data. The device will have a pre-existing local account or Microsoft account that is used for authentication to the device. However, authentication to corporate resources uses an identity that is in Azure Active Directory and would be provided by the business. Management of this device can be accomplished with an MDM tool, however given that the user will likely own this device they might be apprehensive on doing so.

This method is ideal for personally owned laptops that need to be corporate enabled. The user owns and manages the device, however registration to Azure AD allows access to corporate based resources (That would otherwise be inaccessible until registration is complete). The user will also need to manage two accounts, their own account for accessing the device and their corporate account for accessing business applications.

Of course, in this method there is going to be a less suitable user experience (As the user will have two accounts). But also, there is less control that the IT team have with these devices making it a big security debate over if personal devices should be allowed to access corporate applications. 

Summary

Of course, this only scratches the surface with the functionality of Active Directory and Azure Active Directory, but will hopefully serve as a initial understanding to each of the methods and what to lookout for. I have also summarised this in a table to help illustrate this further. 

Thanks for reading! As always, feel free to drop a comment below!