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. “
Azure AD Group Sync flow in a nutshell
- 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 configured succesfully
- Validate devices are (Hybrid) Azure AD registered (Azure Active Directory user discovery)
- Validate SSL communication (Enhanced HTTP)
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.
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.
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.
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.
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.
Technical Preview 2002.2 release includes additional management insight rules to help you configure your site for adding secure HTTPS communication:
- Sites that don’t have proper HTTPS configuration: This rule lists sites in your hierarchy that are not properly configured for HTTPS. This configuration prevents the site from synchronizing collection membership results to Azure Active Directory (Azure AD) groups. It may cause Azure AD sync to not upload all devices. Management of these clients may not function properly.
- Devices not uploaded to Azure AD: This rule lists devices that aren’t uploaded to Azure AD because the site isn’t properly configured for HTTPS.
For either rule, configure Enhanced HTTP, or enable at least one management point for HTTPS. These rules will not appear if you have previously configured the site for HTTPS communication.
Lovely when a plan comes together
By enabling Enhanced HTTP on our primary site device collection membership got synced to Azure AD 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.
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!