The Golden Rules
One of the main challenges Windows administrators face is managing access to resources as efficiently as possible. A golden rule is to use groups instead of individual accounts to assign permissions to resources. Groups can create an abstraction layer in your authorization model that makes the assignment of permissions independent of account-level changes. This rule applies to Windows domains and standalone environments.
For example, in many organizations, users regularly switch between organizational roles. Each role typically requires specific permissions to Windows resources. In AD, you can create groups for organizational roles (e.g., help desk operators, developers) and assign resource permissions to these groups. If a user switches roles, you simply need to make that person's account a member of the associated group. This practice is much more efficient than resetting the account's permissions so that the user can access the resources needed for the new role.
Here are some more golden rules you should follow when managing groups' access to resources:
- Use global groups to combine users, use domain local groups to set the permissions for the resources, then put the global groups into the domain local groups to apply the permission settings.
Although this is a Windows NT 4.0 rule that provides a workaround for missing NT 4.0 delegation capabilities and NT 4.0 domain database-size limitations, it still applies to multidomain Windows 2003 and Win2K forest environments. Group nesting and the choice of group scopes is less important in single-domain Windows 2003 and Win2K forest setups. In those cases, you must simply ensure that you don't assign permissions to users directly but rather use a group intermediary.
Your group nesting choices might also be influenced by two factors, the first of which is the ownership and sensitivity of the data being protected. When the data is very sensitive, the administrator responsible for the data must have complete control over who is being granted access to the data. Thus, it's best not to nest any groups. Instead, you need to use a single group to control membership and use the same group to grant permissions to the resource. However, that's not the best solution when many users need access to a specific resource and the resource owner doesn't want to or can't control every user's membership to the respective group. In this case, it makes sense to have several groups so that other administrators can self-manage their users in their specific groups, then nest these groups in another group that grants permissions for the resource.
The second factor that can affect your decision on whether to nest groups is the recoverability of AD group memberships after the accidental deletion of AD objects. Memberships to domain local groups are the most difficult to recover when their members reside in a different domain.
- In general, I recommend using domain local groups instead of system local groups for domain environments. When you use system local groups, you lose the benefits of having a Windows domain: namely, central control and accountability. You can't control system local groups through AD, and they don't show up in a user account's group membership list in the Active Directory Users and Computers snap-in. In addition, system local group membership changes are logged to a local machine's security event log and not to the DC's event log.
One notable exception to this rule is when you have large AD environments that require numerous local groups. Unlike AD groups, users' system local group memberships aren't expanded at logon and don't affect the user Kerberos ticket size. So, in this situation, you might want to use system local groups instead of domain local groups.
- Use universal groups to give users access to resources that are spread across multiple domains. To do so, put global groups into universal groups, put the universal groups into domain local groups, then use the domain local groups to set permissions for resources.
- Use universal groups when a group's membership is close to being static. When a group's membership changes frequently, use a global group intermediary by adding the users to a global group, then adding the global group to a universal group. Universal groups cause more network traffic in multidomain environments because universal group memberships are stored in the GC, which is replicated forestwide.
Note that this rule applies only to Windows 2003 ADs and Win2K ADs that aren't at the native Windows 2003 forest functional level. In a native Windows 2003 forest, AD supports a new feature called linked-value replication (LVR), which ensures that only group membership changes (and not the entire group membership list) are replicated between DCs when a group's membership is modified. This rule also doesn't apply to multidomain environments that include Exchange servers, which need to use universal distribution groups. In that case, you shouldn't use global group intermediaries because Exchange servers can't expand the membership of global groups defined in foreign domains.
Besides following these golden rules, I recommend that, in general, you try to create as few groups as possible and try to limit the number of group-nesting levels. Fewer groups and group nesting levels help keep permissions simple and hence easier to troubleshoot if problems arise.
Indispensable Knowledge
Now you know the basics of AD groups and how to use them for efficiently managing resource permissions. This knowledge is indispensable for any AD administrator.