Last Updated on March 23, 2023 by rudyooms

After answering (yet again) a question on the Technet forum. I noticed I did not have a blog about the information he needed! So I needed to create a blog about this.

This blog will be about AADJ vs AADR and the MDM vs MAM. It will hopefully show you all the information to get a good understanding of this!

As always I am going to divide this blog into multiple parts

1. Information about AADJ and AADR
2. Configuring MDM and MAM User Scope
3. Corporate vs Personal devices
4. Intune and Disable Registering a device
5. Compliance And Conditional Access
6. Comparing the Azure PRT on AADR and AADJ devices
7. Comparing the Intune reports on AADR and AADJ devices
8. How to Enroll an existing AADR device into MDM
9. What’s working and What’s not with AADR?
10. Comparing DSRegCMD on AADR and AADJ devices
11. Conclusions

1. Information about AADJ and AADR

1. Azure AD Registration

When you want to start making use of 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 could still access the data from the organization but from a personal device.

AADR devices are always logged in with a local user account. As an example: On a Windows device you would log in with your personal Microsoft account. When you are logged in and you want to start logging into the organizational resources like Teams, an Work/School account will be added. When registering your device into Azure Ad it will be marked as a Personal Owned device

Please note: When you register your device into Azure Ad, 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 to enroll itself into Intune would be 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 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 to register itself into Azure Ad

2. Azure Ad Joined

AADJ devices are corporate-owned and most of the time managed devices. You will need to enter a corporate-owned identity (Azure Ad Account like rudy@call4cloud.nl) to authenticate. When you want to go full cloud and not HAADJ, AADJ is the way to go. With AADJ you can make sure all of 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 autopilot

To resume:

When you think about AADR: Azure AD knows about the device but it DOESN’T REQUIRE a corporate-owned identity to login 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. Configuring MDM and MAM User Scope

After reading the first part we have learned that with AADJ and AADR we have the possibility to enroll/register our devices into Azure Ad and also “could” have some management over the device. But like always, there are some prerequisites when you want to use Intune.

Prerequisite for Windows 10 Intune Enrollment  -AADJ and AADR

• Azure active directory & Intune subscription, setup, and configuration needs to be completed
• Admin User needs to be created and appropriate License/access needs to be assigned for enrollment
• Configure MDM User scope for Auto-enrollment

As you have noticed in the prerequisites to enroll a device into Intune, the MDM scope has to be configured.

First some background information about these scopes

When talking to customers, I sometimes have the feeling there is some confusion about the MDM and MAM user scope. A lot of people think that these scopes also apply to IOS and Android devices but that’s definitely NOT the case!

Please note: These scopes only apply to Windows Devices! NOT your IOS or Android devices.

So if we need to manage our AADJ or AADR devices and need to get them enrolled into Intune we need to configure these scopes!

MDM users scope

When you configure the MDM (Mobile Device Management) user scope you are making sure Windows AUTOMATIC Enrollment is enabled for device management with Microsoft Intune. There are 3 options to configure this MDM user scope

None – MDM automatic enrollment disabled

Some – Select the Groups that can automatically enroll their Windows devices

All – All users can automatically enroll their Windows devices

When the MDM scope is configured, AADJ or AADR devices will automatically enroll into MDM management with Microsoft Intune.

Please note: When you configure this scope to “none” it doesn’t mean you can’t enroll a device into Intune, you still can enroll the corporate device in Intune manually.

So putting all the pieces together, the MDM user scope can be used to automatically enroll devices into MDM enrollment with Microsoft Intune. You can define the scope to only a select group of users. This possibility will give you the option to perform phased Intune roll-outs.

MAM users scope

First some background information about MAM (Mobile Application Management). Intune MAM refers to a full set of features to help you to configure, secure, push/publish, monitor, and update mobile apps for your users.

When you configure the MAM Scope, users in this scope who add a Work or School Account to the device aren’t getting enrolled in Intune but will only be registered in Azure AD.

MAM allows you to manage and protects the corporate data within an application instead of managing the whole device. So when you configured MAM without (Intune Device) enrollment (MAM-WE), a corporate application that contains sensitive data can be managed on almost any device including personal BYOD devices.

As an example: If you have configured Windows Information Protection (WIP), only WIP without Enrollment (MAM policy) is applied. To enable WIP without (Intune device) enrollment for Windows 10 devices, the MAM Discovery URL must be configured. If you don’t configure it, users can’t enroll into MAM management.

To be clear MAM Scope = WIP for Windows 10!

So are we going to choose MDM or MAM or maybe both? When making a choice you will need to remind this important note below:

So let’s transform the above text into a nice overview!

I am also mentioning if the device is corporate or not, here is why!

So, let’s take a closer look at the difference between corporate and personal devices

3. Corporate vs Personal

Did you notice the sentence “For Corporate devices in the picture from the last part?

Let me explain what would it take to make a device corporate. The device needs to be:

• Enrolled with a Device Enrollment Manager
• Enrolled with Windows Autopilot
• The device is registered with Windows Autopilot but isn’t an MDM enrollment only option from Windows Setting
• Device IMEI number is listed in the Device Enrollment -> Corporate Device Identifiers
• Enrolled with a provisioning package
• The device enrolls through GPO or automatic enrollment from Configuration Manager for co-management.

So even when a device has performed an Azure Ad Join and “marked” as corporate it doesn’t mean it could enroll into Intune

Please Note: Only devices that were enrolled with a GPO, will show up as Corporate. If a user performs the enrolment manually at the device then it will be marked as a Personal Device

And do you know what’s funny? When changing an AADR personal enrolled device to corporate, Intune would convert that device into an Autopilot device if you configured an Autopilot profile to “convert all targeted devices to autopilot “

For “Personal Devices“. So what makes a device personal? The user adds a work or school account and the device becomes a workplace-joined device

So to be clear: You can add a user to both groups who are in the MDM AND MAM scope but when doing so a user with a personal BYOD will automatically be pushed to MAM and the device will NOT be managed with Intune and will never ever be compliant! (Maybe a good thing?)

I almost forgot to mention that you could also change the device category ourselves after enrollment

4. Intune and disable Registering a Device

As mentioned earlier, registering or joining a device to Azure Ad and Intune are separate things! but often they go together like a horse and a carriage!

When you are using Azure Ad and you enabled/configured 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 configured your MDM and MAM scopes correctly, personal BYOD devices would still be able to 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. There are some articles on the Internet telling you, 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

And 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?

But unfortunately, this isn’t the case… Removing the principal gives you the option 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!

5. Compliance and Conditional Access

Now we have learned we can enrol an AADJ device AND an AADR device into Intune, maybe we also could configure a conditional access rule to require a compliant device? Because we know now when AADR and AADJ devices are enrolled into Intune you can make sure both of them need to be compliant!

Of course, you will need to make sure before you enable the conditional access rule to require a compliant device you have configured the compliance policies

When you have configured your compliance policies you could configure a device-based conditional access rule to require a compliant device and if it 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. There is something else needed when configuring device-based conditional access rules. There needs to be “something” that contains information about the device itself. That something is the Primary Refresh Token (PRT).

So what’s inside the PRT that will make sure you can set up device-based conditional access rules? The PRT contains the Device ID claim. This claim determines the device the PRT was issued to the user on.

When you register or join devices to Azure AD, it will give your users a PRT and also a nice 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?

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.

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.

6. 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 take a look at an AADJ device. When looking at an AADJ device, will notice 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

7. Comparing the Intune MGT Reports on AADR and AADJ devices

Did you ever try to create an MDM report from an AADR device? Normally 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 what the main difference is between those 2 reports? It’s MDMFull vs MDMDeviceWithAAD. Take a look at this picture below. One is from an AADJ device and the other one is from an AADR device, guess which one belongs to which type of enrollment!

MDMFull –> Azure Ad Registered with MDM

MDMDeviceWithAAD –> Azure Ad Joined with MDM

8. How to enroll an existing device into MDM

Option 1a:

Once the MAM user scope setting is changed to NONE and the MDM user scope is still configured to ALL, you can start to un-enrol/disconnect the Windows device from work /school.

When it’s disconnected, you could start adding back the account. This enrollment will enroll the device to Intune so you can require a compliant device with Conditional Access

Option 1b:

If you don’t want to explain to your end-users how to use the settings menu to get to the “access work or school” option you can simply just send them an email with a link in it :

ms-device-enrollment:?mode=mdm

This will make sure the end-users immediately will get the option to start setting up their work account

Option 2:

You could also use the Company Portal app to enroll an existing Windows device into Intune. If you want to read how to do this, please visit this Microsoft blog.

Enroll Windows 10 device in Intune | Microsoft Docs

The results after reconfiguring a work/school account

After you have removed and added your work or school account, within a few seconds the OMA-DM client will start “doing stuff”

Some stuff like installing the Microsoft Intune Management Extension. This application is needed to make sure all other stuff is installed and configured

If you are interested in how this process works, please read this blog where I am explaining how it works

9. What’s working and What’s not with AADR and MDM Enrolled?

Now we have seen we can enrol a personal BYOD device into Intune, I am going to show you what can be managed and whatnot with your Azure Ad Registered Devices and Intune!

Please note: Your device needs to be enrolled into Intune and needs to have the corresponding Intune Management Extension installed!

I am going to show some examples of what is working and what’s not. If you have the feeling I forgot something worth mentioning, please send me a DM

1. Conditional access and require a compliant device
2. Windows Update for Business (WUfB)
3. Windows Expedite/Feature Updates
4. Device Configuration profiles
5. Endpoint Security
6. Bitlocker Recovery Key
7. Bitlocker Recovery Key rotation
8. PowerShell scripts
9. Win32Apps
10. Proactive remediations
11. Company Portal Downloading Apps
12. Windows Hello
13. Changing the Primary user

1. Conditional access and requiring a compliant device:

Yes it works

2. WUfB

Yes it works

3. Windows Expedited/ Fearture updates:

Nope

Expedited updates, Feature Update deployment, and Drivers & Firmware deployments all require an AAD joined device and don’t work with AADR

4. Device Configuration Policies/Settings Catalog

Yes it works

As shown below, I am using Applocker to protect the device. On my AADR device, Applocker just got activated!

5. Endpoint Security:

Yes it works

When you want to add some security to your AADR devices, you are good to go! As shown below I can make sure the Endpoint Security profiles are deployed to my AADR devices!

6. Bitlocker Recovery Key in Intune:

Yes it works

7. Bitlocker Recovery Key Rotation:

Nope

The possibility to perform a “Bitlocker Key Rotation” is greyed out just as the options you have to click on “Locate Device” or “Rename Device”

8. PowerShell Scripts:

Yes it works

9. Win32Apps:

Yes it works

10. Proactive Remediations:

Yes it works (even when Microsoft tells us otherwise?)

You can find the proactive remediations script in the c:\windows\imecache\healthscripts folder.

If you are interested in more proactive remediations, please visit my blog about it!

Proactive Remediations – Call4Cloud

11. Company Portal Downloading apps

Yes it works

I am getting this question quite often, so I need to show you that it does work.

12. Windows Hello

Yes it works

When requiring Windows Hello to be configured on your devices, your AADR device will also prompt you to “set up a PIN”

13. Changing the Primary User

Nope… not possible

As shown below, when your device is AADR it’s not possible to change the Primary user! The option to change the primary user will be greyed out!

10. Comparing the DSRegCMD Results

1. AADJ (MDM Enrollment)

You will notice the Join Type: Azure AD Joined and MDM set to Microsoft Intune

Intune/Azure Ad

Now let’s check the DSREGCMD /Status from an AADJ device first.

Did you notice the Thumbprint? This one is very important I have written a blog about this thumbprint/certificate some while ago. Please read it

2. AADR with MDM enrollment

After enrolling my device and rebooting I ended up with a weird situation… We are making sure that every user who is a member of the local administrator’s group will be removed except the ones we are excluding. And you can guess what happened when I was enrolling my device as a local user with administrator permissions!…

Please note, when the user is not in any group logging in with that user is going to be difficult

So please make sure when you don’t mind personal devices being enrolled this admin removal trick would give you some headaches!

And now let’s see the results

Intune/Azure Ad

Just like with an Azure Ad Joined device, the MDM will be configured to Microsoft Intune but the join type would be Azure Ad Registered as shown below

DSREGCMD /Status

As shown above, on an AADR device you will notice it will list your Work Account

Conclusions:

Conclusion 1: So you can enroll your (existing) Azure Ad registered devices into Intune/MDM to make sure they are managed, cool… but when I need to choose, I prefer that all Windows 10 devices needed to be corporate enrolled and managed with Intune. No question about that, I am 1000% sure. No personal BYOD enrolled devices for me!

Conclusions 2:

When you want to allow BYOD Windows 10 devices in your organization, maybe instead of enrolling them into Intune, a Cloud pc from Microsoft is a way better option! You only need to wait until Microsoft could give us an AADJ Cloud device instead of HAADJ (and with a TPM)

Conclusion 3:

Please don’t forget the fact that performing an Azure Ad Join or registering a device into Azure is something completely different than enrolling them into Intune/MDM!

Conclusion 4:

If you share the same opinion as me, you want to make sure only corporate devices can be enrolled into Intune. I am blocking the possibility to enrol personally owned devices into Intune by configuring the setting “Personally Owned” Windows to Block

With this enrollment restriction, I can be pretty sure I am in control!