Group Scope

Before we jump to creating and managing groups, we need to look at group types and scopes. Table 8-1 compares group scopes available in Windows Server 2008.

Do not confuse domain local groups with local groups on member servers and workstations in your network. Local groups on workstations and member servers have no relation to the domain functional level and will always have only local machine permissions scope. You cannot create any other group type locally. These "computer" local groups are created in the SAM security database using the Computer Management snap-in, as opposed to domain local groups, which are created in Active Directory by means of the Active Directory Users and Computers snap-in.

Domain local groups were designed primarily to be used in defining permissions in discretionary access control lists (DACLs), which are maintained for every object.

^able^-j

Group Scopes

Group

Domain Functional Level

Group Membership

Permissions Scope

Domain local group

Any level

The domain local group can contain user/ computer accounts, local groups, universal groups, and global groups from any domain in the forest.

Domain local groups can be used to assign permissions to resources in the domain where these groups are defined.

Global group

Any level

Global groups can only contain security principal members from the same domain where they are defined.

Global groups can be used to assign permissions to resources in the same domain where they are defined, and can be added to other groups in other domains where implicit or external trust relationships exist.

Universal group

Any level

Universal groups can contain security principals from any domain in the forest.

Universal groups can be used to assign permissions to resources anywhere in the forest and trusting domains.

The entries outline which security principal has what kind of access to the object in question. Domain local groups have domain scope, meaning they can be assigned to a DACL within the domain that they were created in.

When you need to add several people to a resource ACL, one of the approaches is to create a domain local group for this purpose and add accounts to the group; then use this domain local group to assign specific permissions to specific objects in the domain.

This approach is reasonable for single-domain environments but is not recommended by Microsoft for bigger, more complex environments. If domain local groups are used as resource groups in a permissioning model, they will be visible in AD DS, and their quantity and management may quickly mushroom out of control. It may make more sense to use local groups on resource servers instead.

Unlike domain local groups, global groups have a wider scope. They can be added to domain local groups anywhere in the forest or trusting domains, much like universal groups. Generally, it is not recommended to use domain local groups for the purpose of managing access to individual resources that are not hosted on domain controllers. For example, if you have a file and print server, you would want to create local groups on that server, and determine who can access the files and printer queue by considering who is the member of those local groups. Extensive permissioning through domain local groups may result in overpopulating Active Directory with role-based groups that should really be located on servers hosting resources.

Global groups can contain security principals only from the domain where they were defined, and they should contain users that require the same level of access to certain resources. Global groups cannot nest domain local groups but can nest other global groups. Administrators in trusting domains can add global groups from trusted domains to domain local groups or directly into resource ACLs in their domains. To continue with our example, instead of adding users to the domain local group on an individual basis, the recommended practice suggests that you should add these users to a global group, then add the global group to a domain local group, and use this domain local group to define permissions in resource ACLs.

Universal groups can contain security principals from any domain and also be assigned permissions in any domain, provided there is a trust relationship between the domains in question. Infrastructures of small organizations can use universal groups to simplify their group nesting and strategy. Large organizations can leverage universal groups to simplify permissions management through more flexible user organization. Note that extensive use of universal groups may result in increased use of the global catalog. This is because universal groups can contain security principals from other domains. To obtain required information, the authenticating domain controller need to consult the global catalog.

Was this article helpful?

+4 0
The Ultimate Computer Repair Guide

The Ultimate Computer Repair Guide

Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.

Get My Free Ebook


Responses

  • ruby
    What are the different types of group scopes in windows 2008?
    9 years ago
  • lukas
    Which group scope can be assigned permissions in any domain or forest?
    9 years ago
  • Michael
    What is the recommended practice for domain local groups?
    9 years ago
  • marja
    What is group scope in windows server 2008?
    7 years ago
  • leon
    Which of the following are types of group scopes found in windows server 2008?
    1 year ago
  • eligio pisano
    How to assign scopes on server 2008 groups?
    1 year ago
  • biniam
    Which of the following is NOT a type of group scope found in Server 2008?
    4 months ago

Post a comment