Windows Server 2008 : Designing the Active Directory Administrative Model (part 3) - Planning to Audit AD DS and Group Policy Compliance, Planning Organizational Structure

3. Planning to Audit AD DS and Group Policy Compliance

In Windows Server 2008, the global audit policy Audit Directory Service Access is enabled by default. This policy controls whether auditing for directory service events is enabled or disabled. You can configure this policy setting by modifying Default Domain Controllers Policy and then specifying whether to audit successes, audit failures, or not audit at all. You can control which operations to audit by modifying the system access control list (SACL) on an object. You can set a SACL on an AD DS object on the Security tab in that object’s Properties dialog box.

Plan how your administrators should configure audit policy. Enabling success or failure auditing is a straightforward procedure. Deciding which objects to audit; whether to audit success, failure, or both; and whether to record new and old values if changes are made is much more difficult. Auditing everything is never an option—too much information is as bad as too little. Your plan needs to be selective.

In Windows 2000 Server and Windows Server 2003, an administrator can specify only whether Active Directory directory service access is audited. Windows Server 2008 gives more granular control. Your auditing policy can include the following:

• Active Directory access

• Active Directory changes (old and new values)

• Active Directory replication

Auditing Active Directory replication is further subdivided so that you can choose two levels of auditing—normal or detailed.

For example, you are an enterprise administrator at Litware, Inc. Previously, on a Windows Server 2003 domain, the auditing options you could plan had limitations. You could determine that the attributes of an object in Active Directory had been changed but not what changes were made. If a change was erroneous, you relied on documentation maintained by your administration team to reverse or correct the alteration. Such documentation was seldom perfect.

Litware has recently upgraded its domain to Windows Server 2008. You can now plan your auditing procedures so that if a change is performed on an object attribute, AD DS logs the previous and current values of the attribute. Only the values that change as a result of the Modify operation are logged, so your administrators do not need to search through a long list of attribute values to find the change.

If a new object is created, AD DS logs the values of the attributes that are configured or added at the time of creation. Attributes that take default values are not logged. If an object is moved within a domain, your auditing policy can ensure that the previous and new locations are logged. When an object is moved to a different domain, a Create event is generated and logged on the DC in the target domain. If an object is undeleted, your auditing policy can identify the location to which the object is moved. If attributes are added, modified, or deleted during an Undelete operation, your administrators can determine the values of those attributes from the Security event log.

If auditing of Directory Service Changes is enabled, AD DS logs events in the Security event log when changes are made to objects that one of your administrators has set up for auditing. Table 1 lists these events.

Plan whether to react to such events and how to do so. By default, the events are logged in the Security event log, and members of the Domain Admins, Builtin\Administrators, and Enterprise Admins groups can view them by opening Event Viewer. However, you can design your auditing policy so that an event written to the Security event log initiates a task such as generating an alert or starting an executable program. An administrator can select the event in Event Viewer and choose Attach Task To This Event on the Action menu. Figure 10 shows this function.

Figure 10. Attaching a task to an AD DS Modify event

4. Planning Organizational Structure

When planning your organizational structure, one of your primary aims is to organize the logical design of your OU hierarchy so that it facilitates the management of Group Policy. This OU hierarchy need not mirror your enterprise’s departmental hierarchy. Instead, plan every OU so it has a defined purpose such as delegation of authority or the application of Group Policy. Business needs must drive the OU hierarchy. Plan to delegate administrative authority and designate groups of users to have control over the users and computers or other objects in an OU.

You can add users or groups to user rights policies in a GPO that links to an OU or OU hierarchy, as was discussed earlier in this lesson. You can also plan to delegate control of OUs. You do not need to delegate control of an OU, which is the smallest Active Directory container, to an administrative user. Many of the tasks that can be carried out within an OU are straightforward (for example, resetting passwords when users have forgotten them) and can be easily carried out by nonadministrative users. It is also relatively safe to delegate authority to an OU. Other than to child OUs, delegated authority over an OU does not give a user rights to any other part of AD DS.

Figure 11 shows the Delegation Of Control Wizard, which is currently delegating control of the Sample OU to Sample Group. You can plan a very simple delegation, such as the right to reset passwords and require users to change a password at next logon, to more advanced features such as the ability to link this OU to other GPOs.

Figure 11. Delegating control of an OU

Your planned organizational structure should link GPOs to sites, domains, and OUs to implement Group Policy settings as broadly or as narrowly in the organization as necessary. Keep in mind how Group Policy is applied when you plan the scope of application of Group Policy objects. You are probably aware of the following facts, but a spot of review never goes amiss:

• The policy settings in Group Policy objects are inherited and cumulative and apply to all users and computers in an Active Directory container.

• Group Policy objects are processed in the following order: local GPO, site, domain, and OU.

• By default, Group Policy inheritance is evaluated starting with the Active Directory container farthest from the computer or user object. The Active Directory container closest to the computer or user overrides Group Policy set in a higher-level Active Directory container unless you enable the Enforced option for that GPO.

• If you link more than one GPO to an Active Directory container, the GPO processing order (priority) is as follows: the GPO highest in the Group Policy Object Links list, displayed in the Group Policy section of the Active Directory container’s Properties page, has precedence by default. If you enable the Enforced option in one or more of the GPOs, the highest GPO that is set to Enforced takes precedence.

Practice: Creating a Forest Trust

In this practice, you create a forest trust between the contoso.internal and litware.internal forests. You then experiment with adding groups from one forest to groups in another.

▸ Exercise Create a Forest Trust

You need two forests on your network before you can carry out this exercise. Ensure that the forest functional levels of your two forests are at least Windows Server 2003. You might need to raise the domain functional levels of your domains before you can raise forest functional levels. You should also create a conditional forwarder for litware.internal on Glasgow and a conditional forwarder for contoso.internal on Brisbane, using the servers’ respective DNS consoles. If you are unsure how to perform these tasks, refer to the Windows Server 2008 Help files.

1.	Log on to the Glasgow DC with the Kim_Akers account.
2.	Open Active Directory Domains And Trusts from Administrative Tools. Click Continue to clear the User Account Control (UAC) dialog box and ensure that the tool is connected to the Glasgow DC in the contoso.internal domain.
3.	Right-click the contoso.internal domain in the tool’s left pane, and choose Properties. On the Trusts tab, click New Trust as shown in Figure 12 to launch the New Trust Wizard. Click Next. Figure 12. Accessing the New Trust Wizard The wizard prompts you to enter the domain, forest, or realm name of the trust.
4.	Enter the domain name (litware.internal) of the root domain in the forest with which you want to establish the trust, as shown in Figure 13. Figure 13. Specifying the trust endpoint
5.	Click Next. The wizard asks whether you are creating a realm trust or a trust with a Windows domain.
6.	Select the Trust With A Windows Domain option as shown in Figure 14, and click Next. Figure 14. Specifying a Windows domain trust You are given the choice between creating a forest trust or an external trust.
7.	Choose the Forest Trust option, and click Next. At this point, the wizard asks you whether you want to establish a one-way incoming, one-way outgoing, or two-way trust.
8.	Select Two-Way, and click Next to create a two-way trust. The wizard now asks whether you want to configure only your own side of the trust or both sides of the trust. An administrative password for both forest root domains is required to establish the trust.
9.	Choose to configure both sides of the trust. When prompted, enter the username Tom_Perry and the password P@ssw0rd. You now need to choose between Forest-Wide Authentication and Selective Authentication. Selective Authentication enables you to specify the authentication process in more detail, but it involves much more effort.
10.	On the Outgoing Trust Authentication Level—Local Forest page, choose Forest-Wide Authentication. Click Next.
11.	On the Outgoing Trust Authentication Level—Specified Forest page, choose Forest-Wide Authentication, and then click Next. The wizard displays a summary of the options you have chosen.
12.	Click Next to establish the trust. Click Next.
13.	On the Confirm Outgoing Trust page, you can confirm the outgoing link by selecting Yes, Confirm The Outgoing Trust and clicking Next.
14.	On the Confirm Incoming Trust page, confirm the incoming trust link by selecting Yes, Confirm The Incoming Trust and clicking Next.
15.	On the Completing The New Trust Wizard page, click Finish to close the wizard. Click OK to close the Properties dialog box for the contoso.internal domain.
16.	Create a universal security group in the contoso.internal domain. Add this universal security group to the Administrators builtin security group in the litware.internal domain. Experiment to discover the rights and permissions Tom Perry and Kim Akers have in both domains.