AGDLP


AGDLP briefly summarizes Microsoft's recommendations for implementing role-based access controls using nested groups in a native-mode Active Directory 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 and AGLP summarize similar RBAC implementation schemes in Active Directory forests and in Windows NT domains, respectively.

Details

Role based access controls 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 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 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 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 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 and local 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: Global groups represent business roles, while local groups 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 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 on the "bizdev" folder.
  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 instead of, in the worst case, editing as many ACEs as there are users with access to the folder.