Auditing AD administrators with Windows 2008 R2's Event Viewer

When it comes to admin rights, knowing who you can trust is not always easy. But while auditing limitations won’t do you any favors, new features in R2’s Event Viewer can help.

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)
Event ID 4907

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)
The Audit Directory Service Access GPO

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.
Test the auditing by logging on as the admin specified in the audit properties (in my example it is JrAdmin). Modify the object the auditing was defined on and check the security event log. For instance, you can delete the user object or modify an attribute.

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

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

  • 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)
Properties for Event ID 4662


  • 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.

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

Now let’s consider a couple of options and the results.

  • GPO Auditing (directory access) is enabled for success but object auditing is disabled.
    - Result: Event ID 4662 logged when user is removed from object audit list.
  • - Result: Event ID 4738 logged when change to the object is made.
  • GPO Auditing (directory access) is disabled and object auditing is enabled.
    -*#160Result: Event IDs 4662, 4738 and 5136 are all logged.

It’s easy to see the difference in the number of events with full auditing in comparison to having GPO disabled and object auditing enabled. Note that even with GPO auditing disabled the important Event ID 5136 is logged, showing details of the attribute that was changed and who changed it. If both the GPO and object auditing are disabled, only one Event ID 4738 is logged, which has no useful information:

Log Name: Security
Event ID: 4738
Computer: w2k8r2-dc1.w2k8r2.Wtec.adapps.hp.com
Description: A user account was changed.

         Security ID: W2K8R2\JrAdmin
     Account Name: JrAdmin
     Account Domain: W2K8R2

Target Account:
         Security ID: W2K8R2\AdmUser400
     Account Name: AdmUser400
     Account Domain: W2K8R2

Note that while various combinations of auditing can produce some events, there is still no event logged, specifying that the audit policy changed for directory objects. Non-directory objects (files, folders, etc.) log Event ID 4907.

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)
The Custom View folder

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)
Saving selected events

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)
The Saved Logs feature

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.

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.

Dig Deeper on Microsoft messaging and collaboration

Cloud Computing
Enterprise Desktop
Virtual Desktop