AGDLP

AGDLP (an abbreviation of "account, global, domain local, permission") briefly summarizes Microsoft's recommendations for implementing role-based access controls (RBAC) using nested groups in a native-mode Active Directory (AD) domain: User and computer accounts are members of global groups that represent business roles, which are members of domain local groups that describe resource permissions 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.^[1] 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.^[2] 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:^[3][4]

Global security groups 

Domain security groups with global scope represent business roles or job functions within the domain. These groups may contain accounts and other global groups from the same domain, and they can be used by resources in any domain in the forest. They can be changed frequently without causing global catalog replication.

Domain local security groups 

Domain security groups with domain local scope describe the low-level permissions or user rights to which they are assigned. These groups can only be used by systems in the same domain. Domain local groups may contain accounts, global groups, and universal groups from any domain, as well as domain local groups from the same domain.

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 expensive 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.^[5] 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.^[6] The abbreviation AGLP refers to these limitations as applied to RBAC implementations in older domains: Global groups represent business roles, while local 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:

1. Create a new domain local security group in Active Directory named "Change permission on \\nyc-ex-svr-01\groups\bizdev".
2. Grant that domain local group the NTFS "change" permission set (read, write, execute/modify, delete) on the "bizdev" folder. (Note that NTFS permissions are different from share permissions.)
3. Make the global group "Business Development Team Member" a member of the domain local group "Change permission on \\nyc-ex-svr-01\groups\bizdev".

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.

References

1. Ferraiolo, D.F. and Kuhn, D.R. (October 1992). "Role Based Access Control" (PDF). 15th National Computer Security Conference. pp. 554–563.
2. Sandhu, R., Coyne, E.J., Feinstein, H.L. and Youman, C.E. (August 1996). "Role-Based Access Control Models" (PDF). IEEE Computer (IEEE Press) 29 (2): 38–47. doi:10.1109/2.485845.
3. Microsoft Corporation (2007-03-16). "Group Scopes: Active Directory". Microsoft Technet. Archived from the original on 14 March 2009. Retrieved 2009-04-28.
4. Melber, Derek (2006-05-18). "How to Nest Users and Groups for Permissions". WindowsSecurity.com. Retrieved 2009-04-28.
5. Microsoft Corporation (2005-01-21). "Understanding the Global Catalog: Active Directory". Microsoft Technet. Retrieved 2050-10-21. Check date values in: |access-date= (help)
6. Stanek, William R. "Understanding User and Group Accounts". Microsoft Technet. Archived from the original on 27 April 2009. Retrieved 2009-04-28.