Device collection membership Synchronization to Azure AD security groups (aka Azure AD Group sync) is introduced since 1906 and offers a multitude of new management options. Meanwhile a lot has been written and resulted in some great blog posts by various community peers like Nickolaj Andersen, Nick Hogarth as well as by Microsoft Docs.
What these resources have in common is they all describe how to enable and configure Azure AD group sync. In this blog post I’ll go in to more details what’s behind the scenes, how device collection synchronization works and what actions you can take in the event of troubleshooting is desired.
As mentioned synchronizing device collection membership to Azure AD security groups is useful in various scenarios. Microsoft Endpoint Configuration Manager (MECM) simply offers way more options as Azure AD Dynamics Group membership by default does.
Reason to investigate was a customer case where Azure AD Group sync didn’t work. Cloud management seemed to be properly configured in the first place, where co-managed devices were registered successfully in Azure AD. With some research I came across a blog post of my community fellow Nickolaj Andersen which provided me some pointers to determine why device collection membership were not synchronized.
“Device memberships will not synchronize to an Azure AD group if a certain value with the Azure AD tenant ID (also known as the Directory ID) is populated on the device in the ClientKeyData table. “
No device objects are populated and therefore not being added to an Azure AD group.
Azure AD Group Sync flow in a nutshell
Flow of how device collection membership synchronization to Azure AD groups works.
- The Endpoint Configuration Manager administrator imports or creates the client and server apps in Azure AD.
- Endpoint Configuration Manager Azure AD user discovery method runs. The site uses the Azure AD server app token to query Microsoft Graph for user objects.
- The site stores data about the user objects. For more information, see Azure AD User Discovery.
- The Endpoint Configuration Manager client requests the Azure AD user- or device token. The client makes the claim using the application ID of the Azure AD client app, and the server app as the audience. For more information, see Claims in Azure AD Security Tokens.
- Clients will register their Azure AD information to the Endpoint Configuration Manager server using Azure AD token authentication.
- When the AADTenantID information is populated in dbo.ClientKeyData table, device collection membership(s) are synced to Azure AD security groups.
Now we’ve a better understanding how Azure AD Group sync works, we’ll continue with troubleshooting attempt. When Azure AD Group sync isn’t working as expected please double check the following areas:
Validate Cloud Management setup
Make sure you on-board the Azure AD tenant to allow Endpoint Configuration Manager (client/server) to use Azure AD authentication in the first place.
Make sure your Azure AD tenant is successfully registered in Endpoint Configuration Manager.
select convert(xml, settings), * from sites where ISNULL(reporttosite, N”) = N”
To confirm if the tenant is added for the client, can you run this query on your site database.
The first column xml should be like this,
Only after the tenant is on boarded successfully, clients will register their Azure AD information to the Endpoint Configuration Manager server using Azure AD token authentication.
This information will end up at the dbo.ClientKeyData table. When the AADTenantID information isn’t populated in dbo.ClientKeyData table, device collection membership(s) are not synchronized to Azure AD security groups.
When the AADTenant ID isn’t populated in dbo.ClientKeyData table, device memberships are not synced.
The Azure AD information in dbo.System_Disc table comes from the client heartbeat discovery. Although only heart-beats from registered clients are accepted by Endpoint Configuration Manager server, there is no proper Azure AD authentication flow for that route so any registered client can say whatever Azure AD device ID it has.
That’s why the Azure AD info from dbo.System_Disc is not trusted. For the Azure AD groups sync, only trusted data is used. That’s why Azure AD tenant on-boarding for client management is a prerequisite for Azure AD Group sync.
Validate devices are (Hybrid) Azure AD registered
For those that are supposed to register but didn’t, likely will need to get the client logs to see what went wrong. Besides dsregcmd.exe /status consult ClientIDManagerStartup and ADALOperationProvider* log files on the client side.
Another common failure is fail to get Azure AD token because of Multi-Factor Authentication (MFA) is enabled. Windows 10 RS3 (1709) and below devices don’t support Azure AD device token. The user token of the logged on user even for the machine scenarios is required. If MFA is required, and the user didn’t login using PIN, failure can happen as well.
Windows 10 RS3 (1709) and below devices don’t support Azure AD device token and therefore an user token is used. Starting from Windows 10 RS4 (1803) and higher devices use device token which is way more stable to use Azure AD token authentication.
select count(*) from clientkeydata where isnull(isrevoked, 0) = 0 and agenttype=0 and (AADDeviceID is not null)
Use the query below to check if devices that were able to Azure AD register.
Validate SSL communication
One important requirement, which is part of Cloud Management configuration is Enhanced HTTP (E-HTTP) which is fairly hidden but which proved to be the key success to let Azure AD Group sync work as expected. Azure AD-joined and Hybrid Azure AD-joined clients can communicate with a management point (MP) via HTTP for device-centric scenarios, but requires E-HTTP or HTTPS to enable user-centric scenarios.
On the site properties Communication Security tab, you configure the site system settings to HTTPS or HTTP, and you enable the option to Use Configuration Manager-generated certificates for HTTP site systems (aka Enhanced HTTP).
Next step is to configure your Management Point for both HTTP and HTTPS communication. On your Management Point, checks CCM_STS, MP_Registration and ClientAuth logs whether communication based on Azure AD token authentication is successful.
Lovely when a plan comes together
By enabling Enhanced HTTP on our primary site device collection membership got synced to Azure AD Groups.
Device collection membership information is synced where devices shows up in the according Azure AD security groups.
Part on the cloud-attach strategy to empower your Endpoint Configuration Manager hierarchy, Azure AD Web App- (Web app / API/aka server app) and Azure AD Native App (Native/aka client app) services are used to integrate with Azure services to authenticate communications and perform actions in Azure AD.
The web app configured as part of the Cloud Management configuration should be assigned as Owners of the Azure AD Security group(s) which will be filled with devices based on the linked collection(s). Use the Audit logs to determine whether the web app has assigned the correct permissions to perform device adds- or deletions.
Using Audit logs to track changes to the Azure AD Group(s) which are being synced.
Good to know
- The Azure AD synchronization happens every five minutes.
- It’s a one-way process, from Configuration Manager to Azure AD. Changes made in Azure AD aren’t reflected in Endpoint Configuration Manager collections, but aren’t overwritten by Configuration Manager.
- Only devices with an Azure Active Directory record are reflected in the Azure AD Group sync.
- Both Hybrid Azure AD Joined and Azure Active Director joined devices are supported.
An overview of Endpoint Configuration Manager features which support or require enhanced HTTP can be found here. Based on my experience Azure AD Group sync should be added to this list as well.
HTTPS is mandatory for Azure AD Group sync as Azure AD token authentication requires SSL. That means Management Point’s have to be either HTTPS using PKI, or Enhanced HTTP using the Endpoint Configuration Manager generated certificates.
Note: Special thanks to Vincent Huang (Microsoft) for sharing valuable insights!