Active Directory Group Types and Scopes Explained

8.1K

In this article, we’ll talk about the different types of Active Directory groups, the differences between them, group scopes, and will show you how to create AD groups and manage them in several ways.

What is an AD group?

An Active Directory group is a special type of object in AD that is used to group together other directory objects. In other words, a group is a way of collecting users, computers, groups and other objects into a managed unit. Active Directory groups can be used to grant permissions to access resources, delegate AD administrative tasks, link Group Policy Objects, and in e-mail distribution lists.

Group Types and Scopes in Active Directory

When you create a new group in Active Directory using the dsa.msc graphical snap-in, you must select a Group Type and Group Scope.

Modern Identity: Microsoft Entra ID and Cloud Groups

In modern enterprise environments, AD groups are often synced with Microsoft Entra ID, which extends group management into cloud identity scenarios. In Entra ID, groups are no longer limited to on-prem AD scopes. Instead, organizations commonly use:

• Security groups (cloud/synced from on-prem AD)
• Microsoft 365 groups (collaboration-based groups used in Teams, SharePoint, Outlook)
• Dynamic groups (rule-based membership using user/device attributes)

Active Directory group types

There are two types of Active Directory group, each with three scopes:

• Security Group — this type of group is used to provide access to resources (security principal). For example, you might want to allow a particular group to read files on a shared network folder. To do this, you need to create a security group, edit the share permissions, and add this group to the DACL;
• Distribution Group — used to create e-mail distribution lists (usually used in Microsoft Exchange Server and in Outlook). An e-mail sent to such a group will reach all users (recipients) in the group. This type of group cannot be used to provide access to domain resources, because they are not security enabled.

Note. You can assign email attribute to the security group and use it in distribution lists by converting it to a mail-enabled security group (but it is not recommended).

Active Directory group scopes

There are three group scopes in Active Directory, these are Domain Local, Global, and Universal.

When to use Domain Local, Global and Universal groups (real-world scenarios)

Global Groups (real-world usage)

Global groups are used when you need to group users based on identity or role inside a single domain. You should use Global Groups when you are grouping users by department/role, in case all users belong to the same domain, or you want to represent “who the users are”.

Rule of Thumb. You should use Global Groups as “logical buckets” to organize people based on their actual job titles/departments (like “Finance” or “Marketing”).

Domain Local Groups (resource permissions)

Domain Local groups are used when you assign permissions to resources such as files, shares, printers, or applications. You should use Domain Local Groups when you are granting access to a specific resource, when users can come from any domain, or in case you care about “what users can access”, not who they are.

Rule of Thumb. You should use Domain Local groups to manage what people can access, rather than who the people are.

Universal Groups (cross-domain roles)

You should use Universal Groups when your environment has multiple domains, when you need to combine roles from different domains or group membership changes rarely (to reduce Global Catalog replication traffic).

Rule of thumb. You should use Universal Groups sparingly to avoid heavy traffic caused by constant updates. In order to keep your network efficient, you should always nest Global Groups into them rather than individual users (this will make you sure that frequent membership changes remain local to their own domain).

How These Group Types Work Together

The group scopes described above are not used independently in real-world environments. Instead, they are combined into a structured access model:

• Global groups represent who users are (roles, departments)
• Domain Local groups represent what users can access (resources)
• Universal groups optionally combine roles across multiple domains

Dynamic Groups in Entra ID

Unlike traditional AD groups, Entra ID supports dynamic group membership based on rules. Here is an example:

• Users in the Finance department are automatically added based on `department` attribute
• Devices can be grouped based on OS version/compliance state

This eliminates manual group management and is widely used in large enterprises.

How AD Groups Work Together (AGDLP/AGUDLP Model)

How to Combine AD Groups (Best Practice Model)

Based on the roles and scopes described above, AD uses a structured model to assign permissions. It effectively creates a buffer between your users (who change roles frequently) and your resources (which rarely change).

AGDLP Model (Single Domain)

Check the standard model for most environments with a single domain: A > G > DL > P

• A (Accounts). You should never assign an individual user to a folder/printer. An account belongs to a person, not a permission set.
• G (Global Groups). This is your Identity layer. You should group your users by their job role (e.g., GG_Accountants, GG_IT_Engineers).
• DL (Domain Local Groups). This is your Resource layer. You create a group on the server or application itself that represents the “Access” needed (e.g., DL_PayrollFolder_ReadWrite). This is where you actually define the “Lock”.
• P (Permissions). You can take DL group and apply the specific access (Read, Write, Modify, Full Control) to the folder/resource.

Here is an example:

• User: John
• Global Group: Finance_Users
• Domain Local Group: FileServer_Finance_Read
• Permission: Read access to \fileserver\Finance

As a result, John gets access through group nesting, not directly.

AGUDLP Model (Multi-Domain)

In case your environment has multiple domains, you should use this extended model: A > G > U > DL > P

U (Universal Groups). It takes the Global Groups from different domains and combines them into one single logical unit

Here is an example:

• Global Groups: HR_Users_US, HR_Users_EU
• Universal Group: HR_All
• Domain Local: FileServer_HR_Read

There are also local groups. These groups are created in the local Security Accounts Administrator (SAM) database on each computer. The difference from domain groups is that local groups work even if an Active Directory domain controller cannot be contacted.

Common mistakes you should avoid

• assigning permissions directly to users
• adding users directly to Domain Local groups
• using Universal groups for frequently changing memberships

Recommended Naming Convention

You should use prefixes to make group purpose clear:

• GG_ for Global groups (roles)
• DL_ for Domain Local groups (permissions)
• UG_ for Universal groups

As examples, you can use GG_HR_Users, DL_FileServer_HR_Read, or UG_HR_Global.

Hint. AD groups can be members of other groups. This is called nested groups. Nested groups are a useful way to manage in AD based on business roles and functions.

Changing the Scope or Type of AD group

You can change the Scope or Type of the AD group. But there are some conditions:

• You can convert a Global Security Group to a Universal if the group is not part of another Global group;
• You can convert a Local domain group to a Universal one if it does not contain another local domain group as a member;
• A Universal group can be converted to a Local domain group without any restrictions;
• A Universal group can be transformed into a Global one if it does not include another universal group as a member.

AGDLP vs Modern Cloud Access Model

While AGDLP and AGUDLP are still widely used in on-prem AD environments, modern enterprises increasingly move toward role-based access control (RBAC) in Microsoft Entra ID.

Keep in mind that in cloud environments, access is often assigned using:

• Entra ID roles
• Group-based licensing
• App roles (AppRoleAssignments)
• Conditional Access policies

Active Directory Built-in Groups

When you create a new AD domain, several predefined (built-in) security groups are created with a DomainLocal scope. These predefined groups can be used to control access to shared resources and delegate specific administrative permissions on the domain level. The default AD groups are located in a special AD container Builtin.

You can list the predefined AD group using PowerShell:

Get-ADGroup -SearchBase 'CN=Builtin,DC=theitbros,DC=com' -Filter * | Format-Table Name,GroupScope,GroupCategory,SID -AutoSize

Administrators DomainLocal Security S-1-5-32-544
Users DomainLocal Security S-1-5-32-545
Guests DomainLocal Security S-1-5-32-546
Print Operators DomainLocal Security S-1-5-32-550
Backup Operators DomainLocal Security S-1-5-32-551
Replicator DomainLocal Security S-1-5-32-552
Remote Desktop Users DomainLocal Security S-1-5-32-555
Network Configuration Operators DomainLocal Security S-1-5-32-556
Performance Monitor Users DomainLocal Security S-1-5-32-558
Performance Log Users DomainLocal Security S-1-5-32-559
Distributed COM Users DomainLocal Security S-1-5-32-562
IIS_IUSRS DomainLocal Security S-1-5-32-568
Cryptographic Operators DomainLocal Security S-1-5-32-569
Event Log Readers DomainLocal Security S-1-5-32-573
Certificate Service DCOM Access DomainLocal Security S-1-5-32-574
RDS Remote Access Servers DomainLocal Security S-1-5-32-575
RDS Endpoint Servers DomainLocal Security S-1-5-32-576
RDS Management Servers DomainLocal Security S-1-5-32-577
Hyper-V Administrators DomainLocal Security S-1-5-32-578
Access Control Assistance Operators DomainLocal Security S-1-5-32-579
Remote Management Users DomainLocal Security S-1-5-32-580
Server Operators DomainLocal Security S-1-5-32-549
Account Operators DomainLocal Security S-1-5-32-548
Pre-Windows 2000 Compatible Access DomainLocal Security S-1-5-32-554
Incoming Forest Trust Builders DomainLocal Security S-1-5-32-557
Windows Authorization Access Group DomainLocal Security S-1-5-32-560
Terminal Server License Servers DomainLocal Security S-1-5-32-561

There are also some built-in privileged groups in Active Directory such as Domain Admins, Enterprise Admins, DnsAdmins, etc.

Note that in hybrid environments, many privileged operations are now managed through Entra ID roles and PIM rather than only AD built-in groups.

Note. Keep in mind that members of privileged groups (Domain Admins, Enterprise Admins, Schema Admins, etc.) are protected by the AdminSDHolder mechanism. It means that their ACLs are automatically reset every 60 minutes to match the AdminSDHolder template.

How to Create a Group in Active Directory with the ADUC Snap-in

You must be a member of the Account Operators, Domain Admins, or Enterprise Admins group to create, modify, or delete a group in Active Directory. You can also delegate the privileges to manage groups in specific OUs to non-admin users.

The easiest way to create a new group in the AD domain is to use the Active Directory Users and Computers snap-in. Go to the target AD Organizational Unit in which you want to create the group, right-click on it, and select New > Group.

Specify a unique group name, select the group type and scope, and click OK.

In order to add an object to the group members, go to the Members tab and use the Add button to add users, computers, or other groups.

Note that when adding members to a group, searches are performed only for the following types of objects: Users, Groups, and Service Accounts. If you want to add an AD object to the security group (such as a computer or contact), click the Object Types, and check the options Contacts and Computers. You can now select any type of Active Directory object.

You can also add a user to the group by right-clicking on it and selecting the item Add to a group. This is useful if you need to add users to a group in bulk.

Note that on the Member tab, in the properties of any Active Directory user, its Primary Group is specified. Primary group ID was used to support the UNIX POSIX model to control access to resources. In Active Directory, the PrimaryGroupID attribute for a user must be the RID (relative identifier) of the group to which the user is to be associated. By default, all Active Directory users have a PrimaryGroupID of 513 (Domain User group).

Only Global or Universal security groups can be specified as the primary group.

In most cases, you should not change the Primary Group attribute except in special cases related to POSIX applications and Mac clients.

Primary Group and Hybrid Environments (Important Note)

In hybrid environments where AD is synced with Microsoft Entra ID using Entra Connect, the PrimaryGroupID attribute is not used to calculate group membership for syncing purposes.

Entra Connect relies on the standard “member” attribute to determine group membership.

As a result, if a user is assigned a non-standard Primary Group in AD, this membership is not treated as a normal group membership in Entra ID. The user may appear missing from the corresponding group in the cloud view, even though the association still exists at the directory level.

For this reason, in case you are modifying the Primary Group in hybrid environments, it can lead to inconsistent group membership representation between on-premises AD and Microsoft Entra ID.

In modern environments, you should change the Primary Group only in case legacy POSIX/compatibility cases.

Create new security group from Active Directory Administrative Center (dsac.exe)

You can also create new security groups from the graphical Active Directory Administrative Center (dsac.exe). Right-click on the domain name or OU and select New > Group.

Fill in the following mandatory fields:

• Group name.
• Group Scope (Global/Domain local/Universal).
• Group type (Security/Distribution).

Here you can also set a description for the group, enable/disable the Protect from accidental deletion option, add users to the group, etc.

Click OK to create the group.

To remove a user from a group, search for the group by name using Global Search, and open its properties. Go to the Members tab, select the user you want to remove and click the Remove button. Click OK to save your changes.

Create and Modify Active Directory Group Using PowerShell

To create Active Directory groups, use the PowerShell New-ADGroup cmdlet from the Active Directory for Windows PowerShell module.

The type of the group (Security or Distribution) is specified using the -GroupCategory argument. The scope of the group is specified using the -GroupScope parameter (valid values: DomainLocal, Global, or Universal).

You can use the command to create a new global distribution group in the target OU:

New-ADGroup -Path "OU=Groups,OU=Brasil,DC=theitbros,DC=com" -Name "BrasilUsers" -GroupScope Global -GroupCategory Distribution

To find all the distribution groups in your domain, use the following cmdlet:

Get-ADGroup -Filter 'groupcategory -eq "Distribution"'

Use the following command to create a new security group:

New-ADGroup -Name RemoteAccessUsers -GroupScope Universal -GroupCategory Security -Path "OU=Groups,OU=USA,DC=theitbros,DC=com"

You can change Active Directory group attributes using the Set-ADGroup cmdlet. For example, you want to add a description to the security group you have created earlier:

Set-ADGroup RemoteAccessUsers -Description "Users that can access corporate network over DirectAccess and VPN server"

In addition, you can use the Set-ADGroup cmdlet to change the scope of the group. For example, use the following command to convert the Global Distribution group to the Universal Security group type:

Get-AdGroup RemoteAccessUsers | Set-ADGroup -GroupScope Universal -GroupCategory Security

Now you can add users to this group using Add-ADGroupMember cmdlet:

Add-ADGroupMember RemoteAccessUsers -Members user1,user2,user3

To remove a user from an AD group, use the Remove-ADGroupMember cmdlet:

Remove-ADGroupMember -Identity RemoteAccessUsers  -Members user1, user2

Confirm the user membership removal by pressing Y > Enter.

To completely remove an Active Directory group, run:

Remove-ADGroup -Identity RemoteAccessUsers

When you delete a group, you will be prompted to confirm the deletion. To disable removal confirmation, add the Confirm parameter:

Remove-ADGroup -Identity RemoteAccessUsers  -Confirm:$false

To get all the information about the specified group, use the Get-ADGroup cmdlet:

Get-ADGroup "Domain Admins"

DistinguishedName : CN=Domain Admins,CN=Users,DC=theitbros,DC=com
GroupCategory : Security
GroupScope : Global
Name : Domain Admins
ObjectClass : group
ObjectGUID : f04fbf5d-c917-43fb-9235-b214f6ea4156
SamAccountName : Domain Admins
SID : S-1-5-21-3243688314-1360023605-3291231821-512

You can calculate the total number of users in the group:

(Get-ADGroupMember -Identity 'Domain Admins').Count

You can list (export) members of the Active Directory group using the Get-ADGroupMember cmdlet.

To list the AD groups that the user account belongs to, run the command:

Get-ADUser jbrion -properties memberof | select memberof -expandproperty memberof

Time-based group membership

Time-based group membership also known as expiring links. It requires a Windows Server 2016 or later forest functional level and the Privileged Access Management (PAM) Feature to be enabled in the forest. This feature allows you to assign temporary group membership with a specified Time to Live (TTL). The temporary membership expires automatically when the TTL is reached.

Temporarily add user to group using PowerShell

You can temporarily add a user to a group using PowerShell. For example, you want to add a user to a security group for only 2 days to assign temporary permissions. Run the following PowerShell command:

Note. The Privileged Access Management Feature is not enabled automatically. It must be enabled at the forest level before you can use expiring group memberships.

Add-ADGroupMember -Identity g_CA_Sales -Members b.jackson -MemberTimeToLive (New-TimeSpan -Days 2)

After two days, the user account will be automatically removed from the group. To view the remaining time (in seconds) that a user will remain in a group:

Get-ADGroup g_CA_Sales -Property member -ShowMemberTimeToLive

Group-based licensing and access governance

Note that in Microsoft Entra ID, groups are also used for:

• License assignment (Microsoft 365 licensing)
• Access packages (Entitlement Management)
• Privileged Identity Management (PIM) role activation

This allows enterprises to automate identity lifecycle management and reduce manual administration.