Building Active Directory Groups For Role-based Access

Building Active Directory groups correctly to simplify administration and build permissions sets based on job roles takes a lot of work. Like most things, preparation and forethought will save you time and confusion later. So in this post, I will lay out the correct way to build Active Directory groups with role-based access controls using a security group nesting method. Following this method will increase security and decrease management time.

If you are experienced in Windows Active Directory and know what AD group nesting is and why it is necessary, you can skip to following two key sections.

• Active Directory Nested Group Methodology
• Building Nested Active Directory Groups

---

What is Active Directory Group Nesting?

Active Directory can nest groups, which involves putting one group inside another. Creating a parent group and nesting sub-groups as members will provide all the permissions and access rights of the parent group. Group nesting in Active Directory will allow you to build permission sets for defined job roles.

Why set up Group Nesting?

Nesting groups allow for easier user access and permissions management, as specific job roles or permission sets are created and assigned by nesting the appropriate groups.

For example, a group for “Accounting-Data-Access” may be created and given specific permissions to access certain data. A group for “Accounts Users” can then nest within the “Accounting-Data-Access” group to inherit those permissions. This simplifies managing permissions and access for large organizations with complex structures.

Also, More Security!

Group nesting in Active Directory will increase security overall for the domain. Nested group permissions can be assigned to groups rather than individual users, reducing the risk of granting access to the wrong person or forgetting to remove access when someone leaves the organization. This approach also makes auditing and reviewing access to resources within the domain easier, as the permissions assigned to a group can be quickly examined and modified as necessary.

Furthermore, nested groups can enforce a principle of least privilege, where users are only given the necessary access to perform their job functions. By nesting groups and assigning permissions to those groups, access to sensitive resources can be restricted to only those users who require it.

---

Understanding Group Scoping

Before moving on to how to build nested groups, I want to review group scopes. The group scope will limit the reach of permissions sets. So if we limit the scope of a group, by extension, we limit its permissions and prevent abuse. Using limited scopes is most important once you add additional AD forests or domain trusts. Even if you don’t need additional forests or domain trusts right now, it does not mean you won’t need them later. Organizations constantly change, and the first time you go through a company merger or de-merger, you will be glad you set up groups correctly.

Below is a table of the three Active Directory group scopes and their related details. You don’t need to memorize the table. However, if you have questions about why nested groups use one scope over another, refer to this table.

AD Group Scope Table

Scope	Possible members	Can grant permissions	Possible member of
Universal	Accounts from any domain in the same forest Global groups from any domain in the same forest Other Universal groups from any domain in the same forest	On any domain in the same forest or trusting forests	Other Universal groups in the same forest Domain Local groups in the same forest or trusting forests Local groups on computers in the same forest or trusting forests
Global	Accounts from the same domain Other Global groups from the same domain	On any domain in the same forest, or trusting domains or forests	Universal groups from any domain in the same forest Other Global groups from the same domain Domain Local groups from any domain in the same forest or from any trusting domain
Domain Local	Accounts from any domain or any trusted domain global groups from any domain or any trusted domain Universal groups from any domain in the same forest Other Domain Local groups from the same domain Accounts, Global groups, and Universal groups from other forests and from external domains	Within the same domain	Other Domain Local groups from the same domain Local groups on computers in the same domain, excluding built-in groups that have well-known security identifiers (SIDs)

---

Active Directory Nested Group Methodology

So what is the correct way to build AD Groups? Glad you asked. Let me illustrate the general idea of how we will nest our groups.

So we have User Accounts, which are added as members of an “Identity group” with a Global Groups scope. The Identity group is named this because it contains only User account objects(identities). The Identity groups should contain users with the same job role. For example, an Identity group called “Accounting Team” contains all the users of the accounting team.

Access Control List(ACL) Groups have rights and permissions sets granted to them. An ACL group should have permissions related to a job role. When we want to give users with a job role permissions needed for their job, we will add the job role’s Identity group as a member of the ACL group that has the required permissions. The members within the ACL group will inherit all the rights and permissions. ACL groups need to be in a Domain Local groups scope.

What Not To Do

• Never assign User Account permissions directly to an object. So, never assign the User Account “Bob” read/write permissions on a file share. The Bob account should inherit its file share permissions from its Identity group, which, in turn, inherits its permissions from the ACL groups it’s a member of.
• Never assign an Identity group(a group that contains any User Accounts) permissions directly to a resource. Identity groups are only meant to contain User Accounts.
• Never add User Accounts directly to an ACL group. ACL groups should only contain nested Identity groups.

---

Building Nested Active Directory Groups

Let’s run through setting up nested groups and permissions.

1. Create the Identity group

The first step is to create an Identity group with a descriptive name that reflects its purpose. For example, if the group is for Tier-3 Systems Administrators users, the name could be “Tier-3-SAs“. The group scope needs to be Global. Add the appropriate user accounts to this group.

2. Create the ACL group

Next, create the Access Control List (ACL) group and give it a descriptive name that reflects its purpose. For example, if the ACL group is for Teir-3 Systems Administrators access, the name could be “Tier-3-SAs_ACL“. The group scope needs to be “Domain Local“.

3. Nest the Identity group

Add the Identity group (“Tier-3-SAs“) as a member of the ACL group (“Tier-3-SAs_ACL“). This will give all members of the Identity group access to resources that the ACL group has permission to access.

4. Add ACL permissions

Apply the appropriate permissions to the ACL group (“Tier-3-SAs_ACL“). For example, permissions can be given on a file share by right-clicking on the resource (e.g., folder, file) and selecting Properties > Security > Edit. Choose the ACL group and apply for the appropriate permissions.

5. Test the group

After creating and applying for permissions, test the group to ensure the appropriate users can access the resource.

AD Group Organizing Tip

To decrease future AD Administrator’s confusion over if a group is an Identity group or an ACL group, create two separate OUs for each.

---

Building AD Groups for Role-based Access: TLDR

To wrap this up, if you want to simplify Active Directory management build nested security groups around role-based access. The proper way to create Windows AD groups with nested memberships involves the following.

• Creating an Identity group for users.
• Creating an ACL group for permissions.
• Nest the Identity group within the ACL group.
• Apply appropriate permissions to the ACL group.

Following these steps, you can easily manage access to resources within a large organization.

---