Do you manage an enterprise network that contains a forest of Windows 2000 domains? Is securing your Win2K network important to you? If you answered yes to either or both questions, read on. Although Win2K Server uses a multimaster replication model, some forestwide roles, specifically the Schema Master and Domain Naming Master roles, must reside on one domain controller (DC) in a forest.
Win2K provides a security infrastructure to effectively control who can reassign these special roles. However, a user with administrator privileges in a child domain can find ways to reassign a forestwide role to a DC in a child domain. Such reassignments pose significant security problems because unless you control the forestwide roles, a Win2K domain isn't truly a security boundary—the forest is. I don't address improperly reassigning forestwide roles, but I do give you a scripting solution for dealing with this type of event.
The script SchemaControl.vbs, which Listing 1, page 70, shows, enforces what I like to describe as sticky security. SchemaControl.vbs detects the reassignment of the Schema Master role, resets the role to its original location, and sends an email message to inform someone of the event. In a sense, this script makes this important role adhere to its original location. I highlight the Schema Master role because an administrator in the domain to which this role is reassigned can irreparably damage the schema. The worst-case scenario is that this schema damage requires you to rebuild the entire forest. After you understand how SchemaControl.vbs works, however, you can modify the script to detect the reassignment of other roles, such as the Domain Naming Master role. To run the script, you must have the appropriate role-change permission. For transferring the Schema Master role, you must have the Change Schema Master permission, which is granted by default to the Schema Admins group.
Preparing for and Monitoring the Event
SchemaControl.vbs relies on Windows Management Instrumentation (WMI) to monitor the Security event log. Specifically, the ExecNotificationQuery method of the SWbemServices object queries the Security event log for event ID 565. Schema reassignment is one reason why this event code is logged. Event ID 565 is an object-access event code raised when access is successfully granted to an existing object type. To raise this event in the Security event log, you must enable the Audit directory service access policy setting. You can enable this policy setting in any Group Policy Object (GPO). However, I suggest you enable the setting in one of these two places:
- in the Default Domain Controller GPO of the domain in which the Schema Master role is assigned
- in the local GPO of the DC on which the Schema Master role is assigned
To enable the setting in the Default Domain Controller GPO, open the GPO in the Microsoft Management Console (MMC) Group Policy snap-in tool, then navigate to the Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy node. In the details pane, double-click the Audit directory service access policy setting. Then, select the Define these policy settings check box and clear the Failure check box. Don't clear the Success check box.
Completing this task in the local GPO is a slightly different process. One way to complete this task for the local GPO is to open the Local Security Policy option in Administrative Tools, then navigate to the Security Settings\Local Policies\Audit Policy node. In the details pane, double-click the Audit directory service access policy setting, then select the Success check box that appears in the Local Security Policy Setting dialog box.
Assigning this policy setting in the Default Domain Controller GPO applies the policy setting to all DCs in the domain. Assigning the policy setting in the local GPO applies the policy setting to the specific DC that owns the Schema Master role—the DC that SchemaControl.vbs monitors.
The code at callout A in Listing 1 highlights the CheckForEvent() function that determines whether an object was opened, which results in event ID 565 being recorded in the Security event log. When the query is successful, the NextEvent method of the SWbemEventSource object retrieves the event and, as a result, the CheckForEvent() function returns true.
Previous
Register
