How-to: Understand the different types of Active Directory group.

This page describes the different types of Active Directory group, group scope and nesting permissions within and across WANS and domains.

Types of Groups

Security groups are used to control access to resources.
Security groups can also be used as email distribution lists.

Distribution groups can be used only for email distribution lists, or simple administrative groupings.
Distribution groups cannot be used for access control because they are not "security enabled."

Group Scope

Assuming a Native-mode enterprise.

Universal groups
Provide a simple 'does everything' group suitable mainly for small networks. Typically, organizations using WANs should use Universal groups only for relatively static groups in which memberships change rarely. Changes in membership will impose global catalog replication throughout an entire enterprise. Value: 8 (0x00000008)

Global groups
Provide domain-centric membership, place all user accounts into Global groups. Global groups can be nested within other Global groups, this can be particularly useful when delegating OU administrative functionality.

It can be useful to give each Global group a name that is meaningful to the staff involved, i.e. matching the name of a Team or a Project, particularly if the group is also to be used as an email distribution list. Value: 2 (0x00000002)

Domain Local groups
Used for the direct assignment of access permissions on files, printer queues, and other such resources.

It can be useful to give each Domain Local group a name that is meaningful to the IT administrators e.g. if a group assigns rights to a shared folder on a specific server then the group name might include a prefix or suffix indicating the server name. Value: 4 (0x00000004)

Local groups
Stored on the local SAM (Local Computer) use for security settings that apply just to this one machine.
Local groups will work even if the network becomes unavailable, e.g. during a disaster recovery exercise.

The numeric values can be used to build LDAP filters to query Active Directory.

Other Group-Type attribute values:
A group that is created by the system: 1 (0x00000001)
An APP_BASIC group for Windows Server Authorization Manager: 16 (0x00000010)
An APP_QUERY group for Windows Server Authorization Manager: 32 (0x00000020)
A security group. If this flag is not set, then the group is a distribution group 2147483648 (0x80000000)

Best Practice

Place users in Global groups, nest those inside Domain Local groups which in turn are used to apply permissions, as shown below. This will also maximise performance in a multi-domain forest.

Groups - Global Domain local and Universal.

Group membership is evaluated when a user logs on to a domain. To be sure that any membership changes have taken effect, ask the users to log-off. In contrast ACL changes or permissions applied directly to User accounts will take place immediately.
Granting permissions using a group from a different domain is only possible where a trust relationship exists between the domains.

Single Domains

In a single domain the scope of groups will have no effect on performance. Global groups can be used for everything but you can nest groups and use Domain Local Groups to simplify management.

The fact that you cannot add a Domain Local group to a Global group is very useful to enforce the correct inheritance of rights. A common mistake is adding group permissions the wrong way around. e.g. a resource group (such as one for color printers) is added to an organisational group (such as the personnel dept) if at a later date you add someone else to the colour printers group then they will also be able to read all the personnel files.

If all organisational groups are Global and resource groups are Domain Local then it is not possible to add group permissions the wrong way around. Within a single domain individual User accounts can join either type of group, so in the above example if one extra user needed access to the printers they could still be added directly to the Domain Local colour printer group.

Separating People and Resources

It is tempting to use the same groups to hold users and also apply resource permissions but this seemingly simple setup will involve more effort to maintain.

For example, you have a finance department with 25 accountants and clerks, they need access to the Crest system, they also need editor permissions on the intranet and they need access to all the shared Account_Balances spreadsheets.

A common way to deal with this is to create 3 groups and add the 25 people to each:

    25       25           25

The extra work starts when someone changes job or a new hire arrives, now someone has to remember and sort out which groups each of these people needs to be added to or removed from.

The better way of managing this, is to still create the 3 groups as before but also create a group called Accounting, put the 25 people into the Accounting group, and make all the resources available to the group rather than to individuals.

        [ACCOUNTING Group]

Now when a new hire arrives we add them to the accounting group and they will automatically get everything they need. Similarly when someone changes job we remove them from the accounting group and add them to a different group appropriate to their new role. Also note that this arrangement only requires 28 permissions to be set instead of 75.

Separating people and resources also makes it easy to temporarily remove access e.g. during maintenance downtime. In the above example you could just remove the Accounting group from the res_Crest group. This is much easier than having to either remove (and then later accurately replace) a bunch of individual user accounts, or having to edit the actual permissions applied to files/printers/databases.

Compare how many resource permissions are being applied in the two diagrams below:

Nested Groups

With a flat permission structure there are fewer groups to maintain.
With separate groups for users and resources, there are fewer permissions to manage (the arrows in the diagram above).

Nesting one Group within another with a different scope

Rules that govern when a group can be added to another group (same domain):

Group nesting

Rules that govern when a group can be added to another group (different domain):

Naming conventions

Active directory does allow a wide range of punctuation and spaces in group names, but to allow easy scripting stick to alphanumerics, dash and underscore, so Sales-Directors or SalesDirectors rather than "Sales Directors".

For those Global Groups which are likely to be requested by end users, it can be useful to assign a standard prefix to indicate that it is a Group/Team and not a User account, Mailbox or something else. So G-Sales-Directors, T-Sales-Managers etc.
This will also prevent any possibility of naming clashes with default/built-in groups.

Members - who can join each type of group:

Group Scope Location Local Users can join? Domain Users can join? User accounts from another domain? Local Computer accounts Domain Computer accounts Computer accounts from another domain Machine Local groups can join? Domain Local groups can join? Global groups can join? Universal groups can join?
Machine Local Stored in local sam database Yes Yes   No No   No Yes Yes Yes
Domain Local Stored in AD No Yes Yes No Yes Yes No Yes
(same domain)
Yes Yes
Global Stored in AD No Yes No No Yes No No No Yes
(same domain)
Universal Stored in AD No Yes Yes No Yes Yes No No Yes Yes

Machine local groups cannot become members of any other group, but all domain groups can become members of a Machine Local group.

Resources that a group can grant access to:

Group Scope Location Can act as distribution list? File Permissions local machine File Permissions Domain File Server File/Printer SHARE permissions Can be Mail enabled Can use to assign Mailbox permissions Permissions on Active Directory objects
Machine Local Stored in local sam database No Yes No Yes
(same machine only)
No No No
Domain Local Stored in AD Yes Yes Yes Yes Yes Yes Yes*
Global Stored in AD Yes Yes Yes* Yes* Yes Yes Yes
Universal Stored in AD Yes Yes Yes* Yes* Yes Yes Yes

* Possible but not recommended by Microsoft.

Admin rights

To modify groups in AD, you must be a member of the Account Operators group, the Domain Admins group, or the Enterprise Admins group, or you must have been delegated the appropriate authority.

“In the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed” ~ Charles Darwin

Related commands

NET localgroup / NET localgroup /domain / NET group /domain - Create new groups.
How-to: Built-in Groups - Built-In Users and Security Groups.
How-to: circular.ps1 - Script to find circular nested AD groups.
The Golden Rules of Permissions Administration (pt2) -
ServerFault - Performance impact of AD Universal groups assignment. - Naming conventions in Active Directory.
Scripting Guy! Blog - PowerShell script to remediate pre 2003 AD groups that don’t support linked-value replication.
Q231273 - Group Type and Scope Usage.
Q328889 - Users who are members of more than 1,015 groups may fail logon authentication.
Q271876 - Large Numbers of ACEs in ACLs Impair Directory Service Performance (slow logon times.)
Q909264 - Naming conventions in Active Directory for computers, domains, sites, and OUs.

Copyright © 1999-2023
Some rights reserved