Blog article

Building a group structure - the "AGDLP" principle

by Ute Schwietering (comments: 0)

When setting up the Active Directory the question arises as to how to deal with the various group scopes. Windows offers global, domain local and universal groups. This article describes the role based group organisation - which is recommended by Microsoft for an efficient permission administration - on the basis of the so-called "AGDLP" principle. This principle offers you an optimal group nesting which reduces your amount of work, increases the transparency of permissions and - when dealing with more than one domain - lessens the replication work in the network.

The "AGDLP" principle

The letters mean

  • A: user or computer account,
  • G: global group,
  • DL: domain local group,
  • P: permission (e.g. entry in access control list).

With the help of this principle a role based group organisation with the following characteristics is built up:

  • Global groups bunch user and computer accounts and represent roles which orient themselves to business processes.
    Examples: controlling, end user support, sales
  • Domain local groups are used for protected resources (e.g. folders) and registered into the access control lists.
    Important: These groups will be used only in the folder ACL and not elsewhere in Active Directory. They will be referred to as business permission groups and correspond to process permissions.
  • To authorize a number of users, the global group will simply be registered as a member of the resource domain local groups.

This results in several administrative advantages:

  • In general, there will be only two business permission groups (read only and read/write/delete) in the ACL of a protected resource (e.g. a folder).
  • Single users will never be directly authorized, only global groups.
  • Organisational units and permissions can be directly read with the help of a suitable naming convention for business permission groups.
    Example: Reading permission in "Sales" folder: DL_Sales_R (domain local group)
  • The business permission group contains only global groups of users as members.
    Example: The domain local group DL_Sales_RWD contains the global (user) groups
    G_U_Sales_Manager, G_U_Sales_Office, G_U_IT_Support, Domain Admins
  • A change in user permissions takes place in AD only by changing the global groups - no longer in the file system.
  • Also business changes to access rights do not take place in the file system, but by a definition of new global groups in AD and assignment to domain local resource groups, e.g. for projects which are to receive temporary permissions.

Implementation with Parks Authorization Manager (PAM)

An example with Parks Authorization Manager (PAM) shows the principle on the basis of a protected departmental folder.

A folder should be generated for each department where staff members of the department have reading and writing access, and to which other staff members may get reading rights only. For this, a folder template is defined in PAM which will be used when creating the departmental folder.

The corresponding group scope (domain local) is selected during definition of the permissions in the folder template. Also, the required permissions, which are to be entered into the ACL, are clicked upon.

If a departmental folder is to be generated later with the template, PAM automatically creates the groups in Active Directory and initialises the folder ACL in the NTFS file system.

Example: If a folder is created for an organisational unit "Sales", PAM automatically generates a domain local group "DL_Sales_RE" in Active Directory and inserts it with the corresponding permissions (read and execute) into the folder ACL in the NTFS file system (PAM replaces the place holder "$(OrgUnit)" in the name of the group with the organisational unit, "Sales" in this example). The global user groups can be entered into the new group, they will then receive the required access.

Go back

Add a comment