Microsoft KB Archive/326265

= Description of the Group Scopes That You Can Use to Help Secure Active Directory Objects =

PSS ID Number: 326265

Article Last Modified on 7/8/2003

-

The information in this article applies to:


 * Microsoft Windows 2000 Advanced Server
 * Microsoft Windows 2000 Server

-



This article was previously published under Q326265



SUMMARY
This article describes the different group scopes that you can use to help secure Microsoft Active Directory directory service objects. Before you decide on the group scope to use to help secure Active Directory objects, be aware of the uses, limitations, and recommendations for each group scope.

Note This article contains an overview of group scopes. It is not intended to be a detailed discussion of the topic.



Universal Groups
Groups that have a universal scope are referred to as universal groups. Universal groups have the following characteristics:
 * Universal groups are only available in native-mode domains.
 * The universal group and all the members this group are replicated to every global catalog server in the forest.
 * Universal groups contain other universal groups, global groups from any domain in the forest, and user accounts from any domain in the forest.
 * You can use universal groups to help secure resources in any domain in the forest.

Global Groups
Groups that have a global scope are referred to as global groups. Global groups have the following characteristics:
 * Global groups are available in mixed-mode domains and native-mode domains.
 * These groups only contain users from the domain where the group resides. Global groups can also contain other global groups from the same domain if the domain is a native-mode domain.
 * You can use global groups to help secure resources in any domain in the forest.

Domain Local Groups
Groups that have a domain local scope are referred to as global groups. Domain local groups have the following characteristics:
 * Domain local groups are available in mixed-mode domains and native-mode domains. However the functionality changes slightly depending on the mode of the domain.
 * These groups contain users from any domain in the forest, global groups from any domain in the forest, and universal groups. Domain local groups can also contain other domain local groups from the same domain if the domain is a native-mode domain.
 * You can use domain local groups to help secure resources in the domain where the domain local group was created.

Using Groups to Help Secure Active Directory Resources (Including Objects and Containers)
You can use universal groups to help secure Active Directory resources in any domain in the forest. The use of universal groups relies on a global catalog server to evaluate its membership list. If you use universal groups extensively, the size of your global catalog may increase. This size increase affects replication throughout the forest.

You can use global groups to help secure Active Directory resources in any domain in the forest. However, because global groups can only contain members from their own domain, you may have to create similar global groups in each domain to provide the appropriate functionality of those groups.

Use caution when you use domain local groups to help secure Active Directory objects. Even though you can use domain local groups to help secure Active Directory objects (and in some Active Directory deployments, the use of domain local groups may be preferred), Microsoft does not recommend that you use domain local groups to help secure Active Directory resources. A security risk may occur if you use domain local groups to help secure Active Directory resources. For example, if a user requests a level of access to an object such as an organizational unit, the user may be granted more access than you intended.

Objects in a domain are replicated to all global catalog servers in the forest. Each of these objects has an associated Access Control List (ACL). This ACL is also replicated. The ACL contains one or more Access Control Entries (ACE) that define the groups and users who are granted or denied access and the level of access that they are granted or denied. One characteristic of domain local groups is that they are not evaluated by global catalog servers in other domains. Domain local groups are only evaluated by domain controllers that are authoritative for the naming context where the domain local group was created. When a user tries to access an object on a global catalog server, if that object is in one of the read-only partitions that the global catalog server maintains, domain local groups are not evaluated when permissions to that object are being determined. Therefore, if you use domain local groups to help secure objects, if these object can be accessed on global catalog servers of a different domain from where the object was created, the level of access that is given to the user may be greater or less than what you intended. Fortunately this is only an issue when users access read-only objects from other domains. In this case, the highest level of access that can be granted is Read access. Write access permissions are only evaluated on domain controllers in the domain where the object was created, and domain local groups can always be correctly evaluated by these domain controllers.

Example 1
There is a domain local group in Root.com named DLG1. The Root.com domain has an organizational unit named Execs. The Execs organizational unit has default Read permissions for members of the Authenticated Users group. Additionally, the DLG1 domain local group is granted Write permissions to the Execs organizational unit. As a result, the members of the Authenticated Users group, and not the members in the DLG1 group, have Read permissions if they access the Execs organizational unit on DC1.root.com or DC2.child.root.com. The DLG1 domain local group has Read access to the Execs organizational unit if this group tries to access DC2.child.root.com. The DLG1 group has Write access to the Execs organizational unit if this group tries to access DC1.root.com. Because DC2.child.root.com only maintains a read-only copy of the Execs organizational unit, the use of domain local groups in this scenario does not affect the intended permissions. Whenever Write access is requested, the request is forwarded to DC1.root.com. Because DC1.root.com can evaluate the DLG1 domain local group, the correct access is granted.

Example 2
There is a domain local group in Root.com named DLG1. The Root.com domain has an organizational unit named Execs. The Execs organizational unit has default Read permissions for members of the Authenticated Users group. Additionally, the administrator has denied Read access for the DLG1domain local group. As a result, the access that is granted to the DLG1 domain local group may be inconsistent, depending on the global catalog server from where Read access is requested. If a member of DLG1 tries to access the Execs organizational unit on DC1.root.com, that member is denied access. If a member of DLG1 tries to access the Execs organizational unit on DC2.child.root.com, that member is granted Read access. This behavior occurs because the global catalog servers do not try to evaluate domain local groups from other domains. Therefore, the DLG1 domain local group has a higher level of access to a resource than the administrator intended.

Guidelines for Consistent Behavior of Domain Local Groups

 * Do not use domain local groups to deny permissions to Active Directory resources.
 * If you maintain the default Read permission for members of the Authenticated Users group and you grant a domain local group additional permissions to a domain resource, the use of domain local groups is consistent with what is intended. In this case, the members of the Authenticated Users group (including those members that are also in the domain local group) have Read access regardless of the domain controller or the global catalog server that is accessed. If a member of the domain local group is also a member of the Authenticated User group, this member is always granted at least Read access to the required resource. If additional access such as Modify is requested, it must be performed on a domain controller in the domain where the resource resides. Because the resource and the domain local group are in the same domain, the additional permissions are evaluated correctly.
 * Only use domain local groups to grant additional permissions to the default permissions that the members of the Authenticated User group have.

Keywords: kbinfo KB326265

Technology: kbwin2000AdvServ kbwin2000AdvServSearch kbwin2000Search kbwin2000Serv kbwin2000ServSearch kbWinAdvServSearch

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© 2004 Microsoft Corporation. All rights reserved.