Auditing AD administrators with Windows 2008 R2's Event Viewer

Any discussion with Microsoft about how to limit or manage administrator rights usually results in a lecture on how you should not give admin rights to people you don’t trust. This makes sense, but how do you know an admin can’t be trusted if there is no evidence they did something wrong? And further, how do you prove it?

There’s a long list of actions that you simply can’t lock a domain admin out of. Limiting admin rights and delegation is sometimes difficult to accomplish, especially in a multiple domain environment that requires admins in each domain. Support personnel usually need admin rights as well, and sometimes political requirements will dictate even more admins. So the real question is, how do you audit an administrator?

While the answer is to simply enable auditing, this doesn’t catch everything. For example, I recently worked on a large Active Directory deployment with a number of admins. They had an application that used certain user object attributes to provide hooks to the app. From a security standpoint, they found that an admin could disable auditing, modify those key attributes and do bad things with the application. The admin could then re-enable auditing without detection -- even with Windows Server 2008 R2’s attribute auditing features. With auditing enabled, sufficient events are logged to show who made changes to the object, including the attributes. But with auditing disabled, all this evidence was missing.

It turns out that Event ID 4907 (Figure 1) is logged when auditing of non-directory objects is enabled, but no such event is logged for directory objects.

Figure 1. Event ID 4907 (click to enlarge)

The event clearly showed that the audit policy was changed and who did it, but I needed to be satisfied that we could not get the needed information some other way before logging a case with Microsoft. This is important, as it allows me to demonstrate the powerful Event Viewer features like custom views and sorting/saving filters for Windows Server 2008 R2. Verbose auditing dumps an incredible number of events to the security log with object auditing enabled. With the old Event Viewer, it would be very difficult to sort through these events to get what you want.

In order to audit directory objects, the Group Policy Object (GPO) setting “Audit Directory Service Access” (Figure 2) must be enabled on a GPO that applies to the object to be audited.

Figure 2. The Audit Directory Service Access GPO (click to enlarge)

In addition, auditing must be enabled on the object itself. For example, to configure the audit settings on a user object, do the following:

• Locate the desired object in the Active Directory Users and Computers (ADUC) snap-in.

• Open the object Properties and select the Security tab. Be sure to go to the View menu and enable Advanced Features.

• In the Security tab, select the Advanced button.

• In the Advanced Properties screen, select the Auditing tab. Choose Add to add a user or group to audit, as shown in Figure 3. You can specify the security options in the following screen. Click OK to exit out of all open screens.

Figure 3. Advanced security settings in ADUC (click to enlarge)

With auditing enabled, the result is a plethora of events in the security log, most notably:

• Event ID 4738 -- This is logged when the object is modified.

• Event ID 4662 -- A number of these events are logged with various bits of information (Figure 4). In my case 25 of these were generated for a single object modification.

Figure 4. Properties for Event ID 4662 (click to enlarge)

• Event 5136 -- this provides more detail about the modification like the one shown here. Note that we can see the DN of the user making the change to the directory object as well as the DN of the object. We can also see that the description attribute was modified, as we are shown the old value and the value that was deleted (note that some fields were deleted for brevity here):

  Log Name:   Security
  Event ID:   5136
  Task Category:   Directory Service Changes
  Computer:   w2k8r2-dc1.w2k8r2.Wtec.adapps.hp.com
  Description:   A directory service object was modified.

  Subject:
           Security ID: W2K8R2\JrAdmin
           Account Name: JrAdmin
           Account Domain: W2K8R2
  Directory Service:
           Name: w2k8r2.Wtec.adapps.hp.com
  Object:
           DN:
           CN=AdmUser401,OU=Atlanta,DC=w2k8r2,DC=Wtec,DC=adapps,DC          =hp,DC=com
           GUID:
           CN=AdmUser401,OU=Atlanta,DC=w2k8r2,DC=Wtec,DC=adapps,DC          =hp,DC=com
           Class: user
  Attribute:
           LDAP Dsplay Name: description
           Syntax (OID): 2.5.5.12
           Value: This is a test
  Operation:
           Type: Value Deleted
           Correlation ID: {1e193e1d-537f-49c7-bb69-bb50aa4542c2}
           Application Correlation ID: -

So what’s the solution?
The answer is to use a third-party product to audit this activity. Quest Software and Symantec have tools that will do this, for example. It is unknown if Microsoft will change this in the next version of Windows.

Using the Event Viewer

In resolving this issue, the features in Windows Server 2008’s Event Viewer were critical to the process. The security log is famous for its size -- especially with auditing. When auditing was enabled at the GPO and object level, 20 to 30 events would be logged for a single attribute change. The advanced filtering in Event Viewer allowed me to build several filters and simply refresh them when a change was made to the policy or object, allowing me to see only the important events.

The filters were built in the Custom Views folder as shown in Figure 5. In this example I was able to identify the event level, one or more ID numbers and one or more event logs (note that even though I only needed the security log here, I could have added additional logs if I wanted to). I also specified a limit of “Last 12 hours” to further limit it, and I saved it to a logical name. If I decided later that I wanted to add or remove an event ID, for example, I could edit the filter, save it, and then refresh the display to get a new data set of events.

Figure 5. The Custom View folder (click to enlarge)

Attempting to sort in the full security log took an incredibly long time; the Custom View filter took only a second or two. Of course the danger is that if you fail to include a necessary event in the filter, it will not show up in the filtered view. In my case I started with a filter for the last hour to limit the events, then found the events that related to my audit and added them to the Event ID field in the filter. As you can see in Figure 5, I have defined a number of custom views for various purposes and they are always available for use.

Another feature I used was the Copy Details to Text feature. To get the details for Event ID 4738 (shown in text above), I would have had to take several screen shots as the information scrolled in the event. In the Windows Server 2008 Event Viewer, just right-click on the event in the list, select Copy > Copy Details as Text and paste it into something like Notepad. This will display all the information for documentation purposes.

Now suppose you wanted to examine all the events for a time period -- say from 8 a.m. to 5 p.m. -- and needed to send those events to a support engineer or just wanted to work on a smaller file. You could simply select the desired events in the Event Viewer, right-click and select Save Selected Events and specify where you wanted it saved (Figure 6). This will make a small event log of just those events, making troubleshooting much simpler and easily transportable.

Figure 6. Saving selected events (click to enlarge)

Finally, Figure 7 shows the Saved Logs feature. In the old Event Viewer, if you loaded saved event logs they would disappear after Event Viewer was closed. Now they stay until you delete them. Also, they have the names they were saved as, rather than the generic “Saved Application Log” names that were provided in the old Event Viewer. Windows Server 2008’s Event Viewer can also tell what kind of event log it is (system, application, etc.) so you don’t have to specify the log type, which is much easier to use.

Figure 7. The Saved Logs feature (click to enlarge)

So let’s quickly summarize what we’ve gone over. While the auditing of attributes is a powerful feature in Windows Server 2008 R2, it lacks functionality to audit changes to the audit policy, which in turn allows untrustworthy domain administrators to make destructive changes in Active Directory. It can be difficult to tell if an admin is trustworthy when you have no way of checking things like this. While third-party tools can help, this is still a weakness in Windows auditing.

The new features in the Windows Server 2008 Event Viewer provides great flexibility and powerful filtering not available in previous versions. This allows for excellent data reports to aid in the troubleshooting process. It also helps administrators quickly identify crucial events without wading through a sea of logs to find the ones that are related to the problem.

For more information about resolving issues with AD, visit our Active directory troubleshooting topic page.

ABOUT THE AUTHOR
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.