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 / MAM scope. 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
- Information about AADJ and AADR
- Configuring MDM and MAM User Scope
- Compliance And Conditional Access
- Comparing the Azure PRT on AADR and AADJ devices
- How to Enroll an existing AADR device into MDM
- What’s working and What’s not?
Azure AD Registration
When you want to start making use of Bring Your Own Device (BYOD) and skip the corporate enrolled devices part, Azure Ad Registered Devices is the way to go. With AADR a user can 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 10 device you would log in with your personal Microsoft account and when logging into the organizational resources like Teams, an Azure Ad 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 make sure you can manage this device with Intune. It’s a terrible button, I am glad it’s a little bit more improved in Windows 11 but why not giving us the option to remove it/disable this on non managed devices.
If you have corporate-owned devices and you want to block this option, you can push a GPO. This would be the key you need:
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 email@example.com) 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. Just 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
When you think about AADR: Azure AD knows about the device but 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
After reading the first part we now know with AADJ and AADR we can access the company data and “could” have some management over the device. But like always there are of course 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 enrol a device into Intune, the MDM scope has to be configured.
First some background information about these scopes
When talking to customers, sometimes I notice 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! These scopes only apply to Windows 10 Devices! Not your IOS or Android devices.
So if we need to manage our AADJ or AADR devices and need them to get 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 10 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 enrol their Windows 10 devices
All – All users can automatically enrol their Windows 10 devices
When the MDM scope is configured, AADJ or AADR devices will automatically enrol into MDM management with Microsoft Intune.
Please note: When you configure this scope to none it doesn’t mean you can’t enrol a device into Intune, you still can enrol the corporate device in Intune manually.
So putting all the pieces together, the MDM user scope can be used to automatically enrol 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 enrol 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 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 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?)
Did you notice the last sentence in the picture above? “For Corporate devices”. So what makes a device corporate? The device needs to be: Azure Ad joined (Autopilot/User-Driven/OOBE) or enrolled with DEP to be marked as Corporate.
Not to forget you could also change the device category ourselves after enrollment
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.
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 Azure Ad Joined device. We will notice it has an AzureAdPrt set to YES.
But what about an AADR 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 an Ms365 App, it will use the Web Account Manager (WAM) for authentication and the single-sign.
The Azure Ad WAM plugin uses the PRT to enable SSO on Windows. The Azure AD WAM plugin uses the PRT to request refresh and access tokens for applications that rely on WAM for token requests
Once the MAM user scope setting is changed to None and leaving the MDM user scope, un-enrol/disconnect the windows 10 device from work /school and start adding the account which helps to enrol the device successfully to Intune followed by conditional access
You could also use the company portal app to enroll an existing Windows 10 device into Intune. If you want to read how to do this, please visit this Microsoft blog.
The results after reconfiguring a work/school account
After you have removed 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
Now we have seen we can enrol a personal BYOD device into Intune, what can be managed and whatnot with your azure ad registered devices and Intune? 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
Compliant Device / Conditional Access: Yes
Windows 10 Expedited updates: No
Device Configuration Policies/Settings Catalog: Yes
Endpoint Security: Yes
Bitlocker Recovery Key in Intune: Yes
Bitlocker Recovery Key Rotation: No
PowerShell Scripts: Yes
Proactive Remediations: Yes
(even when Microsoft tells us otherwise?)
You can look them up in the c:windowsimecachehealthscripts folder.
If you are interested in more proactive remediations, please visit my blog about it!
AADJ (MDM Enrollment)
You will notice the Join Type: Azure AD Joined and MDM set to Microsoft Intune
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
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 be enrolled this admin removal trick would give you some headaches!
And now let’s see the results
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
Conclusion 1: So you can enrol your (existing) Azure Ad registered devices and into Intune 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!
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)
Please don’t forget the fact that an Azure Ad join or registering a device into Azure is something completely different than enrolling them into Intune/MDM!
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.
With this enrollment restriction, I can be pretty sure I am in control!