Windows Server 2008: Auditing Active Directory

If you have been supporting servers for any amount of time, you have no doubt come across requests from manager for security audits, if you don’t already have them in place yourself to keep an eye on things.

Auditing is exactly what it sounds like — it keeps a record of things that have been modified in Active Directory.

In previous versions of Windows Server there was not a lot of granular control in what you were auditing. Let’s explore some of the new auditing features in Server 2008.

Auditing Changes in Windows Server 2008

One of the most significant changes over the Server 2000 and Server 2003 versions of auditing is that now you can not only audit who and what attribute was changed but also what the new and old value was.

This is significant because you can now tell why it was changed and if something doesn’t look right you’re able to easily find what it should be restored to.

Another significant change is that in the past you were only able to turn auditing policy on or off for the entire Active Directory structure. In Windows Server 2008 the auditing policy is configurable for four subcategories:

• Directory Service Access
• Directory Service Changes
• Directory Service Replication
• Detailed Directory Service Replication

This article will focus on enabling auditing on Directory Service Changes which will show us the ability to audit changes to Active Directory Domain Services.

Implementing Auditing on Windows Server 2008

In Server 2008 when setting up auditing there are three places you can modify to implement controls:

• Global Audit Policy – In Server 2008 the Global Audit Policy is not on by default and must be enabled.
• System Access Control List (SACL) – Is the ultimate authority if an access check gets audited or not.
  
  The SACL is part of the security descriptor for an active directory object and specifies which operations should be audited. These are set by the security administrators who have been assigned Manage Auditing and Security Log privileges. It is assigned automatically to the Administrators Group.
• Schema – To protect administrators from generating too many auditing events there is an override that can be set in the schema to exclude any events that have an attribute set.
  
  We will not be covering the Schema modification in this article, but this is important for you to know.

Enable Global Audit Policy on Windows Server 2008

The first step is to enable the audit policy. I will walk you through both doing it through the GUI and then through the command line:

1. Go to Start, Administrative Tools, and then click on Group Policy Management.

2. Navigate down through your Forest, to the Domains, then Domain Controllers and left click on Default Domain Controllers Policy.

You will get a warning that changes here will impact all other locations that the GPO is linked to. Click Ok.

3. Right click on Default Domain Controllers Policy and then left click on Edit…

4. Navigate under Computer Configurations → Policies → Windows Settings → Security Settings → Local Policies → Audit Policy

5. Right click on Audit Directory Service Access, and then click Properties.

6. Select Define these policy settings and then select Success. Click on Apply and then Ok.

That’s it! You now have configured auditing via GUI.

Let’s take a look at the command line method (much faster):

1. Start Command Prompt with elevated rights.

2. Type in the following command and hit Enter:

auditpol /set /subcategory:”directory service changes” /success:enable

I told you it was much faster! You should see The command was successfully executed. Now let’s move on to the next step.

Setup Auditing in System Access Control List (SACL)

As was mentioned earlier, the SACLs do most of the work in determining what gets auditing and what doesn’t.

Please note that there are many different types of SACLs that can be setup; we are only using one as an example.

1. Open Active Directory Computers and Users.

2. Click on View and make sure that Advanced Features is enabled. If not left click on it to place a check next to it.

3. Right click on any of the Organizational Units you want to audit; in our example I am going to audit Users. Then click on Properties.

4. In the Properties window click on Security.

5. Next click on Advanced.

6. Click the Auditing tab, then click Add.

7. Under Enter the object name to select:, type in Authenticated Users and click Ok.

8. In the next window under Apply onto:, select Descendant User Objects and under Access check the box for Successful next to Write all properties and click Ok.

9. Click Ok until you are out of any dialog boxes.

Now that we have enabled auditing in a SACL let’s go ahead and give it a test.

Example Security Events with Auditing Enabled

With auditing enabled, all events will be logged under the Security Event Viewer. Let’s see what happens when you change a value on an object.

For brevity sake, I am going to create a user called audittest, change his name from Audit Test to Test Audit and then we will take a look in the security log to see what was shown.

There are two images that show the change that corresponds with Event 5136, here is the first one which shows the value being deleted, which in this case is Audit Test:

The next image shows the changed object’s new value which in our case is Test Audit:

So you can see that it is very helpful if you are watching these types of things to know what the old value was compared to the new value, in case you need to quickly and easily reset the attribute without having to go to a backup.

There are a ton of things you can audit depending on the situation and your need.