Using Group Nesting Strategy – AD Best Practices for Group Strategy

Using Group Nesting Strategy – AD Best Practices for Group Strategy

Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services

Published 1/6/2012

Preface:

I put this blog together hoping I can provide insight on how Active Directory groups were meant to be used to provide access to resources based on how Microsoft’s engineers originally designed them to be used.

The method presented here is similar to how I would teach and describe it in a classroom. Of course when I’m teaching, I’m a bit more animated in front of the class with a 12′ wide whiteboard, where I take its large size to the full advantage. I’ll keep it toned down in this blog to shorten your reading time, provide some graphics, and get right to the point.

Some of the graphics in this blog are actual courseware slides which were modified from the Microsoft Official Curriculum MOC 6425C and MOC 6425B courseware, “Configuring and Troubleshooting Windows Server 2008 Active Directory Domain Services.” You can find additional information on this 5-Day, Instructor-Led course in the following link:

MOC 6425C Configuring and Troubleshooting Windows Server 2008 Active Directory Domain Services –
5 Day, Instructor-led, classroom or online.
http://www.microsoft.com/learning/en/us/Course.aspx?ID=6425C&Locale=en-us

There is also 20 hour, a self-paced online version of this course also available. Information on this version can be found in the link below. At the time of this writing, 12/31/2011, the cost is USD $319.00:
https://www.microsoftelearning.com/eLearning/offerDetail.aspx?offerPriceId=222031

The instructor led course costs much more. For pricing, please contact a Microsoft CPLS center (Certified Partner for Learning Solutions).

The terminology used in this blog includes resource access design practice terminology called IGDLA, or short for “Identities, Global groups, Domain local groups, and Access.”

However, the previous terminology was AGDLP, or short for “Add Accounts to Global Groups, then to Domain Local Groups, then apply Permissions to the Domain Local Group.”

By any other name, at the end of the day, the user gets the permissions applied to the Domain Local Group on the resource. IGDLA provides more of a general scope of application, then just defining specfically how AD groups work. IDGLA aligns with current industry standard practice terminology, which was the driving factor to change it.

 

Understanding what Groups are and what they are used for

Before implementing groups in your environment, it’s beneficial to understand how groups are used and which types of groups exist. It’s also important to understand group scope to help identify proper group type and usage in various scenarios. In addition, it’s important to define a group naming convention to easier “see” what the group type and intentions are just by looking at the name of the group, as well as to understand the group nesting feature and the benefits of using this approach.

Using groups makes it more efficient for the operating system to enumerate permissions on an ACL. Imagine if you have 300 user accounts on an ACL. The system must enumerate each and every user account, or rather the user account’s SID numbers, in the ACL. This will be preceived as a performance lag. Not only a performance hit, it’s difficult to keep track of.

When you use Groups, you add the group name to the resource. You also add the user account to the Group in Active Directory. So what happens is when the user logs on, the session ticket that gets assembled will have the user account SID in it, along with the Group SID. Therefore, when you access the resource, the system simply matches the user’s session ticket’s SID entries to the SID entries on the resource ACL. Much simple, easier to manage, and extremely efficient.

Keep in mind, some of the features may or may not exist in your Active Directory infrastructure, depending on what OS version your domain controllers are, or in a mixed NT4 environment. What is the oldest domain controller that still exists in the domain and/or forest, is also a factor. Such features as group nesting, may not exist if the AD domain and/or forest functional levels haven’t been updated to the latest levels. Using groups will also help to reduce the overall administrative overhead of handling user access, instead of simply adding a user account to a resource. What happens when that user leaves the company? Some institutions will keep the account but disable it. Other insitutions will delete the account. So what happens if you delete a user account that is still specified in an ACL? The user account in the ACL of a resource will remain but only as a SID number, and not the user account name, because it was deleted. This can become confusing to figure out who the account was, but at that point, it doesn’t matter because you know it was an account that was deleted. In that case, the only thing you can do is delete the SID entry in the ACL. Unless you were to reanimate the account whether performing an authoritative restore, using ADRestore.Net, or restoring an account from the AD Recycle Bin with Windows 2008 R2 or newer, but that is a different topic beyond the scope of this blog.

And what happens if you just use user accounts instead of groups? You might say I only have 20 users, so I’ll just do it by user account. Then after awhile, the company grows, more users are hired, you keep adding them to resources based on their user accounts, but one day you look at it and say, wow, we have over 200 users now, and we are having problems keeping track of who has access to what. If only I had started using groups in the beginning, and simply added or removed users from the groups as their roles or positions in the company changed, I would have had a better handle oh this mess, and it would be one less thing on my plate that I have to deal with now.

Role Groups

We can create role based groups to help day to day administration. Role groups such as based on their functions:

• Sales
• Marketing
• Accountants
• Managers
• Accounting Managers
• Sales Managers
• etc

Group Naming Convention

Naming convention is important. I usually like to name my groups based on the group type, role and access. For example, I’ll create a Global Group (GG) for the accountants that just need Read access:
G_Accountants_Read

And for the accountants that need Full Control:
G_Accountants_FC

Of course, we usually don’t like to provide Full Control because besides Full Control allowing to change anything, it also allows the ability to change permissions as well as Take Ownership of a resource. In many cases, the “Modify” NTFS permission will work fine, and the users will not know the difference, as long as they see they can create, change, and delete items.

In summary, create Role based groups and properly name them to help easily identify and administer them.

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

 

I hope you’ve found this helpful.
Comments and suggestions are welcomed!

Ace Fekay