7. Developing a Group Management Strategy
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
IGDLA VS. UGDLA
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 10.
Figure 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:
-
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.
-
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.
-
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.
-
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.
Practice Creating and Managing Groups
Practice Creating and Managing Groups
In this practice, you create groups, experiment with group
membership, and convert group type and scope. Before performing
the exercises in this practice, you must create the following
objects in the contoso.com domain:
-
A first-level OU named Groups
-
A first-level OU named User Accounts
-
User objects in the User Accounts OU for David Jones,
Jeff Ford, and Tony Krijnen
EXERCISE 1 Create
Groups
In this exercise, you create groups of different scopes and
types.
-
Log on to SERVER01 as Administrator. Open the Active
Directory Users And Computers snap-in and click the Groups OU
in the tree pane.
If the Sales group already exists, delete the
group.
-
Right-click the Groups OU, point to New, and then click
Group.
-
In the Group Name box, type Sales.
-
Select the Global group scope and Security group type.
Click OK.
-
Right-click the Sales group and choose
Properties.
-
On the Members tab, click Add. Type Jeff; Tony and click OK. Click OK to
close the Properties dialog box.
-
Repeat steps 2–4 to create two global security
groups named Marketing and Consultants.
-
Repeat steps 2–4 to create a domain local security group
named ACL_Sales Folder_Read.
-
Open the properties of the ACL_Sales Folder_Read
group.
-
On the Members tab, click Add. Type Sales;Marketing;Consultants and click
OK.
-
Click Add. Type David and
click OK. Click OK to close the Properties dialog box.
-
Open the Properties dialog box of the Marketing
group.
-
On the Members tab, click Add.
-
Type ACL_Sales
Folder_Read and click OK.
You are unable to add a domain local group to a global
group.
-
Close all open dialog boxes.
-
Create a folder named Sales on the C drive.
-
Right-click the Sales folder, click Properties, and then
click the Security tab.
-
Click Edit, and then click Add.
-
Click Advanced, and then click Find Now.
Notice that by using a prefix for group names, such as
the ACL_ prefix for resource access
groups, you can find them quickly, grouped together at the top
of the list.
-
Close all open dialog boxes.
-
Switch to Active Directory Users And Computers,
right-click the Groups OU, click New, and then click
Group.
-
In the Group Name box, type Employees.
-
Select the Domain Local group scope and the Distribution
group type. Click OK.
EXERCISE 2 Convert Group Type and
Scope
In this exercise, you learn how to convert group type and
scope.
-
Right-click the Employees group and choose
Properties.
-
Change the group type to Security. Click Apply.
Consider: Can you change the group scope from Domain
Local to Global? How?
-
Change the group scope to Universal. Click Apply.
-
Change the group scope to Global. Click Apply.
-
Click OK to close the Properties dialog box.
