Azure/Entra ID SSO and the Challenge of Nested Groups

7/14/20252 min read

Configuring third-party applications for Single Sign-On (SSO) within Azure Active Directory (now Entra ID) has come a long way over the past decade. In the early days, the setup process was often ambiguous, and documentation was sparse or outdated. Today, while the user interface and support materials have improved significantly, some foundational limitations still persist—one of the most notable being the lack of support for nested groups in SSO application assignments.

A Familiar Frustration

Years ago, I configured an SSO integration for an enterprise application in Azure AD. After completing the setup and initial testing, I discovered an odd pattern: some users could sign in without issue, while others—who appeared to be in the correct group—were denied access. After hours of troubleshooting, I stumbled upon an obscure knowledge base article that finally revealed the culprit: Azure AD does not support nested groups in application assignments for SSO.

Correcting the authentication group structure resolved the issue, but the experience highlighted a frustrating gap in the platform’s design—one that still exists today.

Microsoft’s Current Stance

To its credit, Microsoft now includes a clear disclaimer when assigning groups to enterprise applications:

“When you assign a group to an application, only users directly in the group will have access. The assignment does not cascade to nested groups.”

While this helps prevent confusion for new administrators, it doesn’t change the reality that nested group memberships remain unsupported for SSO access control.

Why the Limitation Persists

There are valid technical reasons behind this design decision:

Token Size Constraints: Including all transitive (nested) group memberships in an authentication token can significantly increase its size—often beyond what certain applications, headers, or protocols (like SAML) can handle.

Performance and Scalability: Resolving deep or complex group hierarchies at sign-in time increases latency and places undue load on the Azure AD service.

Security and Complexity: Nested group structures can introduce ambiguity, especially when circular references or misconfigurations exist. Limiting token group claims to direct memberships helps maintain clarity and predictability.

While understandable from a technical perspective, it’s disappointing that after more than a decade, Microsoft has yet to provide a scalable, built-in solution for handling nested group membership in SSO assignments.

What Can You Do?

Until (or unless) native support for nested groups is introduced, organizations must use alternative methods to bridge the gap. Two of the most effective approaches are:

1. Extension Attributes and Claims Mapping

Customize token claims to evaluate user attributes or roles instead of relying solely on group membership. This can be particularly useful when applications can interpret those attributes to determine access.

2. Dynamic Groups

Create dynamic groups in Entra ID that automatically populate based on defined rules—effectively flattening the group structure by including all relevant users, regardless of nesting.

While these solutions don’t cover every scenario, they are highly effective in environments where identity data is well-managed and consistently maintained.

Need Help Navigating These Challenges?

If your organization is facing difficulties with group-based access control in Azure/Entra ID or struggling to implement scalable workarounds for nested groups, Cloud Security Solutions is here to help.

We specialize in designing and implementing secure, efficient identity and access management strategies tailored to your needs.

Visit us: https://cloudsecuritysolutions.tech

Let us help you get SSO right—without the headaches.