Groups are an important class of object because they collect users, computers, and other
groups to create a single point of management.
The most straightforward and common use of a group is to grant permissions to a shared folder. A security group is a security principal with a security identifier (SID) and a member
attribute that identifies members—users, computers, and other groups. If a group has Read
access to a folder, for example, any of the group’s members can read the folder. You do not
have to grant Read access to each individual member—you can manage access to the folder
simply by adding and removing members of the group.

Challenges of Managing Without Groups
-Imagine that all of the 100 users in the sales department require Read-level access to a shared folder called Sales on a server. Assigning permissions to each user individually is not a manageable solution. When new salespeople are hired, you must add the new accounts to the access control list (ACL) of the folder. When accounts are deleted, you must remove the permissions from the ACL to avoid an Account Unknown entry on the ACL (as shown in Figure 4-1), which results from a SID on the ACL that refers to an account that cannot be resolved.

70-640-f36

Figure 4-1 Access management without groups

– Imagine now that all of the 100 users in the sales department require Read access to three shared folders on three different servers; the management difficulty just increased significantly. How many permissions would you have to apply just to configure access to three folders on three different servers for 100 users? 300!

When you manage permissions by adding and removing identities to and from an ACL,it becomes difficult to answer the question, “Who can read the Sales folder?” To answer the question, you must reverse engineer the ACL. And, in the broader example, if the Sales folders are distributed across three servers, you would have to evaluate three separate ACLs to answer the question.

Groups Add Manageability
The example presented in the previous may seem extreme, because you have no doubt learned that although assigning permissions to a resource for an individual identity—user or computer—is possible, the best is to assign a single permission to a group and then manage access to the resource simply by changing the membership of the group.
So, to continue the example, you could create a group called Sales and assign the group Allow Read permission on the Sales folder. This implementation is shown in Figure 4-2.

70-640-f37

You now have a single point of management. The Sales group effectively manages access
to the shared folder. You can add new sales users to the group, and they will gain access to
the shared folder. When you delete an account, it is automatically deleted from the group, so
you will not have irresolvable SIDs on your ACL. It is also easier to answer the question, “Who
can read the Sales folder?” You can simply enumerate the membership of the Sales group.
The Sales group has become the focus of access management tasks.

    There’s an extra benefit: Your ACL remains stable because the Sales group has Allow Read permission, so your backups will be easier. When you change the ACL of a folder, the ACL propagates to all child files and folders, setting the Archive flag and thereby requiring a backup of all files, even if the contents of the files have not changed.

Groups Add Scalability
If the sales users require Read access to three folders on three separate servers, you could
assign the Sales group Allow Read permission on each of the three folders. After you assign
the three permissions, the Sales group provides a single point of management for resource
access, as shown in Figure 4-3.
The Sales group effectively manages access to all three shared folders. You can add new sales users to the group, and they will gain access to the three shared folders on the three servers. When you delete an account, it is automatically deleted from the group, so you will not have irresolvable SIDs on your ACLs.

70-640-f38

One Type of Group Is Not Enough
Imagine now that it is not only salespeople who require Read access to the folders. The executives, the marketing department employees, and the sales consultant hired by your organization also require Read permission to the same folders.
You could add those groups to the ACL of the folders, granting each of them Allow Read permission, but soon you would have an ACL with multiple permissions, this time assigning
the Allow Read permission to multiple groups instead of multiple users. This is shown in Figure 4-4.

70-640-f39

Figure 4-4 One kind of group is not enough to efficiently manage permissions

To give the three groups and one user permission to the three folders on the three servers, you would have to add 12 permissions! The next group that required access would require three more changes to grant permissions to the ACLs of the three shared folders.
What if eight users who are not salespeople, marketing employees, or executives have a business need for Read access to the three folders? Do you add their individual user accounts to the ACLs? If so, that’s 24 more permissions to add and manage!
You can see that using only one type of group—a role group that defines the business roles of users—quickly becomes an ineffective way of enabling management of access to the three folders. If the management rule suggests that three roles and nine additional users require access to the resource, you are assigning a total of 36 permissions on ACLs.
It becomes very difficult to maintain compliance and to audit. Even simple questions such as,
“Can you tell me every user who can read the Sales folders?” become difficult to answer.

Role-Based Management: Role Groups and Rule Groups
The solution is to recognize that you must address two management tasks to effectively manage this scenario: You must manage the users as collections, based on their business roles, and, separately, you must manage access to the three folders.
The three folders are also a collection of items: They are a single resource—a collection of Sales folders—that just happens to be distributed across three folders on three servers.
And you are trying to manage Read access to that resource. You need a single point of management with which to manage access to the resource.

This requires another group—a group that represents Read access to the three folders on the three servers. Imagine that you create a group called ACL_Sales Folders_Read. This group will be assigned the Allow Read permission on the three folders. The Sales, Marketing, and Executives groups, along with the individual users, will all be members of the ACL_Sales
Folders_Read group. You assign only three permissions: one on each folder, granting Read
access to the ACL_Sales Folders_Read group. This is shown in Figure 4-5.

70-640-f40

The ACL_Sales Folders_Read group becomes the focus of access management. As additional
groups or users require access to the folders, you add them to that group. It also becomes
much easier to report who has access to the folders. Instead of having to examine the ACLs on
each of the three folders, you simply examine the membership of the ACL_Sales Folders_Read
group.

To effectively manage even a slightly complex enterprise, you need groups that perform two distinct purposes:
Groups that define roles These groups, referred to as role groups, contain users, computers, and other role groups based on common business characteristics such as location and job type.

Groups that define management rules These groups, referred to as rule groups, define how an enterprise resource is managed.

     This approach to managing the enterprise with groups is called role-based management.
You define roles of users based on business characteristics (for example, department or division affiliation such as sales, marketing, and executives), and you define management rules
(for example, the rule that manages which roles and individuals can access the three folders).

     You can achieve both management tasks by using groups in a directory. Roles are represented by groups that contain users, computers, and other roles. That’s right, roles can include other roles—for example, a Managers role might include the Sales Managers, Finance Managers, and Production Managers roles. Management rules, such as the rule that defines and manages Read access to the three folders, are represented by groups as well. Rule groups contain roles and, occasionally, individual users or computers such as the sales consultant and
eight other users in the example.

The key takeaway is that groups serve two distinct purposes: one group defines the role, and another defines how a resource is managed.

To achieve manageability of an enterprise of any size or complexity, you must manage groups effectively and have an infrastructure of groups that provide single points of management for roles and rules. That means, technically, that you will need groups that can include as members users, computers, other groups, and, possibly, security principals from other domains.
For more information about role-based management, see Windows Administration Resource Kit: Productivity Solutions for IT Professionals.