|
|
A group is a collection of users, computers, and other entities. It can be a Windows Server 2003 built-in group or one created by the system administrator to conform to required attributes. Windows Server uses standard groups to reflect common attributes and tasks. These groups are built in to the OS so that common tasks can be assigned to users with a defined set of specifications and permissions. For instance, members of the Backup group will have access to tape drives, backup applications, and server folders that require backup.
Groups enforce security permissions or carry out distribution functions. They perform three main tasks:
Security groups primarily assign limited permissions to groups that need access to certain folders, applications, and computers.
Security groups also filter out the effect of group policies assigned to their members through a Group Policy Object (GPO). (See Chapter 8, "Group Policies.")
Distribution groups facilitate e-mail and contact information.
NOTE
Security groups determine how a GPO will be applied to an Active Directory container. Security groups do not add members to the container. They only restrict or enable current members to apply the GPO.
Rights and privileges are assigned at the group level. They represent an accumulation of the rights and privileges of all the groups to which a user belongs. Typically a user belongs to more than one group and therefore is granted or denied rights on that basis. To complicate this relationship, groups can be nested, overlapped, or completely independent. Say, for example, that three groups exist for an organizational unit, and that Group 3 members have been nested as automatic members of Group 1, while Group 2 is independent. Thus, User 1 has been assigned to Group 1 and Group 2. Since Group 3 is also a member of Group 1, User 2 inherits the rights of Group 1. On the other hand, User 2 is assigned to Group 2 and Group 3. The relationship between Groups 1 and 3 flows only one way. Therefore, User 1 does not become a member of Group 3 and so does not inherit any of that group's rights (Figure 7.28).
Let's take a look at the relationship from a slightly different perspective. A single user, computer, or group can belong to many groups. As shown in Figure 7.29, User 4 belongs to both Group 2 and Group 3. Because Group 1 is a member of Group 2, User 2 and User 5 have all rights associated with Groups 1 and 2. However, User 3, User 4, and Computer 2 do not receive Group 1 access rights.
A user's rights and privileges are cumulative. If a user is a member of two groups, one having Read and Write privileges and the other having Modify privileges, then the user has Read/Write/Modify rights on an object. By the same token, if any of the groups is denied rights to that object, the user will inherit that denial. The Deny access permission has priority over Allow access permissions. Any member of a group that has been denied permission to an object may not reinstate or counteract rights with membership to another group. (For greater detail, see Chapter 9, "Permissions Security, Folder Sharing, and Dfs.")
NOTE
It is good practice to keep group nesting to a minimum. The reason is visibility—a complicated group membership and permission structure makes it difficult to determine a user's rights. The Deny access permission should also be used sparingly. Overriding permissions that another group has established complicates the user's privilege level. Never use the Deny access permission with the Everyone or the Authenticated Users groups.
Proper planning of group structure affects maintainability, especially in an enterprise environment where multiple domains are involved. Windows Server 2003 groups are classified into one of three group scopes. Each deserves careful examination. Group membership is predicated on a group's intended scope. Underscoring this entire discussion are the assumptions that trust relationships exist between domains and that access is determined by the ACL of the network resource. The three group scopes follow:
Domain local groups assign access permissions to global domain groups for local domain resources.
Global groups provide access to resources in other trusted domains.
Universal groups grant access to resources in all trusted domains.
NOTE
Participating domain member servers can view all directory groups. However, group scope is not visible from them. Determining whether a security group is domain local or global must be done at a domain controller. It can be made easier by choosing a group name that identifies the group's scope. For example, instead of calling a group Engineering, call it Global Engineering or Local Engineering. This may prove troublesome, however, to users.
Members of domain local groups can be from any domain, although group permissions are assigned only to resources in the local domain. These groups may contain users, computers, or groups from any domain in the enterprise (Figure 7.30), and they also may contain individual users from their own domain.
The domain local group may be assigned permissions to any object in its domain. For example, in Figure 7.30 the Printer Group is the domain local group in Domain C and is assigned access rights to a printer in that domain only. The Printer Group may not be assigned permissions to objects outside its own domain. When implementing domain local groups, some additional guidelines should be followed. First, let's define global group.
NOTE
Although individual users may be assigned permissions to resources, this is not recommended.
Global group members may come only from the local domain, but they can be assigned permissions to resources in any trusted domain. They may also join any group in a trusted domain (Figure 7.31). For example, User 1 and Group 1, created in Domain A, are members of the global Accountants group, which is then assigned membership to Group 2 as well as permissions to a printer in Domain C and to a printer in its own Domain A. Again, this only demonstrates global group capabilities and does not reflect how they should be implemented.
NOTE
Although the Accountants' global domain group may be assigned permissions to resources, this is not recommended.
Universal group members are from any domain and may be assigned permissions to any resource in any trusted domain. The universal group has no restrictions on its member list and can be assigned to any object throughout the enterprise.
NOTE
Universal groups are allowed only in native-mode Windows Server 2003 environments. Native mode requires that all domain controllers be promoted to Windows Server 2003 Active Directory.
In addition to proper group scope, the group type must be determined. The two group types are
Security (security principals). These groups may be assigned to discretionary access control lists (DACLs) with associated permissions. They may also be used for e-mail distribution.
Distribution (not security principals). These groups cannot be assigned permissions through DACLs. They are intended only for e-mail distribution.
Since both security and distribution groups can be used for e-mail distribution, why do distribution groups exist? Optimization. When a user logs on to the domain, a security token is created that consists of the user's account SID and his group SIDs. Creating the token adds time to the logon process. Additionally, the security token is presented to any system a user accesses throughout the enterprise; and if it is large, it creates more network traffic. Distribution groups do not participate with security credentials and are not included in the user's security token. Adding a user to multiple distribution groups will not increase the size of the user's security token. Security groups may be converted to distribution groups and vice versa as long as the domain is operating in native mode. A mixed-mode environment does not support such conversions.
There is no such thing as a perfect world when defining groups in a heterogeneous computing environment. Windows Server 2003 supports several group scopes, and the system administrator must understand how to use them.
The Windows Server 2003 group scopes may seem confusing at first. Group management might be less complex if universal groups could always be implemented. However, universal scope has some practical drawbacks, chiefly that it works only in native mode. Most enterprise networks require downlevel compatibility. Because of the heterogeneity of a mixed Windows Server 2003 and Windows NT environment, the administrator must deal with global and domain local groups. Another consideration is that universal groups tax the network by passing group membership information between trusted domains and forests.
The Global Catalog stores domain local and global domain group names, and replicates changes made to group names to all GC servers. It maintains universal group membership on all GC servers as well. Whenever a member is added or removed from a universal group, the change is replicated throughout the trusted domain structure.
The recommended implementation for global and domain local groups involves further restrictions on group use. In general, object permissions should be assigned to domain local groups, whereas users and computer accounts should be placed in global groups. The global groups are then nested in domain local groups to gain access to network resources. To illustrate, we will look in depth at group implementation using default Windows Server 2003 groups.
Consider the case of a user named Joe Engineer with a logon name of jengineer. Joe's user account is created in a Windows Server 2003 domain and added to the global group Domain Users by default (Figure 7.32). The Domain Users group is a member of the domain local group Users, and the Users group is used to assign permissions to local objects within a system or domain.
The Administrator account behaves in a similar fashion. The Administrator is a member of the Domain Admins global group by default. The Domain Admins group is a member of the domain local group Administrators, and the Administrators group is included in ACLs for objects throughout the system.
Remember that these are default conditions and can be modified with the necessary authority. New security groups should be implemented the same way.
The Built-in folder contains predefined groups that reflect common functions. Figure 7.33 lists default domain local groups from the perspective of the Active Directory Users and Computers administrative snap-in tool. Although the membership and permissions associated with these groups (Table 7.6) can be modified, they cannot be deleted or removed from the system.
The Users folder (Figure 7.34) contains the default global domain groups (Table 7.7), which grant domain-wide privileges through domain local group memberships. Default domain local group membership grants global domain groups sweeping access rights throughout the network.
|
Group |
Permissions/Access Level |
|---|---|
|
Administrators |
Full control over the local computer system with all rights and capabilities; default members include the Domain Admins, Enterprise Admins, and Administrator accounts. |
|
Account Operators |
Administration of Domain Users. |
|
Backup Operators |
Back up and restore files on the local system regardless of permissions; also log on and shut down on the system. Group policies can restrict these permissions. |
|
Guests |
Limited logon/shutdown on the local system. |
|
Print Operators |
Administration of the local printers. |
|
Replicator |
Allows Active Directory replication functions; only persons supporting Replicator services should have membership. |
|
Server Operators |
Administration of the local system. |
|
Users |
Application execution, printer access, logon/shutdown/locking, and local group creation and modification; domain users are members by default. |
|
Group |
Permissions/Access Level |
|---|---|
|
Domain Admins |
Sweeping administrative privileges on all systems throughout the domain |
|
Domain Computers |
All domain computers |
|
Domain Controllers |
All domain controllers |
|
Domain Guests |
Membership to the Guests domain local group |
|
Domain Users |
Membership to the Users domain local group |
|
Enterprise Admins |
Membership to the Domain Admins group for each domain, granting forest-level privileges and rights |
|
Group Policy Creators Owners |
Members allowed to modify group policy |
|
Schema Admins |
Members permitted to modify the Active Directory schema |
Three group scopes imply three implementation strategies. Thus, a system administrator must decide the type of group a situation requires. Think about the resources the group needs to access. If you are assigning permission, a domain local group should be used. Users inside and outside your domain should be put in global groups and added to domain local groups to provide access within your local domain.
Another way to choose a group type is to ask two questions:
Is the purpose of the group to collect resources for user access?
Is the purpose of the group to collect users for resource access?
When collecting resources for user access, assign the same domain local group to each resource. Permissions are then assigned to an object by adding the domain local group to the object's ACL. When collecting users for resource access, put the common users in a global group, which is then given membership to the domain local group with access permissions. As a general rule, add permissions only to domain local groups or universal groups. This can be illustrated best by the example that follows.
A company maintaining two domains (Figure 7.35), called Entcert1.com and Entcert2.com, is trying to permit engineers from both domains access to some folders and software configuration applications, all of which reside in the Entcert2.com domain. (This example assumes that a trust relationship exists between the two forests permitting Entcert1.com access to resources in Entcert2.com. If you only have one domain, simply drop the Entcert1.com domain and Entcert1 Engineers group from the example.) Two global groups must first be created to manage users in Entcert1.com and Entcert2.com. Membership in these groups should be based on common resource needs.
To create the two global groups, take the following steps:
Open the Active Directory Users and Computers snap-in.
Right-click the targeted domain or, in this example, Entcert2.com. Select New 
Group. (You can also select the targeted domain and click New Group instead.)
Enter a name for the new group—in this example, Entcert2 Engineers (Figure 7.36).
Set the Group scope to Global.
Set the Group type to Security.
Click OK.
In the details pane, right-click the Entcert2 Engineers node and select Properties. Select the Member tab and click Add (Figure 7.37).
Find an available user account by entering part of a user's name in the box Enter the object names to select. Click Check Names and select an appropriate user account from the search result. Click OK to add the group member (Figure 7.38). Put all engineers who need access to the same resource in this group.
Create a new global group for engineers in the Entcert1.com domain, following the same procedure, and call it Entcert1 Engineers. (This is optional.)
Two global groups have now been created. They can be used to assign administrative responsibilities, allocate resources, and deny resources.
The Software Config domain local group will now be created and given permission to access the Software Configuration folder and a file, Application X.
From the Active Directory Users and Computers tool, right-click your domain node or, in this example, Entcert2.com. Select New Group. (You can also select the domain node (Entcert2) and then click on New Group instead.)
For the group name, type Software Config, for Group scope, select Domain local, and for Group type, select Security (Figure 7.39). Click OK.
Double-click the new group from the Active Directory Users and Computers snap-in and select the Members tab. Click Add. The Select Users, Contacts, Computers, or Groups dialog box appears (Figure 7.40).
Type Entcert as search criteria in the Enter the object names to select box and click Check Names. Select Entcert2 Engineers group from the available domain groups and users. Click OK.
You have successfully added one global group to a domain local group (optionally two). The member list for the domain local group Software Config should look like the one in Figure 7.41.
To create folders on your server to simulate the folders and applications to which engineers from Entcert1.com and Entcert2.com require access, use the procedure that follows:
Right-click My Computer and select Explorer. On an NTFS volume, create a folder called Software Configuration by selecting File New Folder.
Right-click Properties on the Software Configuration folder. Select the Sharing tab and click Share this folder.
Choose the Security tab and click Add. Choose the Software Config group and click OK.
Modify the Permissions for Software Config to allow and deny the appropriate permissions. In Figure 7.42, the engineers have been granted Full Control.
The Software Config group could also be added to an application object and permissions could be set to allow Read & Execute privileges for the Engineers group.
 |
|
|
| Top |