What is an example of an ad group?

Active Directory literally holds the keys to your kingdom. If the right security principles aren’t set up and you are giving excessive permissions to your users, you are leaving yourself exposed to potential security threats.

Within Active Directory, there are numerous security protocols to choose from to implement a policy of least privilege where you are only granting administrative access to those that genuinely need it.

In this blog, we will go through exactly what security groups in Active Directory are, the difference between distribution groups and security groups, what security groups can be used for and exactly how to create one.

What Are Active Directory Groups?

Active Directory, in general, is a program that sorts users into various groups. It is a centralized platform that most enterprises use to manage their computer accounts and to grant access to sensitive data.

An Active Directory group is a group of users that have been given access to certain resources. There are two ways that groups can be given this kind of access; through a Globally Unique Identifier (GUID) or a Security Identifier (SID).

SIDs are mostly used when access wants to be given to specific users, whereas GUIDs are used when grouping together users who all need access to the same resources.

Groups can be created based on individual users that all need access to certain resources, or they can be created based on global groups (such as department), or members of a certain domain.

Types of Active Directory Groups

Active Directory groups are split into two categorizations – Active Directory Security Groups and Active Directory Distribution Groups.

The actual type of group you need will depend on the required function of the group. Distribution groups are simpler in that they would be used if only one-way notifications are required from the central controller. Security groups are more complex, and they are applied when you want to enable users to access and modify data.

Security teams need to pay far more attention to security groups to ensure that permissions do not sprawl out of control and that the risks to the security of your data are mitigated.

Why Should You Use Active Directory Security Groups?

Security groups are vital when it comes to maintaining appropriate access rights to your most sensitive data. The ability to group users into pots to assign levels of permissions is incredibly useful for maintaining a policy of least privilege.

For example, you can use Active Directory security groups to assign high level permissions to members of the board so that they can submit financial information and KPIs for their colleagues. You can also use security groups to assign lower level permissions to new joiners.

Active Directory security groups can also be modified via the AD portal, where users can be moved around or removed completely.

How to Create a Security Group in Active Directory

The following steps apply to Windows 10 and to Windows Server 2016. Please note that you are going to need to be a member of the Domain Administrators group, or have the correct permissions already applied, to be able to create new groups yourself.

1. Open the Active Directory Users and Computers Console.
2. Select the container in which you want to store your group (“Users”, for example).
3. Click “Action” – “New” – “Group”
4. Name your group using the Group name text box and enter a description.
5. Depending on your Active Directory forest infrastructure, choose the correct Group scope: Global or Universal.
6. Click “Security” as the Group type and then click “Ok” to create your security group.

How to Improve the Security of Your Active Directory Security Groups

Many enterprises must deal with joiners, leavers, and movers within their environment. As users change roles, leave the business, or start a new role, their required permissions will be different.

Unfortunately, many enterprises are not communicating effectively enough with the IT and security teams to ensure that permissions and members of security groups are maintained appropriately. In the worst-case scenario, this could potentially lead to insider threats getting their hands on your most sensitive data.

The Lepide Active Directory Auditor (part of Lepide Data Security Platform) will give you the ability to instantly generate a list of users who have been deemed to hold “excessive permissions”, or generate alerts in real time when permissions are changed, so that you can take the required steps to maintain your policy of least privilege.

To see the solution in action, schedule a demo with one of our engineers today or download free trial.

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
  1. Domain Groups
  2. Group Scopes
• Universal vs Global vs Domain Local Groups
• Uses of Universal Groups
  • Use Case for Universal Groups
• Uses of Global Groups
  • Use Case for Global Groups
• Uses of Domain Local Groups
  • Use Cases for 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:

1. Assign User Rights
2. 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 GroupsGlobal GroupsUniversal GroupsMembershipsCan contain users from any domainCan contain users from the same domainCan contain users from any domain within the forest where this Universal Group residesCan contain Global groups from any domainCan contain Global groups from the same domainCan contain Global groups from any domain within the forest where this Universal group residesCan contain Universal groups from any domainCan contain Universal groups from any domain within the forest where this Universal group residesCan contain Domain Local groups but only from the same domainPermissionsPermissions can only be assigned to members inside the domainPermissions can be assigned in any domainPermissions can be assigned in any domain or forestForest-Wide ReplicationDomain Local groups do not trigger forest-wide replication on any change in group membershipsGlobal groups don’t trigger forest-wide replication on any change in group membershipsUser accounts should not be added directly into a Universal group, as it triggers forest-wide replication on each addition and removalScopeCan be perceived as resource groups to provide access to the domainCan be perceived as account groups primarily used to group users in the same domainCan be perceived as both resource and account groupsMemberOfCannot be made a member of Global groupsCan be made members of Domain Local groups to share the respective access to resourcesCan be a member of any group type in the forest.Converted IntoCan 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:

1. User accounts are added into groups with global scope
2. 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:

1. Always Know What You Have
2. Use Standards
3. Establish Group Ownership
4. Implement Change Accountability
5. Periodically Certify
6. Automate Group Processes
7. 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.

DOWNLOAD NOW

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: 

1. DC is identified as a principal domain. 
2. 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

1. 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.
2. 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.

5 12 votes

Article Rating

Jonathan Blackwell

Since 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.

What should an ad group be?

How do I write an ad group?

What is the difference between an ad group and a campaign?

What is a standard ad group?