Default checks to perform when implementing Hybrid Identity, Part 4: Groups with large memberships

Reading Time: 5 minutes

Microsoft has introduced an impressive array of technologies and an awesome vision on Hybrid Identity:

Hybrid Identity

Their vision entails seamless access to corporate resources, services and applications for people, no matter where these resources, services and apps are located (either on-premises or in the cloud) while in the mean time allowing for strong authentication and granular authorization.

While Microsofts Azure Active Directory Hybrid Identity Design Considerations document details a lot of pitfalls you might want to avoid while implementing Microsofts Hybrid Identity technologies in the areas of process and architecture, my projects, on the other hand, have shown technical customer configurations beyond belief.

In this series I’ll detail these configurations, how they ruin Hybrid Identity dreams and how to fix them.

Today, let’s discuss group memberships for groups synchronized from your on-premises Active Directory Domain Services environment(s) to Azure Active Directory.

This is a scenario I experienced myself, and I think this is a limit a large organization may run into.

 

Group memberships in Active Directory

When Active Directory shipped with Windows 2000 Server, it came with group membership limits of 5,000 members. In the Windows Server 2003 Forest Functional Level (FFL), this limitation was lifted with the introduction of link-value replication (LVR).

To enable this feature, the Active Directory Forest Functional Level (FFL) needs to be at least Windows Server 2003 interim and any groups expecting to hit the 5,000 limit, need to be cleared of their memberships. After that, the members can be added back to change the way of replication.

The Active Directory Maximum Limits – Scalability documentation further states:

So far, testing in this area has yet to reveal any new recommended limits to the number of members in a group or any other linked multivalued attribute. Production environments have been reported to exceed 4 million members, and Microsoft scalability testing reached 500 million members.

Essentially, Active Directory Domain Services (AD DS) does not offer group membership limitations, as long as the environment is running a currently supported Forest Functional Level (FFL).

 

The group membership limit in Azure AD

Groups in Azure Active Directory, that are synchronized from on-premises to Azure Active Directory using Azure AD Connect, are limited to 50,000 members.

Note:
Groups in Azure Active Directory, that are still synchronized from on-premises to Azure Active Directory using the soon-to-be-deprecated DirSync tool are limited to 15,000 members.

The 50,000 group membership limit applies to:

  • Synced security groups
    Security groups, synchronized from your on-premises Active Directory Domain Services environment(s) to Azure Active Directory
  • Synced distribution groups
    Distribution groups, synchronized from your on-premises Active Directory Domain Services environment(s) to Azure Active Directory

The limit does does not apply to:

  • Azure AD-only groups
    When a group only lives in Azure Active Directory, the limit does not apply.
  • Nested groups
    The limit applies to memberships per single group. While a group that is a member of a group counts as a membership for that latter group, its memberships do not.
  • Critical security groups
    Security-enabled groups with the attribute isCriticalSystemObject configured as true. These objects, by default, are not synchronized and include most of the built-in groups. You can get an overview of these groups, using the following PowerShell Oneliner:

Get-ADGroup -filter 'iscriticalsystemobject -eq $true' | ft 

  • Mail-enabled groups without SMTP e-mailaddresses
    Security and distribution groups that have no “SMTP:”address entry in the proxyAddresses attribute and have an empty mail attribute, by default, are not synchronized.

Indications of hitting the limit

When the group membership limit is hit, the Azure AD Connect Sync Engine will stop synchronizing to Azure Active Directory.

In the Application log of the Windows Server on which Azure AD Connect is installed and running, you’d find Event ID 107 errors with source Directory Synchronization, and Event ID 6803 with source AD Sync, along with several other events.

EventID 107 with Source Directory Synchronization: Error code: 16. Error Description: Synchronization has been stopped. Your company has exceeded the number of objects that can be synchronized.

EventID 6803 with source ADSync: The management agent failed on run profile "Export" because the server encountered errors.

Additionally, in the Synchronization Service Manager of Azure AD Connect, you would see that Exports for the Azure Active Directory connector would report stopped-server-down and the Delta Synchronization for the Active Directory connector has completed-sync-errors as its status.

When you drill down into the flow error for the latter, you’d see a mention of the sync-rule-error-function-triggered for the Connector Space Object Properties of the group that is causing the error.

Connector Space Object Properties

Circumventing the limit

Ways to circumvent the limit are:

  • Remove memberships from the on-premises Active Directory group, before synchronizing the group to Azure Active Directory
  • Empty the Active Directory Recycle Bin
  • Create the group in Azure Active Directory with memberships and don’t synchronize the on-premises group

Solving the situation

You will need to contact Azure support to get the situation fixed.
Support request can easily be initiated through the Help and Support section of the Azure Portal.

While you can solve all the other warnings, errors, etc., the Azure Active Directory connector will remain broken and report stopped-server-down.

The situation feels comparable to Active Directory Domain Controllers that suspects replication partner(s) of UPN Rollbacks. They will turn their back and not replicate anymore. We know how to deal with that situation, but we don’t have the ability to run repadmin.exe on Azure Active Directory. Knipogende emoticon

Thus, preventing the situation from happening is preferable to detecting and then getting the situation solved by Azure support, especially when you have people from higher management breathing in your neck to solve synchronization fast and questioning Microsofts Hybrid Identity strategy in the process.

 

Detecting Active Directory groups with 50,000+ members

Use the PowerShell script below to detect groups in the on-premises Active Directory environment, the machine you run it from, is joined to:

cls
"Started Inventory."
$Groups = Get-ADGroup -filter "*" -Properties DistinguishedName,Members
"Inventory stage done."
"Started Analysis."

ForEach ($Group in $Groups) {
$Members = $Group.Members | Measure-Object
    if ($Members.Count -gt 49999) {
Write-Host -foregroundcolor Yellow "Group $Group might cause sync problems."
}
}

"Analysis done."

 

Concluding

When you suspect your on-premises Active Directory Domain Services environment(s) have groups with more than 50,000 or more members, it’s a good idea to know the Azure Active Directory group membership limit up front.

Related knowledgebase articles

2812409 You receive a "This company has exceeded the number of objects that can be synchronized" error in a directory synchronization report
2643629 One or more objects don't sync when the Azure Active Directory Sync tool is used

Further reading

Conquer Active Directory’s Built-In Limits
LDAP Query Basics
Working with Active Directory using PowerShell ADSI adapter
Event ID 2095 and The USN Rollback Adventure

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.