AGDLP (an abbreviation of "account, g****loba****l, domain loca****l, permission") briefly summarizes Microsoft's recommend****ations for imp****lementing role-based access controls (RBAC) using nested groups in a native-mode Active Directory (AD) domain: User and computer a ccounts are members of g loba****l groups that represent business roles, which are members of d omain l oca****l groups that describe resource p ermissions or user rights assignments. AGUDLP (for "account, global, universal, domain local, permission") and AGLP (for "account, global, local, permission") summarize similar RBAC implementation schemes in Active Directory forests and in Windows NT domains, respectively.

Details

Role based access controls (RBAC) simplify routine account management operations and facilitate security audits. System administrators do not assign permissions directly to individual user accounts. Instead, individuals acquire access through their roles within an organization, which eliminates the need to edit a potentially large (and frequently changing) number of resource permissions and user rights assignments when creating, modifying, or deleting user accounts. Unlike traditional access control lists, permissions in RBAC describe meaningful operations within a particular application or system instead of the underlying low-level data object access methods. Storing roles and permissions in a centralized database or directory service simplifies the process of ascertaining and controlling role memberships and role permissions. Auditors can analyze permissions assignments from a single location without having to understand the resource-specific implementation details of a particular access control.

RBAC in a single AD domain

Microsoft's implementation of RBAC leverages the different security group scopes featured in Active Directory: Global groups that represent business roles should contain only user or computer accounts. Likewise, domain local groups that describe resource permissions or user rights should contain only global groups that represent business roles. Accounts or business roles should never be granted permissions or rights directly, as this complicates subsequent rights analysis.

RBAC in AD forests

In multi-domain environments, the different domains within an AD forest may only be connected by WAN links or VPN connections, so special domain controllers called global catalog servers cache certain directory object classes and attribute types in order to reduce costly or slow inter-domain directory lookups. Objects cached by the global catalog servers include universal groups but not global groups, making membership look-ups of universal groups much faster than similar queries of global groups. However, any change to a universal group triggers (potentially expensive) global catalog replication, and changes to universal groups require forest-wide security rights inappropriate in most large enterprises. These two limitations prevent universal security groups from completely replacing global security groups as the sole representatives of an enterprise's business roles. Instead, RBAC implementations in these environments use universal security groups to represent roles across the enterprise while retaining domain-specific global security groups, as illustrated by the abbreviation AGUDLP.

RBAC in non-AD domains

Domains in Windows NT 4.0 and earlier only have global (domain-level) and local (non-domain) groups and do not support group nesting at the domain level. The abbreviation AGLP refers to these limitations as applied to RBAC implementations in older domains: G lobal groups represent business roles, while l ocal groups (created on the domain member servers themselves) represent permissions or user rights.

Example

Given a shared folder, \nyc-ex-svr-01\groups\bizdev; a business development group within the organization's marketing department, represented in Active Directory as the (existing) global security group "Business Development Team Member"; and a requirement that the entire group have read/write access to the shared folder, an administrator following AGDLP might implement the access control as follows: To highlight the advantages of RBAC using this example, if the Business Development Team required additional permissions on the "bizdev" folder, a system administrator would only need to edit a single access control entry (ACE) instead of, in the worst case, editing as many ACEs as there are users with access to the folder.