IGDLA and you: A Fledgling’s Guide to Nesting

For anyone who is attempting to learn about Active Directory Domain Services (AD DS), the sheer number of acronyms and practices to memorize is daunting to say the least. Not only are these acronyms more abundant than tribbles, they also represent advanced concepts in system administration that aren’t as simple as the abbreviations might lead you to believe. Nesting is no exception.

If you aren’t familiar with the Active Directory Groups, you probably have no idea what I’m talking about (and you’re probably asking yourself how you found your way to this page). For more on AD Groups, here’s the most interesting article I could find on the subject: Group Types. Once you’ve got that down, it’s time to tackle nesting. In the wonderful world of Microsoft, nesting is the process of storing Groups within other Groups on the AD system, and IGDLA is the best practice for accomplishing this.

I don’t know about you, but when I first started learning about network administration, it was tempting to memorize the acronym and the best practice associated with it without actually processing the ideas behind the words. It was only when I slowed down and started focusing on the theory behind these policies that the logical webbing beneath the surface started to appear before me. Not only is following IGDLA the industry standard, it is also, conveniently, the most practical way to ensure that the integrity of user permissions is maintained. Here’s the breakdown:

If you were wondering how excited I am about IGDLA, this is the doodle on the back of my notebook. I know, right?

What’s it Mean?

IGDLA stands for:

• Identities (I)
• Global Groups (G)
• Domain Local Groups (DL)
• Access (A)

1. Identities: User and computer accounts that represent roles in an organization. They have the privilege of being able to be members of any type of group (except Local and Domain Local groups outside their domain). They are nested inside…
2. Global Groups (aka role groups): Members of Domain Local Groups which represent management rules by grouping together Identities with the similar permissions based on their role. They are nested inside…
3. Domain Local Groups (aka rule groups): Grants members access to resources based on the policies of the local domain. By adding a DL Group to a file’s ACL (Access Control List), you can give the entire group permission to access it, regardless of role in the organization. These groups control…
4. Access: Assigned access to a resource that trickles down the hierarchy until it finds the Identities that require it.

Note: When nesting in a multi-domain system (or forest), the acronym is extended to IGUDLA, including Universal Groups, which we will abstain from touching on in this brief review.

Why IGDLA?

All this is nice and well, and if you memorize the system, you’ll do the job just fine, but the question still remains: Why IGDLA? Why not GLAID or GAIDL (they sound nicer, at least)?

The answer lies in our understanding of how permission is granted in a single domain system. The key is in the default inheritance of permissions. Permissions are inherited by any group nesting within another one. Inheritance trickles down to the user/computer from the Access point.

So, Domain Local Groups grant access to Global Groups, who have their own permissions based on their roles. Global Groups grant access to Identities, who have now inherited rivulets of Access from all the Global and (in turn) Domain Local Groups that the object is a member of.

IGDLA not only allows the administrator to modify the access level of great quantities of users at once; it creates an intuitive hierarchy of Organizational Units (OUs) that anyone accessing the data can understand. By remaining consistent, any administrator knows what they’re looking at, and that is the best practice for nesting.

At this point, we’ve seen a pretty basic model of nesting hierarchy and permission granting. We’ve got our foundation from which to build on. If nothing else, it has become apparent that acronyms don’t always sound or look nice, but they exist for a very good reason.

For a additional resources and practical application, check out this MVP’s article: Using Group Nesting Strategy — AD Best Practices for Group Strategy

Post-script: If you’re wondering what IGDLA looks like in Windows Server 2012, here’s a nice example. Enjoy:

this really is the end