Azure AD Device States, revisited
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?
Comments (12)
Hi, Thanks for wonderful article,
Please confirm how Hybrid Azure AD Joined devices status will look like using dsregcmd /status
any screen shot will help
Also what does “EnterpiseJoined” parameter indicate
Follow the link–all output of that command is described in the link I provided.
Hi Alex, quick question I’ve not been able to find an answer to: Does selecting “None” on the “Users may join devices to Azure AD” setting prevent Windows systems from becoming Registered? Per a contract, we’re required to have MFA trigger on all O365 logins and Registered PCs seem to be bypassing this (which appears to be by design of SSO). I can’t seem to get my users to follow the training I’ve given to prevent their PCs becoming Registered.
You cannot prevent a machine from becoming registered, if you want it to have certain access it will at least be registered. Also joining Azure AD is just registration where the device itself can be then be signed into using the Microsoft 365 credentials. You can increase frequency of MFA if you like, using Conditional access, but it should not be necessary. Let’s say for example that you require MFA on unmanaged devices. For managed devices, you already have two factors (password = something you know, device = something you have). You can however have a Conditional access policy that requires MFA for access to any cloud resource, no matter what app is being used, and whether the device is managed or not. You can also control the sign-in frequency right in the policy, if your requirements call for it.
From my experience device can become Azure AD Registered when you activate Office 365 with Azure AD user. Also, for Seamless SSO (SharePoint Online, Skype, Outlook, most probably OneDrive also, but haven’t set it up) Azure AD Connect is enough and it works with Azure AD Registered (or not at all) Windows machines.
Alex, I think that you’ve been a bit harsh when saying that AAD registered devices status give you no meaningful control over the device. We can apply conditional access policy to registered devices. While that doesn’t give us configuration control over the device is does give us access control and that is pretty powerful stuff. https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-azure-ad-register
“Scenarios
A user in your organization wants to access tools for email, reporting time-off, and benefits enrollment from their home PC. Your organization has these tools behind a Conditional Access policy that requires access from an Intune compliant device. The user adds their organization account and registers their home PC with Azure AD and the required Intune policies are enforced giving the user access to their resources.
Another user wants to access their organizational email on their personal Android phone that has been rooted. Your company requires a compliant device and has created an Intune compliance policy to block any rooted devices. The employee is stopped from accessing organizational resources on this device.”
Combine this with things like blocking legacy auth and require MFA, while we can’t push modern apps, we can effectively enforce their use.
Then finally, if we have an Azure AD P1 license for our users then we can also apply WIP policies. Those Azure AP P1 licenses are becoming mandatory equipment.
Your quote there proves my point actually. The device registration is not an access control I can call upon. The registration has no bearing on whether a conditional access rule is applied or not. If I have a conditional access rule that requires MFA on the web for instance, I could use a machine that is not registered with Azure AD, and it would still be subject to the CA policy. And again in the scenario you are describing from that document, the Azure AD registration is not the magic that gives you leverage over the device, it is being enrolled into Intune. So it is possible to have a device registered only, and enrolled into Intune. As well, it is possible to have a device joined or hybrid joined, and enrolled into Intune. But the Conditional access control that makes the magic is based on Intune compliance, not registration or join status. So the power is all with Intune and Azure AD Premium/Conditional Access. NOT with registration or join. That is the point I was making–device registration, on its own, does nothing for me. If I need to have leverage over the device, I need to get it enrolled (which I can do with Conditional access). If the device is compelled to enroll and become compliant, it is mandatory that it be at least registered–but the registration again is not the leverage on its own–just a pre-req.
One more note, I believe that WIP is actually supported natively with M365 Business, I am not sure we even need the P1 license to get access to it.
I was looking for a wip reference related to m365b but wasn’t able to find one
They don’t call it by that name in the service description, but: “Intune Mobile Application Management (MAM) for Office apps and LOB apps”–I guess that’s what I was reading as WIP (as well as MAM for mobile). For instance, when you run through the setup wizard when you get a new subscription, it has option to setup the Windows app management policies, so, always assumed it was included. But you’re right–I don’t see them explicitly name WIP.
HI Alex – In this article, you stay Hybrid joined devices enjoy SSO to Azure apps once the two IE GPO settings and the SCP are created. You also say that Azure Joined devices get SSO without further configuration. I think Windows 10 machines get SSO without further configuration regardless of Azure Joined only or Hybrid Azure Joined. In both configurations, the device gets a PRT during login (Hybrid machines also get the computer and user TGT from AD). I think the GPO settings for IE are only necessary for downlevel devices (win7 win8 etc.) This is something that I have been struggling with for the past few months in test environments so I’m not completely sure that I’m 100% correct. I also think devices that are merely Azure registered also get SSO to Azure apps without further configuration, although the PRT does not show up in the DSREGCMD /Status command, and it is not present until the user connects to the first cloud app. What are your thoughts on this? Native SSO without using AD Connect’s “Seamless SSO” feature isn’t very well documented. -Joe
I believe that it is as you have said. I always enable seamless SSO and put the GPO in place anyway, but we really don’t have that many “downlevel” devices out there anymore. Still run across some, but is dwindling. But, I think you’re right.