Windows 7 / Security and Privacy

---

Understanding the Scopes of Groups

Windows Server 2008 uses three group scopes: domain local, global, and universal. Each of these groups has a different scope that determines the types of objects that can be included as members of a group and the permissions and rights those objects can be granted. In practice, you will almost always use security groups, because they include distribution group functionality and are the only types of groups that have DACLs.

Domain Local Groups

Consider using domain local groups first when you are giving groups or users access to local domain resources. For instance, if you have a domain named northwind.com and you want users or groups in that local domain to access a shared folder in the northwind. com local domain, you could create a domain local group called SalesPersons, insert in the SalesPersons group the users and global groups you want to give access to the shared folder, and then assign the SalesPersons group permissions on the resource. Access policies for domain local groups are not stored in Active Directory. This means that they do not get replicated to the global catalog and thus queries performed on the global catalog will not return results from domain local groups. This is because domain local groups cannot be determined across domains.

Global Groups

Use global groups to give users or groups access to resources according to how they have been organized. For instance, users from the Marketing or Development departments could be put in separate global groups in order to simplify administration of their need to access resources like printers and network shares. Global groups can be nested in order to grant access to any domain in the forest.

Universal Groups

Universal groups have very few fundamental restrictions. Universal groups can be a tempting shortcut for administrators to use, because they can be used across domains in the forest. Memberships in universal groups can be drawn from any domain, and permissions can be set within any domain. However, using universal groups as your main method of grouping users, groups, and computers has a significant caveat.

Universal groups are stored in the global catalog, and whenever changes are made to a universal group, the changed properties must be replicated to other domain controllers configured as global catalog servers. The replication of individual property changes rather than entire objects is an improvement for Windows Server 2008 that should allow wider use of universal groups without causing network bottlenecks or slowed performance during authentication and global catalog changes.

Which Group Scope Should You Use?

There is a strategy in choosing when to use a group scope and which group scope to use. A common strategy is to organize user accounts into logical groups based on the permissions they need to access specific resources. In a business model, this often can be determined according to the department the user belongs to. For instance, the Development department of a software business may put all their developers in a Dev group, and then assign permissions to a network share to the Dev group. On the other hand, in a Windows Server 2008 environment it becomes more complex than this, because there are different scopes for groups. Furthermore, groups may contain not only users, but also computers and even other groups, and can be nested to any scale.

Some important constraints on group scope in Windows Server 2008 include the following:

• Universal groups are stored in the global catalog and replicated across the network. However, Windows Server 2008 has new features that allow caching of the global catalog and replication of only the changes in it.
• Global groups can be included in an object's security data structure only if that object is in the same domain as the global group. In Windows 2000 native functional level or higher, global groups can be nested in order to grant access to any domain in the forest.
• Domain local groups cannot be processed in other domains.

Group scope functionality and limitations include member inclusion and permissions. Table-4 lists how the three scopes function.

Table-4 How Group Scope Functions Using Windows Server 2003 and Higher Domain Functional Levels

Group	Member Inclusion	Permissions
Universal	You can include users, computer accounts, global groups, and universal groups from any domain.	Within any domain, universal groups can be added to other groups and granted permissions.
Global	You can put in a global group any user or computer account or other global groups from the same domain.	Global groups can be added to other global groups in any domain in the forest and assigned permissions.
Domain local	Same as universal groups, but you can also include domain local groups from the same domain.	Domain local groups can be added only to other domain local groups in the same domain and assigned permissions.

In native mode, Windows Server 2008 groups have nesting limitations that are dependent on the group scope. Limitations for nesting are listed in Table-5.

Table-5 Group Scope Nesting in Windows 2000 Native Functional Level

Group Type	Can Nest in Universal?	Can Nest in Global?	Can Nest in Domain Local?
Universal	No	Yes	Yes
Global	Yes	Yes (only in the same domain)	Yes
Domain local	No	No	No

Why Use Domain Local Groups?

Domain local groups are used when you want to give users, computers, or specific groups access to resources in a single local domain. In a domain local group, you can include other domain local groups with domain local scope, global groups, or universal groups. You can also include single accounts in the domain local group. However, including single user accounts can increase the amount of administration for you instead of reducing it, so unless management has specifically requested a special permission, this may not be the best route.

A common scenario for using domain local groups is to provide access to printers for members of a department (such as the Developers department).

In this scenario, you would use Active Directory Users And Computers:

1. Create a domain local group by right-clicking an OU, and then selecting New, Group.
2. Assign permissions to use the printer by adding the new domain local group to the printer by opening Control Panel, Printers And Faxes, then right-clicking Properties, selecting the Security tab, and fi nally adding the domain local group to the printer.
3. Create a global group.
4. Add the user accounts from the Development department to the global group.
5. Add the global group to the domain local group you created at the beginning.

This way, if you ever add a new printer, all you have to do is add access to it in the domain local group, and the developers automatically get access because their global group is part of the domain local group.

If a new domain is added, all you have to do to give the people in the new domain access to the printer is add the new global groups from the new domain to the domain local group.

Why Use Global Groups?

An important aspect of global groups is they are not replicated outside their own domain. They are not part of the global catalog replication. Thus, you should use global group membership for objects that need high regular maintenance or modifi cations. These changes will not be replicated across your network and thus will not slow network traffic over slow links. Therefore, a main reason to use global groups is to organize users with similar needs within a domain to give them access to resources. For instance, you have two domains, one in the United States, the other in India. In each domain you have developers. Because your business model requires that neither group of developers needs access to the other's source code, you could create two global groups, USA\Dev and India\Dev, and give the global groups permissions to different source code shares.

Why Use Universal Groups?

Using universal groups extends this idea so that users in groups of different domains may be able to access resources without affecting network traffic because of global catalog replication. By creating a universal group and adding global groups to it, you can give users from different domains in the forest access to the same resource. For instance, in the preceding scenario, a third group could be created for the developers, called UniDev. This would be a universal group to which you would add both global groups, USA\Dev and India\Dev, and assign permissions to perhaps even a second network share of source code that both groups of users must access. This is a good strategy, because if you add new user accounts to the global groups, the changes are not replicated to the global catalog and little if no impact to network traffic is incurred. However, be careful about changing memberships to universal groups, because those changes are replicated across all links to other domain controllers configured with global catalogs.