This chapter is from the book
This chapter is from the book
This chapter is from the book
Groups
The idea of groups has been around in the Microsoft world for much longer than OUs have been. As with the OU concept, groups serve to logically organize users into an easily identifiable structure. However, there are some major differences in the way that groups function as opposed to OUs. Among these differences are the following:
Group Membership Viewable by Users—Whereas OU visibility is restricted to administrators using special administrative tools, groups can be viewed by all users engaged in domain activities. For example, users who are setting security on a local share can apply permissions to security groups that have been set up on the domain level.
Membership in Multiple Groups—OUs are similar to a file system's folder structure. In other words, a file can reside in only one folder or OU at a time. Group membership, however, is not exclusive. A user can become a member of any one of a number of groups, and her membership in that group can be changed at any time.
Groups as Security Principals—Each security group in Active Directory has a unique Security ID (SID) associated with it upon creation. OUs do not have associated Access Control Entries (ACEs) and consequently cannot be applied to object-level security. This is one of the most significant differences because security groups allow users to grant or deny security access to resources based on group membership. Note, however, that the exception to this is distribution groups, which are not used for security.
Mail-Enabled Group Functionality—Through distribution groups and (with the latest version of Microsoft Exchange) mail-enabled security groups, users can send a single e-mail to a group and have that e-mail distributed to all the members of that group. The groups themselves become distribution lists, while at the same time being available for security-based applications. This concept is elaborated further in the "Distribution Group Design" section later in this chapter.
Group Types: Security or Distribution
Groups in a Windows .NET Server 2003 come in two flavors: security and distribution. In addition, groups can be organized into different scopes: machine local, domain local, global, and universal.
Security Groups
The type of group that administrators are most familiar with is the security group. This type of group is used to apply permissions to resources en masse so that large groups of users can be administered more easily. Security groups can be established for each department in an organization. For example, users in the Marketing department can be given membership in a Marketing security group, as shown in Figure 6.3. This group is then allowed to have permissions on specific directories in the environment.
)
Figure
6.3 Security group permission sharing.
This concept should be familiar to anyone who is used to administering down-level Windows networks such as NT or Windows 2000. As you will soon see, however, some fundamental changes in Windows .NET Server 2003 change the way that these groups function.
As previously mentioned, security groups have a unique Security ID (SID) associated with them, much in the same way that individual users in Active Directory have an SID. The uniqueness of the SID is utilized to apply security to objects and resources in the domain. This concept also explains why you cannot simply delete and rename a group to have the same permissions that the old group previously maintained.
Distribution Groups
The concept of distribution groups in Windows .NET Server 2003 was introduced in Windows 2000 along with its implementation of Active Directory. Essentially, a distribution group is a group whose members are able to receive Simple Mail Transfer Protocol (SMTP) mail messages that are sent to the group. Any application that can use Active Directory for address book lookups can utilize this functionality in Windows .NET Server 2003.
Distribution groups are often confused with mail-enabled groups, a concept in environments with Exchange 2000. In addition, in most cases distribution groups are not utilized in environments without Exchange 2000 because their functionality is limited to infrastructures that can support them.
NOTE
In environments with Exchange 2000, distribution groups can be utilized to create e-mail distribution lists that cannot be utilized to apply security. However, if separation of security and e-mail functionality is not required, you can make security groups mail-enabled.
Mail-Enabled Groups
With the introduction of Exchange 2000 into an Active Directory environment comes a new concept: mail-enabled groups. These groups are essentially security groups that are referenced by an e-mail address, and can be used to send SMTP messages to the members of the group. This type of functionality becomes possible only with the inclusion of Exchange 2000 or higher. Exchange 2000 actually extends the forest schema to allow for Exchange-related information, such as SMTP addresses, to be associated with each group.
Most organizations will find that mail-enabled security groups satisfy most of their needs, both security-wise and e-mail–wise. For example, a single group called Marketing that contains all users in that department could also be mail-enabled to allow Exchange users to send e-mails to everyone in the department.
Group Scope
There are four primary scopes of groups in Active Directory. Each scope is used for different purposes, but all simply serve to ease administration and provide a way to view or perform functions on large groups of users at a time. The group scopes are as follows:
Machine local groups
Domain local groups
Global groups
Universal groups
Group scope can become one of the most confusing aspects of Active Directory, and it can often require a doctorate degree in Applied BioGroupology to sort it all out. However, if certain design criteria are applied to group membership and creation, the concept becomes more palatable.
Machine Local Groups
Machine local groups are essentially groups that are built into the operating system and can be applied only to objects local to the machine in which they exist. In other words, they are the default local groups such as Power Users, Administrators, and the like created on a standalone system. Before networking simplified administration, local groups were used to control access to the resources on a server. The downside to this approach was that users needed to have a separate user account on each machine that they wanted to access. In a domain environment, utilizing these groups for permissions is not recommended because the administrative overhead would be overwhelming.
NOTE
Domain controllers in an Active Directory forest do not contain local groups. When the dcpromo command is run on a server to promote it to a domain controller, all local groups and accounts are deleted in favor of domain accounts. Essentially, the local groups and users are replaced with a copy of the domain groups and users. Any special permissions using local users must be reapplied using domain accounts.
Domain Local Groups
Domain local groups, a term that may seem contradictory at first, are domain-level groups that can be used to establish permissions on resources in the domain in which they reside. Essentially, domain local groups are the evolution of the old Windows NT local groups.
Domain local groups can contain members from anywhere in an Active Directory forest or any trusted domain outside the forest. A domain local group can contain members from any of the following:
Global groups
User accounts
Universal groups (in AD Native mode only)
Other domain local groups (nested, in Native mode only)
Domain local groups are primarily used for access to resources because different domain local groups are created for each resource and then other accounts and/or groups are added to them. This helps to readily determine which users and groups have access to a resource.
Global Groups
Global groups are the reincarnation of the NT global group, but with slightly different characteristics. These groups can contain the following types of objects:
User accounts
Global groups from their own domain (Native mode only)
Global groups are primarily useful in sorting users into easily identifiable groupings and using them to apply permissions to resources. What separates global groups from universal groups, however, is that global groups stop their membership replication at the domain boundary, limiting replication outside the domain.
Universal Groups
The concept of universal groups was new with the release of Windows 2000 and has become even more useful in Windows .NET Server 2003. Universal groups are just that—universal. They can contain objects from any trusted domain and can be used to apply permissions to any resource in the domain.
Universal groups are available only in Native Windows .NET Server 2003 or Windows 2000 modes and cannot be used in Interim or Windows NT Mixed mode. This is because Windows NT4 backup domain controllers (BDCs) cannot replicate the functionality present in universal groups.
Although simply making all groups within a domain into universal groups may seem practical, the limiting factor has always been that membership in universal groups is replicated across the entire forest. To make matters worse, Windows 2000 Active Directory universal group objects contained a single multi-entry attribute that defined membership. This meant that any time membership was changed in a universal group, the entire group membership was re-replicated across the forest. Consequently, universal groups were limited in functionality.
Windows .NET Server 2003 introduces the concept of incremental universal group membership replication, which accomplishes replication of membership in universal groups on a member-by-member basis. This drastically reduces the replication effects that universal groups have on an environment and makes the concept of universal groups more feasible for distributed environments.