Implement Sticky Security and Control Role Assignment

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:

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 ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit 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 SettingsLocal PoliciesAudit 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.

Event Detected—What Next?
Not all event codes resulting in 565 indicate that the Schema Master role was reassigned. Therefore, the script must next determine the identity of the Schema Master. If the Schema Master role hasn't been reassigned, the script doesn't take any action.

Using Microsoft Active Directory Service Interfaces (ADSI), the IsSchemaMaster function in the code at callout B determines whether reassignment occurred. The function starts by binding to the RootDSE class, a necessary step to navigate the Active Directory (AD) namespace and retrieve the current distinguished name (DN) for the schema. The RootDSE class, which is part of WMI's Active Directory Provider, lets you obtain information about Lightweight Directory Access Protocol (LDAP) servers. After binding to the current schema container, the function retrieves AD's fSMORoleOwner property to determine the identity of the current schema role owner. The function then uses the retrieved fSMORoleOwner property value (i.e., a DN) to bind to the nTDSDSA object. Using ADSI's Parent method (a method of the IADs core interface), the function finds that the server assigned the Schema Master role. Binding to that server and obtaining the dnsHostName property completes the navigation through the AD namespace. The function's last task is to set IsSchemaMaster to the value of the dnsHostName property.

If the IsSchemaMaster function returns a value that's different from the original Schema Master role owner, the ResetSchemaRole() procedure at callout C reassigns the role to the proper owner. This procedure relies on ADSI to bind to the RootDSE, then uses ADSI's Put and SetInfo methods (contained in the IADs core interface) to reassign and save the Schema Master role to its proper location. The Put method uses the becomeSchemaMaster operational attribute to reassign the role.

As I mentioned earlier, after you understand this script, reassigning other roles is easy. For example, becomeDomainMaster is the operational attribute that reassigns the Domain Naming Master role.

Just reassigning the role isn't enough. Someone (e.g., an administrator) needs to be informed about the reassignment. Using the Collaborative Data Objects for Windows NT Server (CDONTS) component, the InformAdmin() procedure at callout D takes care of this detail by emailing someone about the reassignment. This procedure provides details in the body of the email message so that the email recipient knows the server to which the role was improperly assigned and when this improper assignment occurred. This procedure relies on the SMTP service to email someone about the event; therefore, make sure that the SMTP service is running either on the server that maintains the Schema Master role or on some other server that can relay messages on behalf of the DC.

Customizing and Running the Script
Now that you understand how the script works, you must modify three variable values and, optionally, run the script as a service, which lets the script constantly monitor for this event in the background. Otherwise, the script runs in the foreground and only when you manually launch it. Assign a value to the sFromEmail variable (at callout D) to an email address that will appear in the email message's From line. Assign a value to the sEmailAddress variable (at callout E) to an email address that should receive the warning about the Schema Master role reassignment. Assign a value to the sSchemaOwnerName variable (at callout E) to the Fully Qualified Domain Name (FQDN) of the server owning the Schema Master role.

You can determine which server is the current Schema Master by running the MMC Active Directory Schema snap-in. If the snap-in doesn't appear in the list of available snap-ins, type

regsvr32 schmmgmt.dll

from the command line to register the snap-in. Then, reload the snap-in into a custom console, right-click the Active Directory Schema node, and click Operations Master. The Schema Master role appears in the bottom text box of the Change Schema Master dialog box.

You can use the batch file Sc.bat, which Listing 2 shows, to call CScript to run SchemaControl.vbs. SchemaControl.vbs then waits for event ID 565 before finishing. When the event occurs, SchemaControl.vbs finishes and Sc.bat reloads SchemaControl.vbs so that it can continue monitoring. Put SchemaControl.vbs and Sc.bat in the same directory on the server that owns the Schema Master role. Like SchemaControl.vbs, Sc.bat doesn't display anything in the command console.

You can run Sc.bat as a service with the Service Installer (instsrv.exe) or the Service Installation Wizard (srvinstw.exe) and Applications as Services Utility (srvany.exe) tools in the Microsoft Windows 2000 Server Resource Kit Supplement One. For details about running an application as a service, see the Windows Server Resource Kit Tools Help file. You'll need these details after you install the Applications as Services Utility:

In a perfect world, running a script such as SchemaControl.vbs isn't necessary. However, if security is a top concern for you, this script should give you some additional comfort.