What are Active Directory Groups?
Active Directory groups are methods for collecting users, contacts, computers, and even other groups’ objects within Active Directory so that you can manage the objects in the group as a single unit.
Objects in Active Directory Groups
Objects that belong to a particular group are referred to as group members. Using groups can simplify the permission administration by assigning a set of permissions to a security group once, rather than assigning permissions and rights to each group member individually.
Active Directory has several built-in groups that you can use to assign users or computers too, so they have the permissions they need to get their jobs done. You can also create your own groups and assign those groups various levels of access and permissions. Active Directory enables administrators to manage all objects and services from one centralized location rather than having to go from computer to computer to get things done. Many other programs can tie into Active Directory to manage user accounts and other objects as well.
Table Of Contents
- Uses of Active Directory Groups
- Types of Active Directory Groups
- Universal vs Global vs Domain Local Groups
- Uses of Universal Groups
- Uses of Global Groups
- Uses of Domain Local Groups
- Change of Group Scope in Active Directory
- Conditions to Change Group Scopes in Active Directory
- Active Directory Group Management Best Practices
- Built-in Active Directory Security Groups
- Uses Of Built-in/Default Active Directory Groups
- Changing Permissions On Built-in Administrator Groups
- Creating a Group with ADUC
- Creating a Group with ADAC
- Creating a Group Using Command Prompt
- Creating a Group Using Windows PowerShell
- FAQs
Uses of Active Directory Groups
Simplify Administration
To simplify administration by assigning share (resource) permission to groups rather than individual users in the active directory. When you assign permission to a group, all its members have the same access to the resource
Delegate Control
To delegate the control by assigning user rights to a group using Group Policies. In the future, you can add new members to the group who need the permission granted by this group.
Create Distribution List
One of the major use of groups with in active directory service is to create email distribution lists.
Types of Active Directory Groups
As we discussed above, Active Directory groups are a collection of Active Directory objects. The group can include users, computers, other groups, and other AD objects. The administrator manages the group as a single object.
In Windows, there are seven types of active directory groups that involves two domain group types with three scopes in each and a local security group as follows:
Domain Groups Types
- Security Groups
- Distribution Groups
Group Scopes in Active Directory
- Universal groups (UG)
- Global groups (GG)
- Domain local groups (DLG)
Local Security Group
–
We were demonstrating how to manage the creation and automation of Active Directory security groups and distribution lists before we realized that we had no idea what the differences were between the types groups: security and distribution groups, and the group scopes: universal groups (UG), global groups (GG), and domain local groups (DLG).
With a little work, we dug out enough info for this cheat sheet on Active Directory groups:
Domain Groups
The two Domain Groups consist of Security groups and Distribution groups and within these two groups we have three group scopes which will be discussed next. When creating a new Active Directory group, you will need to choose between a Security and Distribution group as also choose the group scope. You use distribution groups to create e-mail distribution lists and security groups to assign permissions to shared resources.
-
Security Groups
Used with care, security groups provide an efficient way to assign access to resources on your network. Security groups have two main functions:
- Assign User Rights
- Grant Permissions to Resources
Assign User Rights
IT administrators can assign user rights to a security group that determines what group members can do. For instance, if a user is added to the Backup Operations security group, he/she will have the ability to restore the files and directories located on every domain controller (DC) in the domain. This is because, by default, the user rights pertaining to ‘Backup files and directories’ and ‘Restore files and directories’ are assigned to the Backup Operations group, and all group members inherit these rights.
Grant Permissions to Resources
By granting permissions to security groups on shared resources, IT administrators allow group members to access the company’s resources, like shared printers, secured folders, and financial records. For example, the Human Resources security group will have access to employees’ data, which is confidential and cannot be shared with other departments.
Security groups can also be used as a distribution group in Exchange. These are known as security-enabled distribution groups or mail-enabled security groups.
Read More: Active Directory Security Groups Uses & Best Practices
-
Distribution Groups
Distribution groups are designed to combine users together so that you can send e-mails (via Microsoft Exchange Server) collectively to a group rather than individually to each user in the group. Distribution groups are designed to be used for e-mail specifically and cannot be granted Windows permissions. The terms “distribution groups” and “distribution lists” tend to be used interchangeably, particularly if you work with Microsoft Exchange Server administrators. Don’t let this trip you up!
Read more: Distribution Group or Mail-enabled Security Group?
Group Scopes in Active Directory
When setting up a security or distribution group you will also need to choose a scope for that group so Active Directory knows how to assign the permissions to the resources that group is allowed to access. Groups, whether security groups or distribution groups, are defined by a definition that identifies the scope to which the group is applied in a domain or forest.
There are three group scopes in active directory: universal, global, and domain local.
-
Universal Group
It can contain users and groups (global and universal) from any domain in the forest. Universal groups do not care about trust. Universal groups can be a member of domain local groups or other universal groups but NOT global groups.
-
Global Group
It can contain users, computers, and groups from same domain but NOT universal groups. It can be a member of global groups of the same domain, domain local groups or universal groups of any domain in the forest or trusted domains.
-
Domain Local Group
It can contain users, computers, global groups, and universal groups from any domain in the forest and any trusted domain, and domain local groups from the same domain. It can be a member of any domain local group in the same domain.
The short answer is that domain local groups are the only groups that can have members from outside the forest. And use global groups if you have trust, universal groups if you don’t care about trust. There are also local groups. These groups are created in the local Security Accounts Administrator (SAM) database on the specific computer. The difference from domain groups: local groups work even if the domain controllers cannot be contacted.
Universal Groups vs Domain Local Groups vs Global Groups
Following differences between Group Scopes are generally defined, but they may be subjective to each use case.
| Domain Local Groups | Global Groups | Universal Groups | |
|---|---|---|---|
| Memberships | Can contain users from any domain | Can contain users from the same domain | Can contain users from any domain within the forest where this Universal Group resides |
| Can contain Global groups from any domain | Can contain Global groups from the same domain | Can contain Global groups from any domain within the forest where this Universal group resides | |
| Can contain Universal groups from any domain | Can contain Universal groups from any domain within the forest where this Universal group resides | ||
| Can contain Domain Local groups but only from the same domain | |||
| Permissions | Permissions can only be assigned to members inside the domain | Permissions can be assigned in any domain | Permissions can be assigned in any domain or forest |
| Forest-Wide Replication | Domain Local groups do not trigger forest-wide replication on any change in group memberships | Global groups don’t trigger forest-wide replication on any change in group memberships | User accounts should not be added directly into a Universal group, as it triggers forest-wide replication on each addition and removal |
| Scope | Can be perceived as resource groups to provide access to the domain | Can be perceived as account groups primarily used to group users in the same domain | Can be perceived as both resource and account groups |
| MemberOf | Cannot be made a member of Global groups | Can be made members of Domain Local groups to share the respective access to resources | Can be a member of any group type in the forest. |
| Converted Into | Can be converted to a Universal group (if no other Domain Local group exists as a member) | Can be converted to a Universal group (if the group is not a member of any other Global group) | Can be converted to a Domain Local group or a Global group (if no other Universal groups exist as members) |
Uses of Universal Groups
Group Consolidation Spanning Across Domains
Universal Scope groups are used for consolidating groups across domains. The best practices recommended to consolidate groups are as follows:
- User accounts are added into groups with global scope
- Same active directory groups are then nested under universal scope groups
Using the above two steps prevents any change in groups with universal scope even with the change in users’ memberships within groups with global scope. Moreover, adding or removing a user in a group triggers replication at different levels depending upon the type of group. For example:
- Adding or Removing a User in a Universal group triggers replication across the forest-wide.
- Adding or Removing a User in Global Group leads to replication at the domain level only
Use Case for Universal Groups
-
Network with Two Domains – (UG with Two GG as Members)
Consider there are two domains are in a network Asia & United States. A universal group named UMarketing which in turn has two global groups, Asia\GLMarketing and US/GLMarketing as its members belong to each domain. Replication will not trigger in Universal Group UMarketing due to any change in memberships of individual Global Scope Groups Asia\GLMarketing and US/GLMarketing.
However, linked-value replication (associated with a change in Domain linked attribute) leads towards replicating the change in attributes of universal groups (modified membership) only into global catalogue server, provided that the windows server 2003 or higher is a forest’s functional level.
Uses of Global Groups
-
Arranging User Objects with Similar Activities
User Objects within Active Directory can be arranged in Global Groups based on similarity in job activities (similar attribute) such as Accountants in Accounting Department. Criteria for organizing users can involve departments, positions, and job activities.
-
Managing Objects Requiring Daily Maintenance
Global groups are employed in active directory to manage user accounts and computer accounts requiring daily Maintenance since changing such accounts in global groups would prevent any replication to global catalogue.
-
Consolidating Rights & Permissions Across Domains
Global groups are employed in active directory to manage user accounts and computer accounts requiring daily Maintenance since changing such accounts in global groups would prevent any replication to the global catalogue.
Use Case for Global Groups
-
Network with Two Domains – (GG with Permission in a Domain)
Consider a network with two domains Asia and United States. In Asia, we have a group with global scope USA/GGMarketing. Considering GGMarketing groups have certain rights and permission associated with them in the USA domain and we want to provide user members in those groups with the same rights and permission in Europe as well. To achieve that, we will create GGMarketing in the Europe domain as well. Thus, applying such a group in the European domain is an example of logical groups management.
When to Avoid using Global Groups?
The use of global groups for assigning access to resources that are domain-specific is not recommended since global groups are visible across the forest. For this use case, domain local groups are recommended to use.
Uses of Domain Local Groups
Uses of domain local groups involve:
- Assigning Access to Permissions
- Making any Changes in the Access List of a Resource
Domain local groups would also include other groups to enable other members to get permissions that the group has assigned.
Use Cases for Domain Local Group
Managing Resource Permissions
Domain local scope groups enable IT in defining and managing access to resources in a single domain. All user accounts can be added to a list of resource permissions. Let’s consider different use cases.
-
Assigning Access to an Existing Printer
IT Admins are interested in assigning access to all given users to a particular resource such as a specific printer in the organization.
-
Assigning Access to Same Users to a New Printer
If IT admins are interested in assigning access to the same users to a new printer in the organization, these given users will be required to be added to the list of new printer’s permissions again.
Such access management of resources can be managed with adequate planning by creating active directory groups with a domain local scope and giving it permission to access a resource such as a printer. So, adding five user objects in an active directory group with a global scope, and then adding that group to domain local scope groups, with assigned permissions of domain local scope for accessing new printer, would enable users to access it. Hence, access to a new resource (printer) is automatically assigned to members of an active directory group.
Changing Group Scope in Active Directory Groups
You can change the scope or type of directory groups, but there are several conditions as follows:
Conditions to Change Group Scope in Active Directory
Convert Global Security Group to Universal Group
You can convert a global security group to a universal if the group is not part of another global group.
Convert Domain Local Group to Universal Group
You can convert a local domain group to a universal group if another local domain group is not added to list of its members.
Convert Universal Group to Domain Local Group
A universal group can be converted to a local domain group without any restrictions.
Convert Universal Group to Global Group
A universal group can be transformed into a global if it doesn’t contain another universal group as a member.
Active Directory groups are integral for managing user access to resources and distributing information. More importantly, effectively managing Azure AD and Active Directory groups is the most proactive security measure IT can put in place. Yet, Azure AD and Active Directory groups are rarely given a second look after they’re created, despite their impact on security, information distribution, and permissions management.
Active Directory Groups Management Best Practices
Imanami has been championing Active Directory groups management for thousands of customers for over 20 years and here are the seven best practices for Active Directory group management based on that experience:
- Always Know What You Have
- Use Standards
- Establish Group Ownership
- Implement Change Accountability
- Periodically Certify
- Automate Group Processes
- Delete Unnecessary Groups
As you consider implementing these best practices, it’s important to view them as a method both to clean up what you currently have and to manage your existing and newly created groups as you move forward.
#1: Always Know What You Have
To get control of your Active Directory groups, reorganize them, and establish a process for continual management, you must be aware of what you have in your directory. For that purpose, you can begin with inventorying the Active Directory groups along with focusing on the most neglected ones within your directory, which are likely to include the following:
- Groups With No Member
- Groups With No Owner
- Groups With No Recent Changes
- Groups that Appear To Be Duplicative (Via Either Name Or Membership)
- Groups that Are Nested Within Other Groups
Do it the easy way: GroupID by Imanami is equipped with features that enable you to stay informed on the current state of your groups. These features include:
- Group Reporting
- Group Info Retrieval
- Similar Groups’ Identification
Once you have visibility into the current state of your Active Directory and Azure AD groups, you can follow the remaining best practices to further organize, configure, use, and manage your groups.
#2: Use Standards
After uncovering the Active Directory groups, you’ll probably discover a few groups with mysterious or cryptic names, such as HQ-RTAudBkPr. Any idea what they are or what the name implies?
You wouldn’t be alone. Most IT professionals will have several of these — with barely any clue as to why they exist. Naming certainly is important, but it’s not the only thing that needs to be standardized as part of proper group management. Here are a few more standards you should consider when creating and organizing groups:
- Group Scope in Active Directory — Group Scope in Active Directory impacts replication, members, and membership within other groups.
- Group Type — Security and distribution groups serve very different purposes but can overlap in functionality (as in the case of a mail-enabled security group).
- Group Description — You have the Description and Notes fields for groups. Use them.
- Object Placement — Just as you use folder structures in a file system to help you quickly identify what a folder contains, take advantage of organizational units in the directory for both documentation and delegation purposes.
- Use of Nesting Hierarchies — Group Nesting isn’t bad if it’s done properly, especially within distribution groups.
GroupID is built to easily implement standards in group names, scope, type, and descriptions.
#3: Establish Group Ownership
IT should be the delegator, not the owner of groups. From a best practice perspective, ownership is much more than merely populating the “Managed By” field with the Domain Admins group. It’s about looking beyond group creation and the process of initially adding members and assigning permissions. So, to create an Active Directory group, IT should designate one or more individuals within the organization as its owners, responsible for its membership, assigned permissions, and even its existence.
Read More: Active Directory Groups Multiple Owners Use Cases
This would not only reduce the workload on IT but also put ownership in the hands of:
- Managers
- Department Heads
- Project Leaders
In short, roles that are better positioned to decide whether the group has the right members and whether the assigned permissions are appropriate for the intended tasks. The goal is to empower end-users within the organization who are closest to the actual purpose the group serves.
#4: Implement Change Accountability
As a routine practice, users submit helpdesk tickets for getting added to various Active Directory groups, it’s often the case that these requests just ‘happen’, leaving you with little or no accountability. To help re-establish some accountability, you should change the process of how groups are modified so that changes would require the approval of the group owner or a person of authority before they are committed to the directory.
Tracking should include changes to:
- Group Attributes
- Membership
- Group Nesting
- Assignment of Permissions
- Group Life Cycle Through to Deletion
You can employ several means to account for changes to groups.
Log Changes:
Track all changes made to groups, from creation to deletion. GroupID Automate and Self-Service can log and maintain the history for each group, that you can view in group properties. Users who make changes to a group are also encouraged to add comments against changes, that could include a reason to justify the change.
Define Workflows:
Do you have processes in place to verify any changes made to objects within Active Directory and Azure AD? If not, then think about it now. Implement workflows to seek approval for the create, edit, and delete events for group objects in the directory.
Set a Group Security Type:
Using GroupID Automate and Self-Service, you can assign a security type to groups, based on their level of criticality. Security types are:
- Private – closed membership
- Semi-Private – users can send join and leave requests to group owners
- Public – open to all users
#5: Periodically Certify
Even if you have implemented accountability into your group changes, you should periodically perform an audit. For Active Directory groups, this audit should take the form of group attestation, where group owners must verify the group’s attributes, members, and permissions.
In addition to certifying that a group’s members and permissions are correct, you also need to periodically have the group’s owner attest to the need for the group’s existence.
For example, you might have a group that exists to provide access to a CRM application, but once you move to a cloud-based CRM system, you no longer need that group. Without making changes to your current model, that group is likely to remain in your directory for years to come. However, by establishing attestation, the application owner (who participated in the creation of the group and was responsible for it) can make the appropriate decision and inform IT that the group is no longer necessary.
#6: Automate Group Processes
IT teams and helpdesk bear the burden of manually managing active directory groups-related tasks, such as:
- Adding And Removing Group Members
- Updating Group Attributes
- Deleting Groups
As such, it is not surprising that human error remains the driving force behind a sizeable chunk of cybersecurity problems.
As much caution as you may exercise, human error is inevitable in manual processes. A pragmatic approach to tackle the problem lies in automation, and directory group management is no exception. Fully or partially automating group-related processes, such as group creation, memberships, group expiry, and deletion, is certainly the right course.
#7: Delete Unnecessary Active Directory Groups
This is probably the least observed practice with groups. Why? If you’ve never performed any of the best practices noted above, you’ve never been in a situation where you were 100% sure that a group could be deleted. Had you implemented group attestation, you could have spoken with authority on the existence of every group. It’s simple – if a group has failed attestation by its owner, it’s time to eliminate that group. Manually deleting such a group is okay but it’s not the ideal approach to directory hygiene.
Automating the process of deleting expired groups is an easy way to achieve this goal. It is reasonable to assume that after a grace period, groups that were not validated through the attestation process and thereby became expired, should be deleted.
Using expiring groups is a much safer and more secure way of identifying and deleting groups that cannot be attested to. (If needed, an expired group can be renewed quickly.) GroupID puts this approach into practice through its Group Life Cycle policy.
Putting Best Practices into Practice
7 Best Practices for Managing Active Directory & Azure AD Groups.
As you implement these best practices, it will become evident that group life cycle management requires some form of automation. PowerShell can help temporarily, but it can become too complicated.
G
Built-in Active Directory Security Groups
Default or Built-In Active Directory security groups are automatically created on the servers running Windows OS. The following are the well-known default security groups:
- Administrators
- Backup Operators
- Remote Desktop Users
There are some additional groups that are formed in Built-In and Users containers of a domain, such as:
- Domain Admins
- Enterprise Admins
- Schema Admins
Below each of these well-known default security groups are defined:
Administrators Group
Administrators, a default active directory group has control over all domain controllers and associated data. Such groups can modify memberships of other Active Directory default groups such as Domain Admins, Enterprise Admins, and Schema Admins.
Backup Operators
Backup operators are primarily responsible for backing up and restoring all files on a computer, irrespective of permissions concerning those files. Such active directory groups can’t be:
- Moved
- Renamed
- Destroyed
Backup operators can also backup and restore domain controllers. Memberships of Backup Operators Active Directory groups can be changed by the following ad group types:
- Default Service Administrators
- Domain Admins in the Domain
- Enterprise Admins
Members of the Backup operator’s group do not have the ability to:
- Modify server settings
- Change directory configuration
However, such group members do have the ability to replace files such as OS files on DCs.
Remote Desktop Users
Remote Desktop Users refers to a group designated to provide users and groups rights to initiate a remote session to an RD session host server. This group can’t be:
- Moved
- Renamed
- Deleted
Remote Desktop Users appear as SID unless the following two conditions are met:
- DC is identified as a principal domain.
- FSMO role is assigned to it.
Domain Admins
This group is added to the domain’s Administrators group. As a result, it inherits all the Administrators group’s capabilities. It’s also assigned to the local Administrators group of each domain member computer by default, allowing Domain Admins full control over all domain computers.
Enterprise Admins
Enterprise admins Active Directory group has full access to all domain controllers and it is a member of the Administrators group. Moreover, it owns a directory configuration partition along with control for domain naming context.
Schema Admins
This default Active Directory group controls and owns schema of Active Directory.
Uses of Built-In/Default Active Directory Groups
Such pre-defined groups in Active Directory can be used in the following two ways:
- Managing Access to Resources
- Allocate Administrative Responsibilities
In default security groups within an Active Directory domain, users’ accounts are assigned certain privileges enabling them to follow perform tasks:
- Sign-on to the local system
- Gain network access to specific files and folders
- Backup such files and directories
EXAMPLE: An example of such privileged access would be a group named Back up Operators, which would have access to backup files and folders across domain controllers within a specific domain. Hence, when you add a user to a group, the user inherits all the group’s user rights as well as all the group’s permissions for any shared resources.
Default groups can be found in the built-in container and the user’s container in Active Directory Users and Computers in the following way:
- Groups defined with Domain Local Scope are found in the Built-in container.
- Groups defined with Global scope and Domain Local scope are included in the Users OU (Organizational Unit).
Movements of such groups within these containers are only limited to other groups or OUs (Organizational Units) within domains.
Changing Permissions on Built-In Administrator Groups
Objects within Active Directory employ security descriptors for controlling access. Security descriptors are primarily used to store information regarding permissions. A background process is initiated periodically to apply a security descriptor to protect groups such as administrative groups along with members within those groups. Any unauthorized attempt to edit such descriptors with respect to groups will be overwritten.
The AdminSDHolder object contains the security descriptor. If we are looking to change the permission on any of the administrator’s groups, it is considered important that we change the security descriptors on AdminSDHolder. However, it is also essential to be cautious while making those changes since we are modifying settings across protected administrators’ accounts.
Creating a Group with ADUC
- Active Directory Users and Computers can be opened by following options:
- Select Run, after right-clicking on Start and Type dsa.msc in the windows search bar, followed by clicking on “OK”.
- Navigate to Server Manager, select Tools, and then click on Active Directory Users and Computers from the menu.
- Navigate to the OU or Container where you want to create the group. Decided the OU or Container where a new group is to be created. Right Click on OU, Select the “New” and Click “Group”.
Specify the below values in New Object – Group Menu:
- Group Name
- Group Scope or Proceed with Accepting Default Scope
- Group Type or Proceed with Accepting the Default Group Type
Click OK to create the group
Creating a Group with ADAC
Following option can be utilized to open ADAC (Active Directory Administration Centre):
Active Directory Users and Computers can be opened by following options:
- Select Run, after right-clicking on Start and Type dsac.msc in the windows search bar, followed by clicking on “OK”.
- Navigate to Server Manager, select Tools, and then click on Active Directory Administration Centre from the menu.
Select New -> Group from the menu, after you Right Click on the Domain Name.
Specify the below values in New Object – Group Menu:
- Group Name
- Group Scope or Proceed with Accepting Default Scope
- Group Type or Proceed with Accepting the Default Group Type
Click OK to create the group
Creating a Group Using Command Prompt
Cmd.exe command can be used to create groups in Active Directory. Following the example of command use to create groups in active directory:
dsadd.exe group "CN=ITGroup,OU=OfficeCorp,DC=office,DC=local"
Creating a Group Using Windows PowerShell
Powershell cmdlets can be used to create groups in Powershell. Following is the examples of Powershell Command lets used to create groups in Active Directory:
Import-Module ActiveDirectory
New-ADGroup -GroupCategory Security -GroupScope Global -Name "HelpDesk" -Path "OU=OfficeCorp,DC=office,DC=local" -SamAccountName "ITGroup
Read more: Active Directory & Azure AD Groups Management
FAQs on Group Scopes in Active Directory
What are group scopes in Active Directory?
Group scopes refers to the extent to which a group can be used with in an active directory domain or a forest
How many types of group scopes are there in Active Directory?
Following are three types of group scopes within active directory:
- Universal
- Global
- Domain Local
What are primary differences between universal, global and domain local group scopes in active directory?
GroupID by Imanami offers a suite of solutions that empowers IT professionals to manage groups, users, and entitlements effectively and automatically. Learn more about the suite of solutions under GroupID.
Jonathan Blackwell
View ProfileSince 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.
Hi Edward, I think your description of the difference between types of AD groups is accurate; but it is incomplete in that it does not explain why there would be different types of groups anyway, or what you should use them for. Let’s try a short indication: To give users access to resources/objects, you could in principle put user accounts directly into the ACL’s of the objects (files, printers,…) they need to use. Because of the number of users and objects in any non-trivial organization this would lead to an administrative nightmare. That is why security groups were introduced, as… Read more »
Jacque, that is excellent, thank you.
Good.. i got sme ideas
Well.. i found that global group cannot be a member of global group of the same domain
excellent …. you explained the difference between those three Active Directory groups very well i found your article short and easy to understand thank you
Understood clearly, its good article.