Tech Tip: Understanding Active Directory’s Native Auditing Capabilities

Allow me to introduce the 2nd in our series of Active Directory Tech Tip's by Darren Mar-Elia:

Active Directory (AD) includes built-in auditing that lets you track changes within the directory. This capability is much improved since Server 2008 shipped. If you are running a Windows Server 2003 AD environment, it is much harder to glean critical data around AD changes and in fact, certain events simply aren’t audited sufficiently. In this tip, we’ll look how you can set up the native auditing capabilities in AD, walk through a specific auditing scenario, and talk about the limitations within the native OS auditing.

Enabling Auditing
There are a variety of categories of auditing within the native OS. When Microsoft shipped Server 2008, they exposed a much more granular audit categorization that allows for tighter control of what events get audited (and consequently, how many events are generated). These categories of auditing must be enabled before any audit events will appear within the security event logs of your Windows machines. (Note that all audit-related events will be sent to the security event log).

There are two principle ways to enable auditing subcategories—via Group Policy or using the auditpol.exe command-line utility (available on Server 2008 and later by default). The Group Policy method, shown in Figure 1, is the easiest one to use.

Figure 1: Viewing audit subcategories within Group Policy.
When these audit subcategories are enabled in a GPO that is processed by your domain controllers, then it will apply to objects within AD—and controls what auditing happens on AD.

Each of the subcategories within the GPO also has an Explain tab associated with it. This tab explains what that auditing enables and gives an indication as to whether the volume of events associated with that subcategory will be high. The advantages of adding these subcategories within Server 2008 and the new OS is that you can tune the amount of auditing that happens by only enabling those subcategories that you truly need to audit. In Server 2003, it was an all-or-nothing proposition and the result could be security event logs on domain controllers that rolled over quite frequently.

Once audit subcategories are defined for your domain controllers, you’ll need to be aware of a second step, if you want to audit changes to properties on AD objects. Namely, you’ll need to make sure that the objects of interest to you have System Access Control Lists (SACLs) associated with them. A SACL is simply a set of audit “permissions” if you will, that tell AD that you want to audit a given set of AD objects for a certain set of operations (e.g., writing the phone number property on all user objects) for a given user group. For example, you could set a SACL that creates an audit event whenever a member of the Marketing Admins group modifies the department attribute on all user objects within the Marketing OU. Figure 2 shows an example of editing a SACL from the MMC tool—AD Users & Computers

Figure 2: Auditing AD object write operations.
You don’t need to set SACLs on other types of audit categories outside of the Directory Services category of auditing. For example, the subcategories within the Account Management category will generate audit events related to AD account management even if no SACLs are set on AD objects.

AD Auditing Walkthrough
Let’s walk through an example of how AD’s native auditing works. In my test scenario, I’m going to change the department attribute on a user object in the Marketing OU. I’ve enabled the “Audit Directory Services Changes” subcategory within Group Policy on my domain controllers, and I’ve set a SACL on the Marketing OU to audit all property changes to all user objects.

Next, I’m going to go into the user object “Joe Jones” and change his department from “Marketing” to “Sales.” The effect of that, on the domain controller that originated the change (note that changes are not audited on any domain controller except the originating one), is that two events get logged in the security event log on the domain controller, as Figure 3 shows.
 
Figure 3: Viewing before/after change events on AD object changes.
Each event shows a task category of “Directory Services Changes” that corresponds to one of our audit subcategories. The reason there are two events is that the first event records the removal of the original value of the Department attribute on Joe Jones, and the second event records the new addition of the value “Sales” on that attribute. This before-and-after value reporting is new as of Server 2008 and was not supported at all in Server 2003. Unfortunately, it does require generating two distinct events to get the values, which is not great from a reporting perspective. This brings us to a final discussion on the limitations of AD auditing.

The Limits of Native AD Auditing
In addition to cumbersome behavior such as the before-after-value reporting I just mentioned, trying to do enterprise auditing using the native tools presents some challenges. For one thing, each domain controller that originates changes will have its own log of those changes. So correlating change events across multiple domain controllers is a manual and labor-intensive process.

In addition, if you want to be alerted on changes that occur that are critical in nature, there is no easy way to do that out of the box.

Finally, the sheer volume of logs that are generated in a reasonably-sized AD environment are likely to cause log rollovers on a fairly frequent basis. This means you will need to come up with a way of capturing off critical log events before they roll over, which implies some storage mechanism that is not natively available. You could use the “event forwarding” feature in Windows Server to help with some of this, but for efficiency and scalability reasons, you would likely need to be selective about which events got forwarded, and some events would inevitably have to be dropped. Third party tools can also be implemented to address these areas.

More Tech Tips are available in our eBook: Protecting Critical Data by Managing the Active Directory Identity Lifecycle

| Follow us on Twitter | Follow us on Facebook