When you investigate groups within Active Directory, you will see that you have many to choose from. The type and scope of group that you choose to create will depend on how that group can be used and where it can be used within the enterprise. Knowing how the Active Directory groups are designed by Microsoft will help you develop a solid group strategy for assigning permissions. In addition to knowing how to design your groups, there are some pitfalls with user and group nesting that you want to avoid, as these pitfalls create a very insecure environment.
Group types and scope
When you jump into the Active Directory Users and Computers interface to create some groups, you will immediately see that there are many options to choose from. As you can see from Figure 1, you need to select the group scope and type during the creation of a new group.
Figure 1: Active Directory groups require both scope and type to be configured
Understanding the specifics of these groups will help you design and determine which options to pick for the group that you are creating. For each group, you need to know what objects it can contain, as well as the overall purpose of the group.
For the group scope, you are determining where the group should be used within the Active Directory enterprise. Your group selection here determines a lot about how you want to use the group within the overall assignment of permissions. Before we discuss each group specifically, the overall picture of group and user nesting is designed to be as follows:
Users go into Global Groups, Global Groups go into Domain Local Groups, and Domain Local Groups are listed on the Access Control List (ACL) of the resource.
If Universal Groups are used, then the following nesting rules apply:
Users go into Global Groups, Global Groups go into Universal Groups, Universal Groups go into Domain Local Groups, and Domain Local Groups are listed on the Access Control List (ACL) of the resource.
Domain Local Group – This group scope is designed to contain Global Groups and Universal Groups, even though it can also contain user accounts and other Domain Local Groups. If you want to follow a logical nesting rule pattern, you will not put user accounts into Domain Local Groups. As you design and create Domain Local Groups, you should be considering “What the group is designed to do at the resource.” Examples might be “Read SQL DB,” “Full Control HR Data,” or “Modify Finance Group Membership.”
Note:
Domain Local Groups can only be seen and used on domain controllers if the domain is still in mixed mode. Mixed mode also eliminates the capability of nesting Domain Local Groups into other Domain Local Groups. This is due to the fact that NT4 domain controllers don’t understand the concept of Domain Local Groups, so they are simply seen as Local Groups.
Global Groups – This group scope is designed to contain user accounts. Global Groups can contain user accounts and other Global Groups. Global groups are designed to be “global” for the domain. After you place user accounts into Global Groups, the Global Groups are typically placed into Domain Local Groups or Local Groups (which reside on member servers in the Security Accounts Manager (SAM)). As you design and create Global Groups, you should be considering “What type of user belongs in this group.” Examples might be “Salesreps,” “HR Managers,” or “Finance Managers.”
Note:
Global Groups can only contain user accounts if the domain is in mixed mode. Like group nesting is not available in mixed mode due to legacy NT4 domain controllers.
Universal Groups – This group scope is designed to contain Global Groups from multiple domains. Universal Groups are designed to help “group” groups in a multi-domain enterprise. Universal Groups can contain Global Groups, other Universal Groups, and user accounts. After the Global Groups from the different domains are placed into the Universal Group, the Universal Group is typically placed into a Domain Local Group or Local Group. As you design and create Universal Groups, you should be almost mimicking the concepts of the Global Group, but from an enterprise standpoint. So, you might have a Universal Group named “All HR Managers” or “All Finance Managers.” Within each of these Universal Groups, you will have the “HR Managers” or “Finance Managers” from each domain as members.
Note:
Universal Groups cannot be used as Security Groups if the domain is in mixed mode. This means that they can’t be used for controlling access to resources via permissions. Again, this is because NT4 domain controllers don’t understand the concept of Universal Groups.
Security Groups – This type of group has a unique characteristic in that it has a Security Identifier (SID) assigned to it from Active Directory. This SID enhances the function of the group so that it can be used for assigning and controlling permissions to a resource. In essence, Security Groups can be placed on an ACL of a resource. Security Groups can also be used for email distribution lists.
Distribution Groups – This type of group is limited in capabilities, because it does not have a SID assigned to it. Distribution Groups are designed to work with email, but not for the assignment or control of permissions to a resource.
Groups and Users in Windows NT4
Most environments still rely on the old style of group nesting that was forced in Windows NT4 domains. This is because most companies migrated in some fashion from Windows NT4 to Active Directory, so the group model was already formed. The group model that I am referring to has the following group and user nesting structure:
Users go into Global Groups, Global Groups go into Local Groups, and Local Groups are listed on the Access Control List (ACL) of the resource.
This was the only option for multiple reasons. First, Windows NT4 did not support like group nesting. So, Global Groups could not be included in other Global Groups and likewise for Local Groups. Second, The domain SAM did not include Domain Local Groups, so the only way to nest groups from the domain was to place Global Groups into the Local Groups on the member servers where the resource resided. Third, each domain was its own entity, so there was no need to consider cross domain interaction within the same directory like Universal Groups accomplish in Active Directory.
What NOT To Do
In reality, all group nesting rules are subject to interpretation. I have seen all options implemented and used company wide. As long as the user and group structure has logic and is secure, there is really no reason that the “designed Microsoft” methods need to be followed strictly.
However, there are two different options that should be avoided at all costs. These two options create an insecure environment that is almost impossible to track, troubleshoot, and secure.
- User accounts should never be placed into Local Groups. The Local Groups that I am referring to are the Local Groups in the local SAM of member servers. When this is done, it is nearly impossible to enumerate which Local Groups a user has membership in, which is essential for a security audit. Also, when a user moves from one job role to another, it is impossible to make sure that all “old resources” that the user has access to are removed.
- User accounts should also not be placed directly on the ACL of a resource. The reason for this is identical to the reasons listed in the first bullet. There is no way to enumerate the resources that a user has access to if the user is placed directly on the ACL.
Summary
The use of domain groups is essential for administration of resource access. Knowing which groups are available and the intent of the group is key to designing your group nesting strategy. Microsoft developed the groups within Active Directory such that the administration of all groups could be within Active Directory. However, with the migrations from Windows NT4, it has made it hard to implement the desired group strategy that Active Directory provides. Knowing the capabilities of each group, as well as the limitations, you can now design a strategy that works best for you. Regardless, make sure that you don’t configure users and groups such that a security issue is created.
No comments:
Post a Comment