Group scope is important to understand if you want to effectively control risks in how you use AD groups. The scope of a group determines where the group can be applied in the forest or the domain. Scope also determines who can be a member of a group. Because Microsoft hasn’t built many limitations into Active Directory regarding which groups can be nested within which, group nesting can present massive security and operational risks to an organization. The only real help that AD offers to combat the potential risks of nesting security groups is the group scope. There are three group scopes: universal, global, and domain local. Each group scope defines the possible members a group can have and where the group’s permissions can be applied within the domain. The table below was taken straight from Microsoft Technet and it gives the whole story of the rules for group scope. But the rules are only half of the story. The other, more important half lies within understanding how to properly use and apply these scopes. The goal of a well-architected AD is to provide the appropriate users with no more or less than the necessary levels of access to information and resources needed to do their jobs. Role-, attribute-, and resource-based security models are all different ways that organizations use to accomplish this goal across the whole of the IT infrastructure including AD. A proper understanding of group scope and how to apply it is necessary to achieve these models in the environment. AGDLP and AGUDLP are Microsoft’s best practice structural models for AD architecture and they can help organizations follow these security models. The AGDLP model provides a guide for how to nest groups within one another without compromising security or sacrificing operational efficiency. The model stipulates the following: User and computer Accounts should be members of Global groups, which are in turn members of Domain Local groups that describe resource Permissions. The rationale behind this can be a little tricky, but I’ll do my best to break it down here. Global groups are used to contain user and computer accounts and can include other global groups from within the same domain. Think of global groups as “account groups”. These groups will include users who are alike in the sense that they are all a part of the same domain, since global groups cannot contain members from other domains. The users will also probably have some other commonalities such as being in the same department, having the same manager, or some other similarity of that nature. For instance, all of the users who are in the Marketing department of the New York headquarters of a company would be put into the same global group called “Marketing”. Due to the flexibility of their membership restrictions, domain local groups are ideal for granting permissions on resources. Specifically, these groups are used because groups from the parent domain as well as other domains and trusted forests can be added to them. This allows for administrators to grant access to a resource for anyone in the environment should they need it. If global groups are the “account groups”, then domain local groups are the “resource groups”. An example of a resource group in action may be a domain local group that grants access to a file share called “Marketing Documents”. By nesting the “New York Marketing” global group inside the “Marketing Documents” domain local group, we have just given all of the users in the Marketing department in New York access to the contents of the Marketing Documents share. Here is a graphical representation of this AGDLP scenario:
The use of domain local groups becomes especially important when you are dealing with situations involving trusted forests. In a case like this, chances are good that accounts in one forest will need access to resources in the other forest. If a global group was being used to grant access to a resource, there would be no way for accounts in the second forest to be given access to that resource, since accounts and groups cannot be nested into global groups from a different domain or forest. To continue with our example, perhaps our fictitious company acquires another company in Miami and the IT groups decide to trust the two companies’ forests together. If we follow the AGDLP model, the Miami-based company’s Marketing department should have its own global group in their forest. In order to give the new company’s Marketing department access to the Marketing Documents share, all the admin has to do is nest the Miami Marketing global group in the Marketing Documents domain local group. See the graphical representation below for a simplified look:
The AGUDLP model is very similar to AGDLP (as the name suggests) but introduces the “U” for Universal groups into the equation. These groups’ memberships are stored in the global catalog, which is more of a necessity in multi-domain environments. The use of this model really depends on how much the global catalog is relied on in the organization. If there is a vested interest in having the global catalog be as complete as possible (perhaps you have a large mobile workforce and rely heavily on employees being able to easily find each other in Outlook), then the AGUDLP model will help in this endeavor. However, for smaller environments that only have a single domain this model may add an unnecessary layer of complexity. The reason these models are Microsoft’s best practice is two-fold. From a security perspective, if one was to use global groups to give users permissions to resources they would have to add users from other domains and forests into the domain where the resources reside. Generally, separate domains and forests exist for a reason and the delineations between domains and forests are not meant to be blurred. By using domain local groups to grant permissions to specific resources, an admin can give members from other domains and forests access to the resource without needing to give them direct access to the rest of the domain where that resource lives. Too often we see organizations use global groups to define permissions on resources and end up over-provisioning access and rights as a result when users move in and out of the group. From an operational perspective, the AGDLP and AGUDLP models also make group membership management easier in the sense that permissions and user organization are managed in distinct places. Resource permissions are set for domain local groups and do not need to change once they are determined, limiting how often it is necessary to go out to the resource to adjust these permissions. In addition to containing built-in restrictions for membership, global groups are also easily changed and thus, provide a perfect place for users to reside in since users are constantly moving around the organization necessitating different levels of access. It should be noted that just because these models are Microsoft’s best practices, they are not perfect for everyone. In larger environments, the use of domain local groups to manage resource permissions can lead to the generation of very large numbers of groups. This could result in a user being a member of thousands of groups by the time they are granted access to all of the resources they need and could, in turn, result in issues like token bloat. In the end of the day, following the AGDLP and AGUDLP models offers some very real benefits to an organization. The trouble often times lies in implementing the infrastructure to follow the model given that it relies on more than just a savvy admin to shuffle groups around in AD. These models necessitate constant vigilance and oversight on the part of IT to enforce. Many steps have to be taken to implement and maintain them such as assigning owners to groups who understand the needs of the users in those groups, ensuring that the right users are in the right groups and that groups contain the correct permissions on resources. The good news is that there are tools that can help with these steps. Our StealthAUDIT Management Platform, for example, provides a jumping off point for getting organizations on track by helping them to understand what groups are currently granting access to, which users are in those groups and what rights those users have. Furthermore, StealthAUDIT can assist in the transformation of an organizations access model and the identification of group owners by putting the power in the business’s hands to manage their own groups since they know who needs access to what better than anyone. While it can be a monumental effort to adopt AGDLP or AGUDLP, the residual benefits can go a long way towards ensuring a secure, sustainable environment. Alex Berger is product manager at STEALTHbits Technologies.
