Active Directory Groups, How they Work and How to Use Them

Managing Your Accounts the Right Way

One of the most important roles a Systems Administrator has is user management. Depending on the size of your network, it can be really simple or horribly daunting.  Luckily, there are strategies for handling permissions to accounts, so you don't have to spend your entire life applying permissions to each user.  This is the purpose of Security groups, and there are some best practices associated with handling them.

The Best Practice

Somewhere along the line, back in the age of NT, Microsoft developed a group and account management strategy called AGDLP.  The underlying purpose for this strategy was to handle account access between domains.

Accounts were added to Global groups, and the global groups were added to Domain Local groups.

The Domain Local groups were given permissions to files, processes, and anything else that needed access.  The whole purpose of this strategy was to prevent administrators from having to assign permissions to individual users in each domain (which can take forever in large environments).  With Windows 2000, Microsoft also added the Universal group and AGDLP became AGUDLP.
 
The strategy continues today, in the world of Windows 2008 (if you've gotten there yet).  So let me explain what each of these group types do.

The Skinny on the Group Types

We'll start from the bottom of the list and work our way up in defining the group types

Local Groups Local groups are not really important in the context of this article, but they should be mentioned.  Essentially, they are groups that exist only on a single computer.  Members of a local group can come from anywhere in the forest.

Think of the Local Administrators group on your Desktop or Laptop.  This is a Local Group.  You can assign any user or group (think Domain Users or Domain Admins) to local groups and not have to assign individual permissions.  The purpose of this particular type of group is to make allow specific permissions on a single device.

Domain Local Domain Local can contain users and groups from any domain in a forest and any forests that you have a trust with.  However, when developing ACLs, you can only use these groups if the objects are in the same domain.

The entire purpose of the Domain Local group is to assign permissions for file access, system access, user rights assignment, and just about anything else with an ACL in a domain.  The major exception to this is ACLs tied to directory objects.  When granting permissions and delegating authority in Active Directory Users and Computers it is not recommended using Domain Local groups.

Global Global groups are almost the exact opposite of a Domain Local group.  Then can be used to grant permissions anywhere in the forest, but they cannot have members outside of the domain they are in.

In addition, you cannot have a Domain Local group in a Global group.  This is important to remember.  Global Groups can be placed in a Domain Local group anywhere in the forest, but not the other way around.

The purpose of Global Groups is to group together members of a single domain so they can be granted permissions in a different domain.  This is a user organization group.  

According to best practices, you really shouldn't assign permissions directly to Global Groups. (For information, the Domain Admins and Domain Users groups are actually Global Groups.  The reason for this is to prevent Users from external Domains from gaining full administrative and user rights in a separate domain.   This is a security feature and can be considered an exception to the rule).

Global groups are not replicated during domain replication, which means you can change the membership of a Global group all you want and have no increased replication traffic.

Universal Groups Universal Groups are, well, universal.  They can have members from any domain and can be given permissions to any object in any domain.  This sounds like a great flexible thing and at first glance you may be thinking, "Why not just use Universal Groups exclusively?" The answer lies in the way Active Directory replicates between Domains.

Every member of a Universal group is listed along with the group in the Global Catalog (The Global Catalog is basically the Active Directory Database.  It holds all the information about the entire AD forest).  Domain Local and Global groups are also listed in the Global Catalog, but without information about what users are in those groups.  So in order to use a Universal group, you have to have access to a Global Catalog at all times (If the Global Catalog server goes down, permissions granted to universal groups go with it).

In addition, changes to Universal groups require replication, and the more members you have in a Universal Group, the more replication traffic you have to deal with.  Universal Groups are meant to be a bridge between Domains and Forests, allowing Global Groups to be given permissions in other domains and forests with greater ease and without having to search a separate domain for the global group when adding it to a domain local group.

Again, Domain Local groups cannot be placed in a Universal group. Because of the replication requirements, members of Universal Groups should be fairly limited.  Also, just like Domain Local groups, Universal groups cannot be made members of Global groups.  This is the reason for AGUDLP.

AGUDLP In Action

AGUDLP stands for Accounts go into Global groups which go into Universal groups, which go into Domain Local groups, which get Permissions.

Now, we start with a situation.  Users in Domain A need access to Resources in Domain B.  We have a specific list of users.  In order to work this strategy right, we do the following:
Note:To make sure the universal group shows up properly, we'll need to force replication throughout the forest (I'm not going to cover that, because it'll trigger my ADD and I'll go off on a tangent...oooh shiny).
Once that is done, we need only find the resources that the users in Domain A require and add the Domain A Access group to the ACL for those objects, then apply the appropriate permissions.
And there you have it.  AGUDLP has just allowed us to give users in a different domain access to resources in the other domain.

Next, let's say you have a single domain.  Microsoft's actual recommendation is to put all users into a Global group, then make the global group a member of a domain local group.  Then assign permissions to the Domain Local group.  In this situation, you'll have the ability to add new groups of users to the domain local group, and you won't have to set another set of permissions.  The second Global group will have the same access as the first.

Closing

AGUDLP is meant to help decrease replication traffic and make your life easier.  I highly recommend familiarizing yourself with it, as it will save you time and effort in organizing and granting permissions to your users.

Additional Resources

Group Scopes, when to use different groups and why: http://technet.microsoft.com/en-us/library/cc755692%28WS.10%29.aspx