Auditing NT 5.0's Active Directory

An important tool in securing your NT network

If you're planning to migrate your network to Windows NT 5.0, the Active Directory (AD) will become a major part of your life. Whether you roll out NT 5.0 to 10 workstations or 10,000 workstations, one aspect of AD will be important to you: security. AD's security falls into two areas: creating and managing permissions to objects and their properties in a Directory Information Tree (DIT) and creating and managing audits of objects and their properties in a DIT. I discussed how to create and manage permissions in "Managing Permissions for NT 5.0's Active Directory" (July 1998). Now I will discuss how to create and manage audits.

In the context of NT, you can define auditing as the tracking of successful and unsuccessful events. NT 5.0 provides similar levels of auditing compared with NT 4.0; however, NT 5.0 extends the audit's reach to new areas, such as AD. You can add triggers, or alerts, to AD objects and see the results in the auditing log.

The following article looks at how to view and create auditing entries and how to check auditing logs in NT 5.0's 1773 Interim Developers Release (i.e., post-beta 1). I used a single-server domain running the post-beta 1 release of NT 5.0 as my default setup. The domain's AD contains the NT server and workstation client running NT 5.0 post-beta 1.

Viewing Auditing Entries
Suppose you want to set up an auditing process for a domain called ims. Before you consider what audits to apply to AD objects and containers, you need to know the default auditing entries for the domain.

To view the auditing entries for the ims domain, you must use the Microsoft Management Console (MMC--for more information about MMC, see Darren Mar-Elia, "Microsoft Management Console," June 1998). In MMC, open Directory Management. Right-click ims in the scope pane, and select Properties. In the ims Properties dialog box that appears, select the Security tab. Click Advanced to bring up the Access Control Settings for ims, and select the Auditing tab.

Screen 1, page 156, shows AD's default auditing settings. In Screen 1, the system is auditing all successful and failed events (All) of varying accesses (Special) in the ims domain (this object only) for AD's built-in group (Everyone). The default access control setting of Special means that the system audits multiple events. To see those events, you can either double-click the auditing entry line or highlight the line and click View/Edit. In the dialog box that appears, you'll see two tabs: Object and Properties. Screen 2, page 156, shows the default Object tab; Screen 3 shows the default Properties tab. Both screens display the audited events that apply to only the root of the ims DIT for the Everyone group.

As Screen 3 shows, AD audits only property writes for the ims domain object by default. This default makes sense when you consider that Microsoft designed AD for more reads than writes. Users log on to a DIT or query published resources much more often than they change their password or change the name of a printer. Consequently, if the system default were full auditing instead of write access, the log containing the auditing entries would fill up quickly and individual entries would be hard to find.

For the same reasons, the List contents, List object, Read all properties, and Read permissions check boxes in Screen 2 are empty. The system enables only the auditing of write, delete, and modify events of ims objects by default.

You might have noticed that Screen 3 has a Read all properties check box, but not a corresponding Write all properties check box. NT 5.0 beta 1 had a Write all properties check box in the Properties tab. But in NT 5.0 post-beta 1, the developers moved this option to the Object tab (as Screen 2 shows) and added a duplicate Read all properties check box. This modification is a good reminder that NT 5.0 is still prerelease software and therefore can change.

Creating Auditing Entries
To show you how to create auditing entries, I used object examples from "Managing Permissions for NT 5.0's Active Directory" and created a DIT for the ims domain. This DIT has an organizational unit (OU) container, TestOU1, which contains a user, TestUser1. Elsewhere in the DIT, the default Users container houses a domain group, DataEntryGroup. TestUser1 is a member of DataEntryGroup.

Suppose you decide that the system's default of auditing every write and every modification is too intensive. Instead, you want to set up a simple audit policy to monitor DataEntryGroup. Specifically, you want an alert to go off when group members try to modify an object's permissions or owner but fail because of insufficient access permissions. You want to apply these events to the entire domain. In other words, you want to monitor these two events for every object. To disable the default setting and create an entry, follow these nine steps.

If you are manually setting up an auditing entry for the first time on a server, a dialog box opens with the message: The current Audit Policy for this computer does not have auditing turned on. To enable auditing, you must use NT 5.0's Security Configuration Editor (SCE). The sidebar "How to Enable Auditing with the Security Configuration Editor," explains how to use SCE for this purpose.

Checking the Auditing Log
After you have set up the auditing policy for the domain, you need to check the auditing log. In MMC, open Computer Management and expand System Tools in the scope pane to display the Event Viewer. Expanding the Event Viewer gives you five logs to choose from; you need the Security Log. Clicking Security Log displays the audited events in the display pane, as Screen 4 shows.

Suppose that when you check the Security Log, you find that DataEntryGroup members occasionally don't modify the owner of a certain object, TestOU1, in the DIT. To find out what is occurring, you can set up an audit on that container only. To set up this audit, go through the nine steps for creating an auditing entry, except substitute the TestOU1 object for the ims domain and choose to audit all successful and failed write, delete, and modify events for TestOU1 and for any objects below TestOU1 in the DIT. This audit will let you see all aspects of TestOU1 that the DataEntryGroup members are attempting to change.

Suppose that this audit reveals one particular user, TestUser1, as the culprit. Having checked TestUser1's permissions, you find nothing unusual, so you decide you need to audit TestUser1's events. To set up this audit, follow the same nine steps you took to set up the container audit, except substitute TestUser1 for DataEntryGroup and select all the check boxes in the Successful and Failed columns.

This new audit places a complete audit trail on TestUser1, letting you maintain a vigil on what that account owner is doing. Whether TestUser1's actions are unintentional (e.g., in an application, clicking a key that happens to have a rogue function call that attempts to make changes) or intentional (e.g., using System Tools to try to deliberately change an object's permissions), you can identify and solve the security problem immediately.

You might be wondering why you didn't audit all events from the outset to identify the problem. Immediately conducting a full audit might not be a good idea. (I stressed might not because it might be appropriate in certain situations.)

For companies with many users, auditing every event for every object will generate thousands of entries in a matter of minutes. Because the system must record every entry in the auditing log, auditing imposes a load on the system. Even a powerful server will likely suffer from a notable decrease in performance. In addition, you're productivity will likely suffer as you search through all those entries looking for clues. (The sidebar "Frequently Asked Questions About Auditing Under the NT 5.0 Post-Beta 1 Release," also addresses this topic and others.)

Simplicity Is Key
The important fact to keep in mind with auditing NT 5.0 is that the more events you audit, the more time you'll spend trying to find the entries you are looking for. NT 5.0 generates thousands more Security Log entries than NT 4.0 because users constantly access AD during their daily operations. Although NT 5.0 ships with an enhanced version of NT 4.0's filtering settings, information overload is a real possibility. So to keep the information easy to manage, you need to define simple auditing controls for the domain and set up container-based controls only when you need them.