Group Scope

There are four group scopes:

• Local
• Global
• Domain Local

• Universal

The characteristics that define each scope fall into these categories:

• Replication. Where is the group defined, and to what systems is the group replicated?
• Membership. What types of security principals can the group contain as members? Can the group include security principals from trusted domains?
• Availability. Where can the group be used? Is the group available to add to another group? Is the group available to add to an ACL?
• Trust availability. A trust allows a domain to refer to another domain for user authentication, to include security principals from the other domain as group members, and to assign permissions to security principals in the other domain.

The terminology used can be confusing. If Domain A trusts Domain B, Domain A is the trusting domain and Domain B is the trusted domain. Domain A accepts the credentials of users in Domain B. It forwards requests by Domain B users to authenticate to a domain controller in Domain B, because it trusts the identity store and authentication service of Domain B. Domain A can add Domain B’s security principals to groups and ACLs in Domain A.

Local Groups:

Local groups are truly local. They are created, defined on and only available to the specific computer they were created on. Local groups are created in the local Security Accounts Manager (SAM) database of a domain member computer, whether a workstations or a server.

Replication:

     Because a Local Group only exists on a specific machine, the group and its membership are not replicated to any other system and is only available for any sort of use only on that specific machine.

Membership:

A local group can include as members:

• Any security principals from the domain—users, computers, global groups, or domain local groups.
• Users, computers, and global groups from any domain in the forest.
• Users, computers, and global groups from any trusted domain.
• Universal groups defined in any domain in the forest.

• Availability. A local group has only machine-wide scope. It can be used in ACLs on the local machine only. A local group cannot be a member of any other group.

Local Group Usage Best Practice:

In a workgroup, you can use local groups to manage security of resources on a system. In a domain, however, managing the local groups of individual machines becomes an administrative overhead, and is for the most part unnecessary. It’s not recommended creating custom local groups on domain members. There are very few scenarios in a domain environment that are addressed by using local groups.

In most cases, the Users and Administrators local groups are the only two local groups that you should really be concerned with managing in a domain environment. You can use the Restricted Groups GPO setting to easily manage these two groups across the forest.

Using Restricted Groups
http://www.windowsecurity.com/articles/Using-Restricted-Groups.html

Restricted groups are made for local group management:
http://www.frickelsoft.net/blog/?p=13

Domain local groups (DLGs):

DLGs are used primarily to manage permissions to resources, which means they mostly serve as rule groups. For example, the ACL_Sales Folders_Read group discussed earlier in the lesson would
be created as a domain local group.

Domain local groups have the following characteristics:

• Replication. A domain local group is defined in the domain naming context. The group object and its membership (the member attribute) are replicated to every domain controller in the domain.
• Membership. A domain local group can include as members:
• Any security principals from the domain—users, computers, global groups, or other domain local groups.
• Users, computers, and global groups from any domain in the forest.
• Users, computers, and global groups from any trusted domain.
• Universal groups defined in any domain in the forest.
• Availability. A domain local group can be added to ACLs on any resource on any domain member. Additionally, a domain local group can be a member of other domain local groups, or even machine local groups.

The membership capabilities of a domain local group (the groups to which a domain local group can
belong) are identical to those of local groups, but the replication and availability of the domain local
group make it useful across the entire domain.

DLGs Best Practice:

Domain local groups are well suited for defining business management rules, such as resource access rules, because the group can be applied anywhere in the domain, and it can include members of any type within the domain, and members from trusted domains. For example, a domain local security group named ACL_Sales Folders_Read might be used to manage Read access to a collection of folders that contain sales information on one or more servers.

Global Groups

Global groups are used primarily to define collections of domain objects (users, other global groups, and computers), based on business roles, which means that they mostly serve as role groups.

Role groups, such as the Sales and Marketing groups, and roles of computers such as a Sales Laptops group, are usually created as global groups.

Global groups have the following characteristics:

• Replication. A global group is defined in the domain naming context (the domain itself). The group object, including the member attribute, is replicated to all domain controllers only in the domain they were created in.
• Membership. A global group can include as members only those users, computers, and other global groups in the same domain the global group was created in.
• Availability. A global group is available for use by all domain members, and by all other domains in the forest and all trusting external domains. A global group can be a member of any domain local or universal group in the same domain or other domains in the forest. It can also be a member of any domain local group in a trusting domain. Global groups can be added to ACLs in the domain, in the forest, or in trusting domains.

Global groups have the most limited membership (only users, computers, and global groups from the same domain) but the broadest availability across the domain, the forest, and trusting domains.

Global Group Best Practice:

Global groups are well suited to defining roles, because roles are generally collections of objects from the same directory. For example, global security groups named Consultants and Sales might be used to define users who are consultants and sales people, respectively.

Universal Groups

Unlike Global and Domain local groups, the use of Universal Groups is not limited to role or rule type of groups; they can be used in both types of groups depending on the scenario.

Universal groups have the following characteristics:

• Replication. A universal group is defined in a single domain in the forest but is replicated to the global catalog, which makes the universal group available to all domains, forest wide, and to trusting domains and forests.
• Membership. A universal group can include as members users, global groups, and other universal groups from any domain in the forest.
• Availability. A universal group can be a member of a universal group or domain local group anywhere in the forest. Additionally, a universal group can be used to manage resources, for example, to assign permissions, anywhere in the forest, as well as across trusts.

Universal groups are useful in multidomain forests. They allow you to define roles or to manage resources that span more than one domain.

Universal Group Limitations:

“Universal Groups cannot contain members (users or groups) outside the forest they are created in. This limitation would preclude users or groups that are members of domains trusted via External

Trusts from being added to Universal Groups.”
“Universal Groups from any domain in any forest can not be placed as members into Global Groups.”
“Domain Local Groups from any domain in any forest can not be placed as members into Universal Groups.”
“Universal Groups can not contain Global Groups from a mixed-mode domain in the same forest. “
http://networkadminkb.com/kb/Knowledge%20Base/Windows2003/Universal%20Group%20Limitations.aspx

Enable Universal Group Membership Caching in a Site:
“To reduce Global Catalago replication traffic, You can enable universal group membership caching.”
“In a branch site that has no global catalog server and in a forest that has multiple domains, you can use this procedure to enable Universal Group Membership Caching on a domain controller in the site so that a global catalog server does not have to be contacted across a wide area network (WAN) link for every initial user logon.”
http://technet.microsoft.com/en-us/library/cc816928%28WS.10%29.aspx

The best way to understand universal groups is through a short example

(For a bigger example, see the Group Nesting Strategy example towards the end of this blog)

Widgets, Inc has a forest with three domains: Americas, Asia, and Europe. Each domain has user accounts and a global group called, Regional Managers, which includes the managers of that region.

Keep in mind that global groups can contain only users from the same domain. Therefore due to this limiation, we need to look at using a Universal Group for this solution. We’ll create a universal group called, “Widgets Regional Managers,” or rather “U_Widgets Regional Managers” and the three Regional Managers groups are added as members.

The Widgets Regional Managers group therefore defines a role for the entire forest. As users are added to any one of the Regional Managers groups, they will, through group nesting, be members of the Widgets Regional Managers.

Widgets, Inc is planning to release a new product that requires collaboration across its regions. Resources related to the project are stored on file servers in each domain. To define who has the ability to modify files related to the new product, a universal group is created called “U_New Product_Modify.” That group is assigned the Allow Modify permission to the shared folders on each of the file servers in each of the domains. The Widgets Regional Managers group is made a member of the “U_New Product_Modify” group, as are various global groups and a handful of users from each of the regions.

Using universal groups can help you to represent and consolidate roles that span domains in a forest, and to define rules that can be applied across the forest.

Identifying and Creating a Group Nesting Strategy – IDGLA or AGDLP

Nesting is the process of adding one group to another group. This will allow you to help better manage and administer your environment based on business roles, functions, and management rules.

However, you can’t add any old group to any other old group. There are some rules to follow. The two Scope Summary charts above will help understand which groups can be members of other groups, depending on group scope or type.

The Best Practice for group nesting, known as IGDLA. IGDLA stands for Identities, Global groups, Domain local groups, and Access:

• Identities (user and computer accounts) are members of:
• Global groups that represent business roles. Those role groups (global groups) are members of:
• Domain Local groups that represent management rules—determining who has Read permission to a specific collection of folders, for example. These rule groups (domain local groups) are granted:
• Access to resources. In the case of a shared folder, access is granted by adding the domain local group to the folder’s access control list (ACL), with a permission that provides the appropriate level of access.

As mentioned earlier, it was previously referred to as AGDLP, but changed to IDGLA because it defines more of a general scope of aplication, then just defining how AD groups work, which aligns with industry standards practice.

If the Domain Functional Level and Forest Functional Level is set to Windows 2000 or newer, AGDLP can be expanded to AGGUUDLDL, allowing you to nest Globals into other Global Groups, Global Groups into Universal Groups, Universal Groups into other Universal Groups, as well as Domain Local Groups into other Domain Local Groups.

The same applies to IDGLA expanded to IDGGUUDLDLA, or Identities, Global groups, Global Groups, Unicersal Groups, Universal Groups, Domain local groups, and Access. However, it’s not really referred to it as such, and is more or less a description of it’s expanded options, but more so because IGDLA refers to simply organizing identity resource access by role.

By any other name, the end results is the user gets the permissions applied to the Domain Local Group.

Summary:

AGGUDLP:

Recommended Best Practice for Active Directory Groups Nesting Strategy:

Add accounts to a Global Group, add the Global Group to a Universal Group, add the Universal Group to a Domain Local Group, apply permissions for the Domain Local Group to a resource. The accounts in the original Domain Local Group will have access to the resource with the permissions levels based on the permissions applied to the Domain Local Group.

AGGUUDLDLP:

Extended Optional Active Directory Groups Nesting Strategy:

Add accounts to a Global Group, optionally nest the Global Group into another Global Groups, etc, add the last nested Global Group to a Universal Group, optionally nest the Universal Group into another Universal Group, etc, add the last nested Universal Group to a Domain Local Group, optionally nest the Domain Local Group into another Domain Local Group, etc, apply permissions for the last nested Domain Local Group to a resource. The accounts in the original Global Group will have access to the resource based on the permisions applied to the Domain Local Group.

With a multi-domain forest, we’ll need Universal groups to fit the bill, which would be used to add Global Groups from multiple domains. That universal group can be added as a member of domain local groups in multiple domains. You can remember and refer to the nesting as IGUDLA.

If a Universal Group is available Forest Wide, then where is the Universal Group stored?

The Universal Group is stored in the domain of where it was created, but the Universal Group Memberships are stored in the Global Catalog and replicated Forest Wide.

Group Nesting Strategy Practice Scenario:

TechNet forum thread question: “can we add universal group into global group?”
http://social.technet.microsoft.com/Forums/en/winserverDS/thread/fa66b5c5-3ed3-4700-b479-e036577e110b

Basically, you need to follow the AGUDLP guideline (Add users to a global group, add the global group to a Universal, add the Universal to a Domain Local Group, add the Domain Local Group to the resource, then provide permissions for the Domain Local Group to access the resource).

This can be expanded to ADDUUDLDLP, which means you can nest Global groups into other Global Groups, nest Universal Groups into other Universal Groups, and nest Domain Local groups into other Domain Local Groups, but you can’t go backwards, meaning that you can’t add universals into a Global. Matter of fact, the system won’t even give you the option to add the groups trying it the other way.

.

Here’s an example of what I use in class when teaching group nesting:

• Scenario: One forest, three domains.
• Domain and Forest Levels are at the latest levels.
• The Accountants in each domain need Full Control permissions to the accounting database in only their domain.
• The Accountants in all domains in the forest need Read permissions to the accounting databases in the other domains.

How would you do this?

Solution:

• In each domain, create two Domain Local Groups (DLG), one that you will assign Read permissions, and the other that you will assign Full Control permissions.
• Add both DLG groups to the accounting database in each domain, and assign the appropriate permissions for each group.
• In each domain, create a Global Accountants Group.
• Add the users in each domain to their own domain’s Global Accountants Group.
• Add the Global Accounting Group in each domain to their domain’s Domain Local Group that has been assigned Full Control to the database.
• Create one Universal Accountants Group.
• Add the Global Accountants Group from each domain to the Universal Accountants Group.
• Add the Universal Accounting Group to the Domain Local Accountants Group in each domain, that has been given Read permissions to the accounting databases.

Here’s two versions of the diagram that should help to show the solution steps in the above bullet point.

Reference picture:
http://cid-0c7b9fd0852378b8.photos.live.com/self.aspx/Technet%20Forum%20Support/AD%20Groups/AD%20Groups%20Strategy.jpg

Reference Link to pic above:
https://public.blu.livefilestore.com/y1pe2i8ifuHij7srt59GRhupSS4CwgSe2OuOsUf23GQt2fNNcZFzlJGrM4VopdRoeBILusmw3CnVbaJKPfREWLPZw/AD%20Groups%20Strategy%20-%202.jpg?psid=1

.

Related Info and links:

Group scope: Active Directory
http://technet.microsoft.com/en-us/library/cc755692(WS.10).aspx

Active Directory Groups & Permissions Guideline – Good tutorial:
http://microsys.unity.ncsu.edu/documentation/ITD-Active-Directory-Environment/Groups-Permissions.php

Ace Fekay

Reference:

https://blogs.msmvps.com/acefekay/2012/01/06/using-group-nesting-strategy-ad-best-practices-for-group-strategy/