Odd Case Of MDM System Center Configuration Manager Instead of Intune in Azure AD. (It’s not Intune)
I have a bit of an (It’s not Intune) series going. Intune usually get’s blamed when it’s pretty much downstream from all of it’s prerequisites. In this case, we have a co-managed environment. MDM autoenrollment is enabled for Intune via GPO and The Configuration Manager Client. Here is some excellent reading on Azure AD Device token based enrollment via Configuration Manager from our Friend Martin Bengtsson:
When you check devices in the AzureAD portal, they say MDM: System Center Configuration Manager, and no User is associated with the device. When you run dsregcmd /status on the devices, they show AzureADPRT: NO for all users. Some further reading on that:
Autoenrollment is configured via GPO (as well as the configmgr client). As we know the GPO method defaults to User Token, and falls back to Device Token. Azure AD Device Token enrollment has been an option via ConfigMgr 1906. The short of it is, Devices were falling back to Device Token, rather than User Token. Why? A couple of issues. MDM User Scope was not opened up in Azure AD/Intune. That’s half the problem. OKTA was in the equation here. All the proper Identity Provider endpoints were not enabled. All user’s were getting AzureADPRT : NO.
Once these endpoints were ensured to be enabled, things started “magically” working. That means the Windows 10 Identity Provider was now able to successfully establish hybrid identity and acquire an AzureAD PRT since it could reach the necessary endpoints.
Now, when running dsregcmd /status, user’s see AzureADPRT : Yes.
And since we opened up the proper MDM scope, the user now had the ability to enroll. Again, this is one possible scenario of many configs out there since environments vary so wildly. When Intune MDM Autoenrollment isn’t working, always go back and triple check identity.
Until next time.
