Outlining the Role of Groups in an AD DS Environment

The AD DS group structure, although not new in AD DS, provides an efficient mechanism for managing security on large numbers of users. Without groups to logically organize users, permissions on each object in a network would have to be set up manually on a per-user basis. This means that if an entire department needed access to a printer, each user would need to be manually entered into the permissions list of that printer. These tasks would make administration of security daunting.

The concept of groups was therefore devised to ease administration. If a large department needed access to that same printer, the department’s group need only be supplied the necessary permissions. This greatly eases security-based administration and has the added advantage of providing for ease of transition if specific users leave the company or are transferred to a different department. For example, imagine an administrator in charge of printing and her user account is a member of a group named Printer Admins, which has full administrative privilege to the printers. Now, if this user transfers to become an email administrator, for example, reassigning permissions to a new print administrator is as simple as adding that new user to the Printer Admins group. This capability greatly simplifies these types of situations.

Groups in AD DS work in the way that previous group structures, particularly in Windows NT, have worked, but with a few modifications to their design. Groups are divided into two categories: group type and group scope. There are two group types in AD DS: security and distribution. Essentially, a security group can be used to apply permissions to objects for the members of the group. A distribution group, on the other hand, cannot be used for permissions but is used instead to send mail to members of the group. Group scope in AD DS is likewise divided into several components, defined as follows:

. Machine local groups—Machine local groups, also known as simply “local groups,” can theoretically contain members from any trusted location. Users and groups in the local domain, as well as in other trusted domains and forests, can be included in this type of group. However, it is important to note that local groups allow resources to be accessed only on the machine where they are located, which greatly reduces their usability.

. Domain local groups—Domain local groups are essentially the same thing as local groups in Windows NT, and are used to administer resources located only on their own domain. They can contain users and groups from any other trusted domain. Most typically, these types of groups are used to grant access to resources for groups in different domains.

. Global groups—Global groups are on the opposite side from domain local groups. They can contain users only in the domain in which they exist but are used to grant access to resources in other trusted domains. These types of groups are best used to supply security membership to user accounts that share a similar function, such as the sales global group.

. Universal groups—Universal groups can contain users and groups from any domain in the forest and can grant access to any resource in the forest. Along with this added power come a few caveats. First, universal groups are available only in domains with a functional level of Windows 2000 Native or later. Second, all members of each universal group are stored in the global catalog, increasing the replication load. It is important to note, however, that universal group membership replication has been noticeably streamlined and optimized in Windows Server 2008 R2 because the membership is incrementally replicated.



Choosing Between OUs and Groups
Whereas OUs are primarily used to segregate administrative function, groups are useful for logical organization of security functions. Translated, OUs are created if there is a need for a department or physical location to have some certain type of administrative control over its own environment. For example, an organization with offices in Japan could organize its Japanese users into a separate OU and give a local administrator password-change and account-creation privileges for that OU. Groups, however, can be used to organize users to more easily apply security permissions. For example, you can create a group named Japanese Office Users that contains all the users from the office in Japan. Security permissions can then be established on objects in AD DS using that group. They could, for example, be given privileges to folders in the main corporate location, something that could not be done at the OU level.

Source of Information : Sams - Windows Server 2008 R2 Unleashed