Active Directory 2008 : Managing an Enterprise with Groups (part 1) - Understanding the Importance of Groups

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.

The example presented in the previous section 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 practice 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 2.

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.

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 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.

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.

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.

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 5.

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:

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.