Azure AD Device States, revisitedAlex Fields
I have an older article on Azure AD Device States already, but I wanted to quickly return to this topic. I have a few in the audience who are still confused about this.
Azure AD Registered – A machine that shows up as Azure AD registered represents a device that exists and has been registered against Azure AD. This association gives you no meaningful controls over the device. You can disable or delete the object, but it doesn’t prevent that device from re-registering itself. Any device type can be Azure AD registered–Mac, Windows, iOS or Android. On Windows, a user signs into this machine using a personal or local account (not a “Work/School” account).
Note: not every device that accesses cloud resources ends up Azure AD registered. However, when you enroll into MDM or MAM with Intune, registration is mandatory.
Azure AD Joined – This device state only applies to Windows. It is the exact same relationship as Azure AD Registered (again, it gives you little to no control), with one critical difference: the local device state changes so that users can login to the workstation using their Azure AD credentials. That’s it.
Hybrid Azure AD Joined – Again, only applies to Windows. Nothing more than a combination of Domain-joined (to a traditional AD) and Azure AD Registered. Proper hybrid join involves using Azure AD Connect and configuring an SCP, along with some group policy to enforce device registration. Your control in this model still comes primarily from Group Policy and other on-prem tools.
Intune / MDM enrolled – This is not a device state like Azure AD Registered, Joined or Hybrid Joined. Instead, enrollment into MDM is what actually gives you compliance and control capabilities. Not that other stuff. This. It applies to any supported device type (Mac, Windows, iOS and Android). You do not have be Azure AD Joined or Hybrid Joined to take advantage of MDM–any BYOD user can go download the Company Portal app and get themselves enrolled. You can also configure auto-enrollment with Azure AD Join or Hybrid Azure AD Join.
Is one device state better than another?
One of these device states (Registered, Joined, Hybrid Joined) does not have any “higher” or “better” status than any other from Intune’s perspective. Once enrolled, all the device types can be subject to the same config profiles, the same security baselines, the same compliance and so forth. However, some policies in Intune will allow you to distinguish between corporate and personal devices, targeting different settings depending on context.
If you are troubleshooting a device, and you need to find the local device state of any given Windows 10 client, open a command prompt and run: dsregcmd /status
If you want a full rundown of how to interpret the output of this command, check out this article.
When to use what
The main reasons you would choose one device state over another is not related to the management tool you intend to use (e.g. Intune) but rather how that device is used and what it needs to access. For example:
Corporate-owned devices that also need reliable and frequent access to on-prem resources: Choose Hybrid Azure AD Joined. A user can sign-into the device using corporate credentials and/or Windows Hello for Business. Supports Seamless SSO to Azure AD apps, when properly configured via Azure AD Connect and corresponding GPO.
Corporate-owned devices that rarely if ever need access to on-premises resources, or are mostly “on the road” or “in the cloud” etc.: Better to pick Azure AD Joined (not Hybrid). The user can sign into device with corporate credentials and/or Windows Hello for Business. Supports SSO natively without additional configuration.
Personal device that needs access to company resources – just Azure AD Registered, and, if your company requires it for security and compliance, enrollment into MDM using the Company Portal app. The user could have a completely unique login (personal or local account), not tied to the company. The company credentials and MFA may be required to complete enrollment and gain access to resources, however. Notice: that means we can provide the same security policies and controls against BYOD devices–a big departure from traditional Active Directory.
Whether a device is BYOD or Corporate-owned, corporate data can be protected on devices using MAM or Application Protection policies, also known as Windows Information Protection (WIP). If you go down either path, MDM and MAM would both require the device to be Azure AD Registered first in order to apply the policies correctly.
Okay, hopefully that clears it up. I know–they don’t make this confusing at all, right?