Windows Server 2008 : Designing the Active Directory Administrative Model (part 2) - Using Group Strategy to Delegate Management Tasks

2. Using Group Strategy to Delegate Management Tasks

A user to whom you delegate a specific management task or set of tasks is known as a management stakeholder. Such users can be enterprise administrators who can perform tasks across multiple domains or multiple forests if the appropriate forest trusts are configured. However, most day-to-day administration in a well-organized enterprise network is carried out by users who do not have administrative rights to an entire domain, forest, or multiple forests. Instead, these users have sufficient rights to carry out specifically defined tasks, typically within a single OU and any child OUs. This follows the principles of autonomy (stakeholders can perform predefined tasks) and isolation (stakeholders can perform only the tasks that are predefined) that were discussed earlier in this lesson.

Stakeholders might be delegated rights to determine who in the organization has permission to read, write, and delete data in a shared folder on a file server. They might be delegated rights to reset passwords in a departmental OU so that they can deal with the situation when a user forgets a password, without needing to call in an administrator. An administrator can be delegated the rights to create and change the membership of a global distribution group and, hence, to determine the membership of a mailing list but have no rights to reconfigure security policies.

A responsible member of staff who is nevertheless not an administrator might be delegated permission to configure a member server as an RODC on a specified site. An administrator at a remote location might be able to configure servers at that location and restore a server from backup but have no rights at other locations. A domain administrator might have rights to a specific domain but not to any of the domains in a separate forest in the enterprise.

Typically, the rights and permissions of stakeholders are conferred through membership of security groups. It is possible to give an individual user rights, but this is bad practice. Familiarize yourself with the built-in domain-wide local security groups that confer limited rights such as Account Operators and Backup Operators. Figure 1 shows the built-in local security groups in the Builtin Active Directory container. You cannot change the group type or scope of built-in local security groups.

Figure 1. Built-in local security groups

If you open Group Policy Management Console, look at Default Domain Policy GPO, and access the Back Up Files And Directories user right, you will see on the Explain tab that Backup Operators is one of the security groups that has that right. Figure 2 shows this tab.

You allocate rights to security groups in Default Domain Policy GPO, in Default Domain Controllers GPO, or in GPOs linked to specific OUs. For example, Figure 3 shows the Back Up Files And Directories user right being allocated to the Sample Group security group (which was created to illustrate this operation and is not a built-in group).

This example is a reminder that to allocate a user right to a security group, you add the group to the user right in a GPO. This is a task you would delegate, but you need to bear the process in mind when you are planning group strategy. You need to keep group strategy as simple as possible. For example, if you created the Sample Group to carry out backup operations in the domain, this would almost certainly be bad design because you already have the built-in Backup Operators group to do this. However, if you want a group that can back up files and directories only in a single OU and give the members of that group no rights other than to that OU, creating a domain local group is a valid strategy.

Allocate user rights to domain local security groups. You can allocate rights to global security groups, universal groups, and even to individual users, but this is bad practice. By the same token, you should not add users directly to local groups. You learned this rule in your very first days of training to be an administrator. Now that you are an experienced administrator looking at high-level planning tasks, the rule is every bit as important.

Add users to global groups. Nest global groups in other global groups. If you use universal groups, add global groups (not users) to universal groups. Add global and universal groups to domain local groups. Assign rights to domain local groups.

Figure 4 shows the domain local security groups in the contoso.internal domain. These are installed with AD DS or created during configuration operations, for example, when a computer account for an RODC is created in a domain.Some domain local security groups can be changed to universal security groups, such as the Allowed RODC Password Replication Group, while others, such as the Cert Publishers group, cannot.

Figure 4. Domain local security groups

This functionality is determined by whether the operation of a group is confined within the boundaries of a domain (such as publishing certificates) or whether they can cross domains. (Branch-office users in several domains can have their passwords replicated to RODCs for local authentication.) You can create additional domain local security groups and assign them rights in GPOs linked to the domain, to the Domain Controllers OU, or to other OUs in your planned organizational structure.

Figure 5 shows the global security groups created automatically when AD DS was installed to create the contoso.internal domain, plus the DnsUpdateProxy group that was created when the default DNS installation for a new domain was specified. The Read-Only Domain Controllers group was created when an RODC computer account was configured, and the RODC_Installers group was created manually. These last two groups will probably not be present on your DC. The DnsUpdateProxy group can be converted to a universal group. The other automatically created groups cannot be.

Figure 5. Global security groups

It is important to remember that even an apparently powerful group such as Domain Admins has no directly allocated user rights but instead gets its rights through membership in the Administrators built-in local group. You can allocate rights directly to a global security group, but it is bad practice to do so.

Figure 6 shows the universal security groups created automatically when AD DS was installed to create the contoso.internal domain, plus the Enterprise Read-Only Domain Controllers group that was created when an RODC computer account was configured. Universal groups can contain users or (preferably) global security groups from multiple domains and can be allocated rights and permissions across domains. If forest trusts are set up correctly, they can operate across forests.

Figure 6. Universal security groups

To an enterprise administrator, universal groups might seem at first to provide an easy answer to cross-domain and cross-forest design, but beware. Universal groups need to be replicated across domains and forests, typically over slow WAN links. They can increase network traffic and thus reduce performance.

Microsoft recommends using as few universal groups as possible. With careful planning, you can do most of what you want to do with global and domain local groups. If you must use a universal group, do not add users. Every time the group membership changes, this triggers more replication traffic. Use only global groups, for example, the Domain Admins group from each of your domains, as members of a universal group. Even if the membership of a Domain Admins group changes, the membership of the universal group—that contains groups and not individual users—remains the same.

Management Roles

The previous discussion in this lesson has shown that an individual user right in a GPO can be allocated to a user or group. This can be a tedious procedure when extensive rights configuration is required. Roles are collections of rights and permissions, and you should use them in your planning rather than relying on individual rights. For example, Server Manager is a role that consists of a number of rights such as logging on to servers interactively and configuring servers. In general, a role is implemented by a built-in or domain local security group.

Microsoft recommends a number of roles for service management. These role recommendations take into account defined sets of logically related administrative tasks and the security sensitivity and impact of these tasks. The following is the set of recommended roles for delegating service management:

• Forest Configuration Operators

• Domain Configuration Operators

• Security Policy Administrators

• Service Administration Managers

• DC Administrators

• Backup Operators

• Schema Administrators

• Replication Management Administrators

• Replication Monitoring Operators

• DNS Administrators

In addition, Microsoft has engineered a set of recommended roles for delegating data management. These role recommendations take into account the sets of logically related administrative tasks and the security sensitivity and impact of these tasks. The following is the set of recommended roles for delegating data management:

• Business Unit Administrators

• Account Administrators

• Workstation Administrators

• Server Operators

• Resource Administrators

• Security Group Administrators

• Help Desk Operators

• Application-Specific Administrators

Planning Forest-Level Trusts

In the days before AD DS, domain administrators needed to know about trusts. However, with the full-trust Active Directory model, every domain in a single forest trusts every other domain. Trusts are typically created when your enterprise contains several forests, and cross-forest administration is definitely a task for the enterprise administrator. For this reason, this lesson discusses forest trusts in some depth.

A forest trust (or forest-level trust) allows every domain in one forest to trust every domain in a second forest. Forest trusts can be one-way incoming, one-way outgoing, or two-way. For example, you can configure all the domains in Forest A to trust all the domains in Forest B by creating a one-way trust in either Forest B or Forest A. If, in addition, you want all the domains in Forest B to trust all the domains in Forest A, you need to create a two-way trust.

You can use forest trusts with partner or closely associated organizations. For example, Contoso, Ltd., and Litware, Inc., have merged but do not choose to amalgamate their Active Directory structures in a single forest. Instead, you are asked to plan a forest trust to give employees of one organization rights and permissions in the other.

Forest trusts can form part of an acquisition or takeover strategy. Northwind Traders has acquired Coho Winery. The eventual plan is to reorganize the domain structures of both companies into a single forest, but until this process is complete, you might plan a forest trust between the organizations.

You can also use forest trusts for Active Directory isolation. You might, for example, want to run Exchange Server 2007 as part of a migration strategy to try out the new features and familiarize your technical staff. However, you do not want to install Exchange Server 2007 into your production forest because this could affect your current Exchange Server 2003 deployment. You can create a separate forest in which you can run Exchange Server 2007 but access resources in your production forest while doing so by setting up a forest trust.

Planning Trust Type and Direction

The most common type of trust that operates across forests is the forest trust, and this is the type of trust discussed in this lesson. You should, however, be aware of the other types of trusts that can be set up with entities outside your forest. These include the following:

• Shortcut trust A forest trust will enable any domain in one forest to trust any domain in another forest. However, if forests are complex, with several layers of child domains, it might take some time for a client in a child domain to locate resources in a child domain in another forest, especially when the operation happens over a WAN link. If users in one child domain frequently need to access resources in another child domain in another forest, you might decide to create a shortcut trust between the two domains.

• External trust You set up an external trust when a domain within your forest requires a trust relationship with a domain that does not belong to a forest. Typically, external trusts are used when migrating resources from Microsoft Windows NT domains, many of which still exist. Windows NT does not use the concept of forests, and a Windows NT domain is a self-contained, autonomous unit. If you plan to migrate resources from a Windows NT domain into an existing Active Directory forest, you can establish an external trust between one of the Active Directory domains and the Windows NT domain.

• Realm trust If a UNIX realm uses Kerberos authentication, you can create a realm trust between a Windows domain and a UNIX realm. This is similar to an external trust except that it is between a Windows domain and a UNIX realm.

When you have selected the type of trust you require—typically a forest trust because shortcut, external, and realm trusts are used in specific situations—you then need to decide whether the trust is one-way or two-way and, if the former, what the trust direction is. One-way trusts can be incoming or outgoing.

If users in Forest A must access resources in Forest B, and users in Forest B must access resources in Forest A, you need to create a two-way trust. Because this is bidirectional, you do not need to specify a direction.

If, however, users in Forest A require access to resources in Forest B, but users in Forest B do not require access to resources in Forest A, Forest A is the trusted forest and Forest B the trusting or resource forest. Forest B trusts the users in Forest A and allows them to access its resources. If you are creating a one-way forest trust in a resource forest, it is an incoming trust. If you are creating a one-way forest trust in a trusted forest, it is an outgoing trust.

Imagine the trust as an arrow. The resources are at the point of the arrow. The users that are trusted to use these resources are at the other end. Figure 7 shows this relationship. The arrow is incoming at the trusting (resource) forest and outgoing at the trusted forest.

Figure 7. One-way forest trust relationship

Creating Forest Trusts

Before you create a forest trust, ensure that the forest functional level of both forests is either Windows Server 2003 or Windows Server 2008.Your next step is to ensure that each forest’s root domain can access the root domain of the other forest. You need to create the required DNS records and use the nslookup tool to ensure that you can resolve domain names in the other forest. You also need to know the username and password for an enterprise administrator account (an administrator account in the root domain) in each forest unless you are setting up only one side of the trust, and an administrator in the other forest is setting up the other end. You create a forest trust in this lesson’s practice.

Planning Data Management

In many enterprise organizations, the Active Directory rights administration structure is not the main concern of the majority of users. They are not concerned about who can configure what. They are concerned about how their data is administered and whether they have the appropriate permissions to read, update, and delete files. A list of data management roles was given earlier in this lesson. It remains only to discuss group management in this context.

Suppose, for example, you have a shared folder on a server called Data Files. In practice, this will probably be a data structure, and you could plan whether to block permission inheritance on subfolders. Your administrators can configure share and NTFS permissions on the folder or folder tree through the Sharing and Security tabs. On the Security tab shown in Figure 8, Sample Group has the Modify permission on the folder. Standard users can read the files.

You can delegate the management of Sample Group to one of its members. For example, Figure 9 shows the management of Sample Group delegated to Don Hall. Don can change the group membership.

The consequences of this configuration are significant. Don Hall is a standard user with no administrative rights other than the delegated right to manage the Sample Group membership. He cannot set permissions. He cannot manage any other groups. The permissions on the Data Files folder have been set by an administrator. Members of Sample Group have Modify permission. Don cannot change this.

However, he can change the membership of Sample Group. So, safely, and without allocating any administrative rights to anything else, you have delegated to the user Don Hall the facility to determine who can modify files in the Data Files folder. This is a valuable technique. Use it in your planning.

Using Starter GPOs

Windows Server 2008 Group Policy introduces starter GPOs; incorporate these in your group strategy planning. Starter GPOs enable you to save baseline templates that you can use when you create new GPOs. You can also export starter GPOs to domains other than those in which they were created.

When you open Group Policy Management Console in Windows Server 2008, you can locate the Starter GPOs container in the left pane below a domain. Until you populate it, this container is empty. You create a starter GPO by right-clicking the Starter GPOs container and selecting New. You can configure GPOs in this container as you would configure any GPO except that only the Administrative Templates settings are available in both Computer Settings and User Settings.

When you create a new starter GPO, you are prompted to name it, and you can add a comment. You can edit your starter GPO and set the Administrative templates you require. When you create a starter GPO, you automatically create a new folder on the DC to which Group Policy Management Console is connected, by default in the C:\Windows\SYSVOL\domain \StarterGPOs path. This is replicated to other DCs as part of SYSVOL replication.

You can create a new (normal) GPO by using a starter GPO as a template by right-clicking the starter GPO and selecting New GPO From Starter GPO. Alternatively you can right-click the Group Policy Objects container, select New, and then specify a starter GPO from the Source Starter GPO drop-down list. You can access the same dialog box and specify a starter GPO if you right-click an OU (or the domain) and select Create A GPO In This Domain, And Link It Here. From a starter GPO, you can easily create multiple GPOs with the same baseline configuration. You need only to configure settings in these GPOs that are not contained in Administrative Templates.

Starter GPOs are not backed up when you choose Back Up All on the Group Policy Management Console Action menu or right-click the Group Policy Objects container and select Back Up All. You must back up starter GPOs separately by right-clicking the Starter GPOs container and selecting Back Up All or by right-clicking individual starter GPOs and selecting Back Up.

For example, a multinational organization is planning to install five separate Active Directory forests, one for each of its national offices in different countries. You are part of a central planning committee that has decided on 500 Group Policy settings that will be used throughout the enterprise. Each national office will then add its own unique Group Policy settings, to be applied locally.

In this scenario, you would plan to create a starter GPO that has the 500 Group Policy settings applied and distribute it to each national office. You can import and export starter GPOs, which facilitates the distribution of large numbers of policy settings to other environments. You could create a starter GPO in the root domain of each forest and manually apply the 500 settings or create a new GPO in the root domain and do the same. However, this requires significantly more effort than creating a single starter GPO and exporting it to each separate forest. You cannot link to GPOs in other forests.

Starter GPOs are not the answer to every Group Policy planning scenario. For example, your enterprise has a 20-domain Active Directory forest. You want to apply a consistent set of 300 Group Policy settings to every computer in the forest. When applying these settings in each domain, you do not want to link to GPOs outside that domain.

In this case, you do not need to use starter GPOs. You could instead create a GPO and apply the 300 Group Policy settings and copy the GPO to each of the 20 domains. It is possible to copy GPOs to domains within the same forest. Although you could create a starter GPO, export it, import it into each domain, and then create a new GPO based on the newly imported starter GPO, this is unnecessary and requires more administrative effort.

Another scenario in which you would use starter GPOs is when you are planning the Group Policy strategy for a new organization. Suppose, for example, you want to apply 350 Group Policy settings to each OU but then allow the GPO attached to each departmental OU to be modified and any of those basic settings to be changed if departmental managers request it.

In this case, you would create a starter GPO and apply the 350 basic Group Policy settings. You would create a new GPO for each OU based on the starter GPO and apply each new GPO to the appropriate OU. Changes can then be made to each individual GPO on a per-department basis later. This is not as easily accomplished when you link a single GPO to each OU.

You can view the settings of a starter GPO by selecting it in Group Policy Management Console. You can add comments to each starter GPO, explaining its properties, and use keyword filters to locate appropriate starter GPOs when necessary.

Using Group Policy Modeling and Results

You or one of your administrators can use the Group Policy Modeling node of Group Policy Management Console to verify that planned Group Policy settings have been correctly configured prior to deployment. You can delegate the rights to perform this operation to a member of your team by assigning that user account the Perform Group Policy Modeling Analysis permission.

You can use the Group Policy Modeling node to simulate policy settings that will be applied to a computer that is not currently logged on. You can use the Group Policy Results node (or Group Policy Results tool) to display policy settings that are applied to computers or users that have actually logged on. If you want to delegate the ability to use planning mode, a user account must be assigned the Perform Group Policy Modeling Analysis right. The Read Group Policy Results permission is required to use the Resultant Set of Policy (RSoP) snap-in tool in logging mode.

Using Migration Tables

You use migration tables when you import or copy a GPO from one domain or forest to another. These tables deal with domain and forest-specific information that specifies where the GPO was created. Such information does not apply to the domain or forest in which the GPO is being copied or imported. GPOs copied within the same domain, being backed up, or being restored to their original location do not require migration tables.

Your plan would include migration tables if you need to import GPOs that were created in another forest or to copy a GPO to another domain within the same forest. If you want to export a GPO from one forest to another and you need to account for all domain-specific settings that exist for the GPO that you want to export, you would use the Migration Table Editor tool to populate a migration table automatically with domain-specific Group Policy values so that these can be accounted for when the GPO is imported into the target environment.