Hello Everyone! My name is Dheeraj and I am a Support Engineer with the Mobility team, working on the Enterprise Mobility Suite of products. Few weeks ago, I worked on an interesting support issue relating to Group provisioning from On-premise to Azure Active Directory and I wanted to share this information with you. If you happen to run into this scenario, this article will help you troubleshoot and isolate the problem.
Some of the group objects present in Active Directory on-premise were not synchronizing to Azure Active directory.
While looking at the AADConnect tool, the following errors were observed in the sync operations tab whenever export run profile was executed on the Azure AD Management Agent (a.k.a Cloud Connector).
“Every group requires that the Security Enabled attribute have a valid value. This attribute indicates whether the group is a security enabled group. Please set this attribute, and then try again.”
SecurityEnabled is a mandatory attribute which needs to be populated in order to provision a group successfully into Azure Active Directory. In this scenario, the attribute was not getting populated and we needed to find out why.
We began by reviewing the AADConnect configuration.
It was interesting to note that there were some security groups which did sync up successfully to Azure AD. So, there must be something unique about these groups that failed to provision.
To understand this better, we started comparing the attributes of working security group and non- working security group.
For our discussion, let’s take the groups as Group1 and Group 2.
CN= Group1 (Synchronized group)
CN= Group2 (Non Synchronized group)
We first started searching in AD connector space with RDN “CN=Group1” and “CN=Group2” and validated if the security enabled attribute is set to True. We found that both the groups had this attribute set to true.
We then validated if isCriticalSystemObject value is set, found that it is not set on non-synchronizing groups. If this attribute is set to true, then this is filtered from getting provisioned into Azure AD. Here is a snippet from a TechNet post that is referenced later on in this article.
That brings us to the next question – Which attributes are required at a minimum in order to get provisioned into Azure AD?
This TechNet post provides an exhaustive list of all the attribute that can be synced as well as the ones that are mandatory.
In the AADConnect tool, the in-flow and out-flow of these attributes are controlled by the Sync rules, which can be configured using the Synchronization Rule editor. So, that is our next stop.
We reviewed the inbound and outbound synchronization rules for Groups and compared with a default working setup from our lab. That is where we found out that the original out of the box rules were missing!!
In the ‘out to AAD- Group join’ sync rule we had only 4 rules and we were missing the rule for SecurityEnabled Attribute.
So, we went ahead and re-added a direct mapping for the SecurityEnabled attribute ( as shown in the screenshot below )
Following this, we ran the sync profiles and we could observe that the attribute was now populated and exported successfully to Azure AD!
But the success was short-lived as the customer ran the configuration wizard once again and we were back to the square now. The rule got wiped out. But now, we know where exactly to look for!
We went through each step in the configuration wizard and identified that the SecurityEnabled attribute was not selected in the wizard.
Here is a CSV export comparison of the attribute list from an Out-of-box configuration vs the one having the problem.
This can also be viewed in the UI at the Azure AD attributes section:
Typically, the attribute list is not something that we should be modifying as this would directly affect the sync rules which would then affect the synchronizations made between on-premise and Azure Active Directory. Customers are recommended not to uncheck attributes that are absolutely essential for syncing objects between On-premise and Azure.
Once we re-selected the missing attribute in this wizard, the issue was resolved completely and all existing as well as new groups started to sync successfully with Azure.
I hope this blog provides a general troubleshooting approach that can be taken to identify attribute-related issues while working with Azure AD connect. The key takeaway here is to understand the mandatory attributes needed for provisioning to Azure and also identify missing configurations from sync rules and wizards.
Happy troubleshooting !!
Microsoft Mobility Team
Microsoft Security Support Escalation Engineer