Adding groups to other groups—a process called nesting—can create a hierarchy of groups that support your business roles and management rules. Now that you have learned the business purposes and technical characteristics of groups, it is time to align the two in a strategy for group management.
Earlier in this #lesson, you learned which types of objects can be members of each group scope. Now it is time to identify which types of objects should be members of each group scope. This leads to the best #practice for group nesting, known as IGDLA:
– 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—for example, managing who has Read permission to a specific collection of folders. These rule groups (domain local groups) are granted
– Access to resources. In the case of a shared folder, for example, access is granted by adding the domain local group to the folder’s ACL, with a permission that provides the appropriate level of access.
A multidomain forest also contains universal groups that fit in between global and domain
local groups. Global groups from multiple domains are members of a single universal group.
That universal group is a member of domain local groups in multiple domains. You can
remember the nesting as IGUDLA.
Note : IG DLA vs. UG DLA
Some texts abbreviate the group nesting strategy as UGDLA: Users go into Global groups, which go into Domain Local groups, which are given Access to resources. This text, and others, changes the abbreviation to IGDLA. Although users are members of groups, so are computers. For example, to deploy software to a collection of computers, you can make them members of a group that is used as a deployment target by your software distribution tools. Therefore, identities is more accurate than users. In addition, the change allows U to be used for Universal groups in multidomain forest group nesting.
This best practice for implementing group nesting translates well even in multidomain scenarios. Consider Figure 4-10.
Figure 4-10 represents a group implementation that reflects not only the technical view of group management best practices (IGDLA) but also the business view of role-based, rule-based management.
Consider the following scenario. The sales force at Contoso, Ltd., has just completed their fiscal year. Sales files from the previous year are in a folder called Sales. The sales force needs Read access to the Sales folder. Additionally, a team of auditors from Woodgrove Bank, a potential investor, requires Read access to the Sales folder to perform an audit. The steps to implement the security required by this scenario are as follows:
1. Assign users with common job responsibilities or other business characteristics to role groups implemented as global security groups.
This happens separately in each domain. Salespeople at Contoso are added to a Sales role group. Auditors at Woodgrove Bank are added to an Auditors role group.
2. Create a group to represent the business rule regarding who can access the Sales folder with Read permission.
This is implemented in the domain that is managing the business rule. In this case, the business rule is Read-level access to the Sales folder, and the Contoso domain (in which the Sales folder resides) manages the access. The resource access management rule group is created as a domain local group, ACL_Sales Folders_Read.
3. Add the role groups to the resource access management rule group ACL_Sales Folders_Read to represent the management rule.
The role groups you add can come from any domain in the forest or from a trusted domain such as Woodgrove Bank. Global groups from trusted external domains, or from any domain in the same forest, can be members of a domain local group.
4. Assign to the rule group the permission that implements the required level of access. In this case, grant the Allow Read permission to the domain local group ACL_Sales Folders_Read.
This strategy results in single points of management, reducing the management burden. One point of management defines who is in Sales, and one defines who is an Auditor. Those roles, of #course, are likely to have a variety of permissions to resources beyond simply the Contoso domain’s Sales folder. Another single point of management determines who has Read access to the Sales folder. And, of course, the Sales folder might not just be a single folder on a single server: It could be a collection of folders across multiple servers, each of which assigns Allow Read permission to the single domain local group.
Note: Role-based management
Role-based management is a concept used throughout information technology and information protection, and it can be attained with out-of-the-box capabilities of Active Directory. IGDLA is the implementation of role-based management using Active Directory groups.