Let’s say you recently turned on Tenant Attach and Co-Management for your tenant, and you’re excited to run SCCM commands from your Intune web interface.
But when you try to run a ConfigMgr-related command, like Collections, from that interface, it throws a Missing Configuration error:
Error 401 – Unable to get device information. Make sure Azure AD and AD User Discovery are configured and the user is discovered by both. Verify that the user has proper permissions in Configuration Manager
A Missing Piece From the Microsoft Setup Docs: Azure AD User and Group Discovery
If you Google this error, a Microsoft Doc will come up right up showing you the most common reason this occurs: The Azure AD User Account doesn’t have any permission in Configuration Manager.
Even the original error above tells you to configure “Azure AD User Discovery”. Huh?
Interesting note: The MS Docs walking through the co-management setup don’t mention having to setup Azure AD User and System Discovery. (at least, as of March 2022)
This is a case of “unknown unknowns” — if you didn’t already know that you had to set this up, you might wind up as confused as I was.
Azure AD User and Group Discovery is totally separate from ConfigMgr’s AD User/Group Discovery. The Azure AD one requires registration through the “Cloud Services” area in ConfigMgr:
An Azure Global Administrator is required to set it up, as the service has to create two Azure AD enterprise apps to work.
This will add Azure AD users and groups into ConfigMgr.
What it also does is signal to SCCM that these Azure AD users are married to on-premises AD users.
Also, Check The Directory Sync Status of Your Azure AD Account
If your Azure AD Account is Not Directory Synced, it will NOT be able to run CM commands.
CM doesn’t delegate access to Azure AD accounts directly.
Instead, CM is told to add these Azure AD accounts (and/or groups), and if those accounts are directory synced between AD and Azure AD, CM will pick up on this “marriage” between the two accounts.
In the logs, ConfigMgr translates the Azure AD account into its synced on-prem account, and uses the AD account to run the command that was sent via the MEM web interface.
If your account is not directory synced, it will throw an access denied error in the MEM interface when you run a CM command on a device.
To check this, go to Azure Active Directory -> Users, then check the “directory synced” column of the user that you’re running these commands under:
In the above image, for example, only one AAD account on my test tenant is synced to my test AD tenant, so only that one account could run the SCCM-related commands on a device from the MEM Console.
The M365 Developer Program Makes This Setup Free, By the Way
Intune licenses normally require an E3/A3 or E5/A5 license.
However, sign up for the M365 Developer Program, which is free, and you get Azure AD plus 25 licenses at the A5/E5 level to test with!
The only drawback: It doesn’t come with any Azure credits.
So if you want to implement the next logical step for testing — a Cloud Management Gateway — the resources it sets up will cost money.