This blog will discuss AADJ/Entra Joined vs. AADR/Entra Registered. It hopes this blog will provide you with all the information you need to understand this!
1. Information about AADJ/Entra Joined and AADR/Entra Registered
Let’s start with takin a look at Entra Registered Devices first!
Entra Registered / Azure AD Registered
When you want to start using Bring Your Own Device (BYOD) and skip the part of the corporate enrolled device, Azure Ad Registered Devices could be the way to go. With an AADR device, a user can still access data from the organization but from a personal device.
AADR devices are always logged in with a local user account. For example, on a Windows device, you log in with your personal Microsoft account. When you are logged in, and you want to start logging into the organizational resources like Teams, a Work/School account will be added. When registering your device into Azure AD/Entra it will be marked as a Personal Owned device
Please note: When you register your device into Azure Ad/Entra, you have the option/possibility to “Allow my organization to manage my device” after entering your credentials.
It’s a terrible option, I am glad it’s a little bit more improved in Windows 11 but why not give us the option to remove it/disable this weird window on non-managed devices.
If you have corporate-owned devices and you want to block this option, you can push a GPO. You will need to create this registry key: BlockAADWorkplaceJoin
HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin, “BlockAADWorkplaceJoin“=dword:00000001
Another option to block a Personal Device from enrolling itself into Intune is to configure Device Enrollment restrictions, as shown below.
When you blocked the possibility for Personal Devices to be enrolled into Intune (while doing so only allowing corporate devices to be enrolled), you are also making sure the device will be denied the Azure AD JOIN / Entra Join itself! Also trying to add a work or school account (AADR) on a Personal device to enroll in Intune will end up with the famous 80180014 error!
Please note: When your user is NOT a member of the MDM scope or does NOT have an Intune license, this option doesn’t stop the device from registering itself into Azure Ad
Entra Joined / Azure Ad Joined
AADJ/Entra Joined devices are corporate-owned and, most of the time, managed devices. To authenticate, you must enter a corporate-owned identity (Azure Ad Account like rudy@call4cloud.nl). When you want to go full cloud and not HAADJ, AADJ is the way to go. With AADJ, you can ensure all your users can access corporate cloud and on-premise resources and benefit from SSO. Like with AADR, you can use an MDM like Intune to further manage the devices. But with the use of AADJ, you can also make use of some great features like Windows Autopilot.
To resume:
When you think about AADR: Azure AD knows about the device, but it DOESN’T REQUIRE a corporate-owned identity to log into the device
When thinking about AADJ: Azure Ad knows about the device, and you will be REQUIRED to log in with a corporate-owned identity
Let’s take a look at how it looks in Azure whether a device is Azure Ad Joined or Registered
2. Intune and disable Registering a Device
As mentioned earlier, registering or joining a device to Azure AD/ Entra and Intune are separate things, but they often go together like a horse and a carriage!
When you use Azure AD and enable/configure Intune in your tenant, this option will be greyed out.
Enrolling a device into Microsoft Intune (MDM) requires registration! Of course, when you only want to allow Azure Ad joined devices, a good solution to prevent personal devices from registering themselves in Azure would be nice.
But if you have configured Conditional Access and your MDM and MAM scopes correctly, personal BYOD devices can still register themselves into Azure, but they can’t access your Company data!
But just like with the Marvel “What If” series, what if you accidentally turned on Intune and you want to ditch it and only allow Azure Ad joined devices (It’s a weird thought… but… I have heard the question)
The first thing that can come to mind is to change the MDM and MAM scope to none.
But after some time waiting, the option I mentioned earlier is still greyed out. Some articles on the Internet tell you that you could disable it by using PowerShell by running the Set-AzureADServicePrincipal command.
But like shown below… that ain’t working
get-azureadserviceprincipal -filter “displayname eq ‘microsoft Intune'” | set-azureadserviceprincipal -accountenabled $false
Even Microsoft is telling us you can’t change the MDM authority to unknown
Maybe removing it? (PLEASE DON’T !!!!!!) but I needed to check it out in one of my test tenants for my own!
get-azureadserviceprincipal -filter “displayname eq ‘microsoft Intune'” | remove-azureadserviceprincipal
Within a minute or 2, my whole Intune went broken…and I could change the “users may register their devices with Azure Ad” back to none.
Removing the Intune service Principal will break Intune. When I tried to open Intune, I immediately was prompted with multiple errors, and this one! “You haven’t enabled device management yet“
When I “click here” it showed me this nice error: 403 No Access Microsoft_Intune_Enrollment
After some reading, I found out (2) Sandy Zeng | LinkedIn also has seen this error while deleting the Intune Service Principal. So I tried the same thing, to recreate it…hopefully, Microsoft automated the recovery of the Intune Service Principal by now?
Unfortunately, this isn’t the case. Removing the principal allows you to change the greyed-out setting, but it will break Intune completely!
UPDATE 16-08-2021
I guess it’s all in the date… Friday the 13th, I broke Intune… but after recreating the service principal and waiting 24 hours, Intune was working again!
3. Compliance and Conditional Access
Now that we have learned we can enroll Entra Joined and Entra Registered devices into Intune, we could also configure a conditional access rule to require a compliant device. Because we know now that when AADR and AADJ devices are enrolled into Intune, you can ensure both are compliant!
Of course, you must ensure that you have configured the compliance policies before you enable the conditional access rule to require a compliant device.
When configuring your compliance policies, you could configure a device-based conditional access rule to require a compliant device. If the device isn’t compliant, access will be blocked. So again, to resume, when a device is not Intune enrolled, there is absolutely no way to require a compliant device.
But there is more information to tell. When configuring device-based conditional access rules, something else is needed. That something needs to contain information about the device itself. That something is the Primary Refresh Token (PRT).
So, what’s inside the PRT that ensures you can set up device-based conditional access rules? The PRT contains the Device ID claim, which determines the device on which the PRT was issued to the user.
Registering or joining devices to Azure AD will give your users a PRT and a pleasant thing called Seamless Sign-on (SSO) to cloud resources.
Read more on my blog about SSO
A quick summary: A PRT is necessary if we want to deploy device-based conditional access rules. How do we get it?
Entra Registered / Azure Ad Registered
Web Account Manager (WAM): WAM is the default token broker on Windows 10 devices. WAM also provides a plugin framework that identity providers can build on and enable SSO to their applications relying on that identity provider.
A PRT is issued when a user adds a secondary work account to their Windows 10 device. Users can add an account to Windows 10 in two different ways
*Adding an account via the Use this account everywhere on this device prompt after signing in to an app (for example, Outlook)
*Adding an account from Settings > Accounts > Access Work or School > Connect
On Azure AD registered devices, the Azure AD WAM plugin is the primary authority for the PRT because Windows logon is not happening with an Azure AD account but with a personal account.
Entra Joined / Azure Ad Joined
Cloud Authentication Provider (CloudAP): CloudAP is the modern authentication provider for Windows sign-in, that verifies users logging into a Windows 10 device. CloudAP provides a plugin framework that identity providers can build on to enable authentication to Windows using that identity provider’s credentials.
A PRT is issued during Windows logon when a user signs in with their organization credentials. A PRT is issued with all Windows 10 supported credentials, for example, password and Windows Hello for Business. In this scenario, Azure AD CloudAP plugin is the primary authority for the PRT.
4. Comparing the Azure PRT on AADR and AADJ devices
Now, let’s take a look at how we can determine if we have a PRT. We can check out if the user has a working PRT by using dsregcmd /status
First, we need to examine an AADJ device. You will notice that it has the AzureAdPrt set to YES.
When logging in for the first time, the Primary Refresh Token (PRT) is issued by signing requests using the device key. This device key is secured by the TPM preventing any malicious access.
But what about an AADR device and using dsregcmd /status to determine if the user has a PRT?
You will notice the AzureAdPrt is been set to: NO
This will happen when the Cloud AP Plugin couldn’t successfully authenticate your identity against Azure AD. As we know by now, when you log in to your AADR device, you are doing this by NOT using a corporate cloud identity so using the CloudAP plugin is not possible from an AADR device.
When a user opens a Microsoft 365 App, it will use the Web Account Manager (WAM) for authentication and the single-sign in. The Azure AD WAM plugin uses the PRT to request refresh and access tokens for applications that rely on WAM for token requests. These access tokens are encrypted by using the Data Protection API (DPAPI)
To finish this part, let’s take a look at this small PRT vs WAM comparison
AADJ –> PRT –> Protected by TPM –> Safe
AADR –> WAM –> Protect by DPAPI –>Less Safe
5. Comparing the Intune MGT Reports
Have you ever tried to create an MDM report from an AADR device? Usually you can find it in the account settings by pressing on your account and pressing on the info button. But on an AADR device, this button isn’t there.
So how are we going to get our MDM reports? Like always with the use of the fantastic MDMdiagnosticstool by using these parameters: -area deviceenrollment; deviceprovisioning -zip c:\temp\report.zip
Do you know the main difference between those 2 reports? It’s MDMFull vs MDMDeviceWithAAD. Take a look at the picture below. One is from an AADJ device, and the other is from an AADR device. Guess which one belongs to which type of enrollment!
MDMFull –> Entra Registered with MDM
MDMDeviceWithAAD –> Entra Joined with MDM
Conclusions
You can enroll your (existing) Azure Ad registered devices into Intune/MDM to ensure they are managed. That’s cool… but when I need to choose, I prefer that all Windows 10 devices be corporately enrolled and managed with Intune. There is no question about that; I am 1000% sure. No personal BYOD-enrolled devices for me!
If you want to know what features work when your device is Entra registered and Intune enrolled I advise you to read this blog:
Excellent write-up. This may be more of a SCCM/MECM and Intune co-management question, but what about blocking the device enrollment prompt for organizations that have enabled Hybrid Azure AD Join? The Intune enrollment would be dictated by SCCM/MECM so you wouldn’t necessarily want to allow the user to enroll with that prompt. Would the registry key be applicable in those circumstances (assuming you would want to remove it when the time came for Intune to manage the device through co-management)?
Hi,
You could take a look at the microsoft their docs, in it you will notice this line”block your users from adding additional work accounts to your corporate domain joined, Azure AD joined, or hybrid Azure AD joined Windows 10 devices.
https://docs.microsoft.com/en-us/azure/active-directory/devices/faq#q-how-can-i-block-users-from-adding-additional-work-accounts-azure-ad-registered-on-my-corporate-windows-10-devices
This article is great. Many thanks for your work.
A few days ago I tested every single scenario. I found it quite difficult to keep an overview over all these dependencies.
Hi Rudy, in your test.
Windows Hello for Business work for AADR and MDM Enrolled?
Thanks.
Mmm need to take a look at my screenshots I took, as I didn’t mentioned it but looking at the ms docs, it should work 🙂
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-faq#how-does-windows-hello-for-business-work-with-azure-ad-registered-devices
Hello,
thanks for this blog.
Is it possible to have a domain-joined and AADR device?
The scenario here:
The device is domain joined (not our domain), but should be managed by Intune (our tenant)?
https://learn.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-plan#handling-devices-with-azure-ad-registered-state
But azure ad registered is something else than also managed by Intune
The scenario you are telling about, is not the way you want it to happen 🙂 . If you want to enroll those domain joined devices into Intune your best option is to use azure ad connect and enroll them into azure ad and add a gpo to enroll them into Intune
Hello,
thank you very much for such a quick response.
Our company had an acquisition of another company which is having an Active Directory without MECM and without Intune.
Our devices are HAADJ (enrolled by the GPO) and we have AAD Connect and some Azure Joined (Autopilot).
Their devices are domain joined only but are not in our domain.
We are exploring a possibility where their devices remain in their domain, but managed by our Intune (perhaps Azure registered).
We would like to avoid the Hybrid AADJ scenario if possible.
They should remain in their domain to access their on-prem ressources, but managed by our Intune (different tenant). We want to manage WUfB, Driver Updates, M365 Apps, Security etc.
Is there a possibility for this scenario to work and if so, how?
HI,
just to be clear, to have devices registered as corporate what info do i need to gather from them? I need to gather the Hardware hash but not setup the autopilot stuff?
While it all works, still doesn’t help the fact of having loads of personal devices appear as ad registered in Azure AD. Is a nightmare trying to explain that they can’t actually do anything to higher up management etc
What a most excellent blog, finally resolving the question of the pre-requisites required for enrolling devices automatically, AADJ or AADR etc… something which is impossible to find a concrete explanation for on the Microsoft Documentation. This is actually very useful for some of the certifications for ex. MD-102, there is always the confusion that a device with AADR will not be automatically enrolled etc… Thanks a log
thanks a ton for this article. Helped me a lot.
We currently have the situation that a lot of Windows IoT Devices for MTR (10/11 mixed) are enrolled in Intune but only AADR and not AADJ. Do you know of a way to make them to AADJ? dcregcmd /join doesnt work with local Admin (strange error message regarding “No domain controller available or the domain does not exist : 0x8007054b). The only thing that works is to remove them from Intune, disconnect Work Account and start the Enrollemnt by Hand again but with Entra ID Join this time.
I’m facing issue registering my devices, got hit with 80180014 when I just want the device to be registered (Not joined)
Tried alternatives like logging into Microsoft Office Apps but my work account still didn’t show up on the Accounts used by other Apps
…
I believe accounts need to be added here (Entra Registered) for Conditional Access that filters by device displayname to work.