Building a robust RBAC model in Active Directory is one of those projects that rewards patience and punishes shortcuts. The classic nested group design using the AGDLP pattern (Accounts nested into Global groups, nested into Domain Local groups, assigned to Permissions) gives you a clean separation of concerns: organizational structure on one side, resource permissions on the other, with a clear mapping between them.
Done well, it's genuinely powerful. File shares, SharePoint Online, SQL servers, internal applications — all governed by a group structure that's logical, auditable, and maintainable.
The problem surfaces when you try to hand it off.
Why RBAC in AD Is Hard to Maintain
The design challenge isn't creating the initial RBAC structure. It's keeping it coherent over time as the organization changes around it.
Active Directory was designed for static environments. The AGDLP pattern assumes a relatively stable set of roles, resources, and users. Modern organizations don't stay static. Teams reorganize, projects spin up and down, hybrid and multi-cloud environments add complexity, and SaaS applications sit entirely outside the AD boundary.
The practical result is that AD RBAC implementations drift. New groups get created outside the established naming conventions. Exceptions get granted directly to user accounts rather than through groups. Nested groups accumulate layers that nobody fully understands. Service accounts accumulate permissions without review. Within a few years, what started as a clean AGDLP implementation becomes a tangle that nobody wants to touch because the blast radius of a change is unpredictable.
Designing It Right: The AGDLP Pattern
For anyone building from scratch or cleaning up an existing implementation, the AGDLP pattern is still the right starting point.
Accounts (user objects) are added to Global groups that represent job roles or organizational units. A Global group called GG-Engineering-Backend contains all backend engineers. This is the identity layer: it reflects who someone is, not what they can access.
Global groups are nested into Domain Local groups that represent access requirements for specific resources. A Domain Local group called DL-FileShare-ProjectX-ReadWrite controls read/write access to a specific file share. This is the access layer: it represents a permission set on a resource, not an identity.
Domain Local groups are assigned to Permissions on the actual resources. The file share, the SQL server, the SharePoint site.
The separation pays off when things change. An engineer moves from backend to frontend: remove them from GG-Engineering-Backend, add them to GG-Engineering-Frontend. Their resource access updates automatically because the Domain Local groups are downstream. You never touch the resource permissions directly.
Naming Conventions and Documentation
The single biggest maintainability factor in AD RBAC is consistent naming. Groups named with clear, machine-readable conventions are groups that can be audited, scripted against, and understood by the next person who inherits the environment.
A workable convention follows the pattern: TYPE-Scope-Resource-Permission
GG-Department-TeamNamefor Global groups representing organizational unitsDL-Server-ResourceName-AccessLevelfor Domain Local groups representing resource permissionsSA-ApplicationName-Purposefor service accounts
Enforcement matters as much as the convention itself. If admins can create groups outside the naming standard, they will, especially under time pressure. Group creation should require justification and should be reviewed against the naming convention before approval.
The Hybrid AD Problem
Most organizations running Active Directory are also running Azure AD (now Microsoft Entra ID), either because they've migrated to Microsoft 365 or because they have cloud workloads that need identity integration.
Hybrid AD introduces complexity that pure on-premise implementations don't have. Azure AD Connect syncs identities from on-premise AD to Entra ID, but the sync is unidirectional by default. Groups created in Entra ID (cloud-only groups) don't sync back to on-premise AD. Applications that use Entra ID for authentication may not respect on-premise AD group membership, and vice versa.
The governance implication is that you can have a clean RBAC model in on-premise AD and a separate, potentially inconsistent access model in Entra ID, with no single view of what a user's full access entitlement looks like across both environments.
Addressing this requires either a unified directory strategy (gradually migrating to cloud-only identity) or a governance layer that can see across both environments and manage access in both from a single control plane.
Where AD RBAC Ends and IGA Begins
AD RBAC handles the structural enforcement of access within the AD environment. What it doesn't handle is the governance layer above the structure: the processes for requesting access, approving it, reviewing it, and revoking it when it's no longer needed.
That gap is where Identity Governance and Administration platforms operate. Zluri, for example, integrates with Active Directory through an on-premise connector that can read current group memberships, execute provisioning and deprovisioning actions, and surface AD group access in access review campaigns alongside SaaS application access.
The practical effect is that the RBAC model you've built in AD becomes part of a larger governed access framework. New hire onboarding triggers automatic provisioning into the appropriate AD Global groups based on their role in the HRMS. Role changes update group memberships automatically. Offboarding removes all AD group memberships as part of a deprovisioning playbook that also covers every connected SaaS application.
Access reviews give department heads visibility into current AD group memberships for their teams, with the ability to certify or revoke access through a structured workflow rather than a service desk ticket. The review record feeds directly into audit evidence for SOC 2 or other compliance requirements.
The Maintainability Problem, Solved
The reason AD RBAC implementations drift is that the governance processes around them are manual. Group creation is ad hoc. Access requests go through informal channels. Reviews happen annually at best, usually as a pre-audit scramble. The AGDLP structure can be perfect on day one and degraded within two years.
The fix is connecting the structural model to automated lifecycle management. The RBAC design determines the group structure. The IGA layer governs who belongs in which groups, automates the changes that keep membership current, and produces the audit evidence that the structure is working as intended.
Neither element works well without the other. A clean AD RBAC design without governance automation drifts. An IGA platform without a coherent AD group structure has nothing structured to govern. The combination is what makes it maintainable at scale.
.svg)
