Active Directory Auditing

IT administrators have been working with and around Active Directory since the introduction of the technology in Windows 2000 Server. Windows 2000 Server was released on February 17, 2000 but many administrators began working with Active Directory in late 1999 when it was released to manufacturing (RTM) on December 15, 1999.

Auditing Active Directory in Windows Server

Prior to Windows Server 2008 R2 and Windows 7, auditing in Windows was a fairly simple topic. You navigated to the auditing policies in a GPO and enabled auditing and chose Success, Failure, or both.

There were a number of articles on the internet describing each of the auditing policies and many administrators quickly avoided anything that didn’t provide much value. Below is a screen capture showing the available audit policy settings.

In Windows Server 2008 R2, a new feature was introduced to allow for advanced auditing policies in Group Policy. Officially, 53 new settings were made available to replace the original 9 policy settings shown above. A little known fact is that these 53 new settings were actually available in Windows Server 2008. However, you had to use logon scripts and auditpol.exe to take advantage of the new settings. Thus, most administrators didn’t. One common area of confusion is the apparent overlap of the original 9 policy settings (hereafter called the basic audit policy settings) and the advanced audit policy settings. There actually isn’t any overlap though. Let’s examine why by looking at the account management auditing.

With basic audit policy settings, you can enable the “Audit account management” policy for Success and Failure. With advanced audit policy, you can enable auditing for application group management, computer account management, distribution group management, account management events, security group management, and user account management. Enabling the “Audit account management” basic audit policy setting is the same as enabling auditing in the 6 subcategories available in an advanced audit policy. Neither provide more data. But, as many administrators have realized, generating too much audit data can be worse than not generating any audit data because of the massive volume of audit data that can be generated.

Common auditing struggles

Administrators have been struggling with audit data for a long time. Some of the common struggles are:

  • Windows event logs fill up.

Windows event logs can be configured in a number of different ways. You can set a maximum log size and delete old event as needed. You can archive a log when it fills up and then start a new log. Or, you can configure the logs not to overwrite events and require manual intervention. You can even shut the server down if you can’t write to the Security event log. Administrators often can’t afford for new events not to be written or for servers to shut down when a log fills up. Thus, overwriting events or archiving are the most common settings. But this leads to administrative overhead: monitor event log sizes, monitor disk space, move archived logs off of server, manage archived logs, and figuring out a way to search through all of the data.

  • Disk volumes run out of space.

I still find it amusing that in 2015, disk space is still the major source of server downtime in many companies. Log files are a common problem whether from auditing or from applications such as IIS. I have heard from several organizations that experienced an outage and the root cause was the system volume running out of space due to Windows event log archiving.

  • Inability to locate specific audit data.

When you generate a massive amount of data, every data management task, even normally simple tasks, become complex and time consuming. Tasks such as compressing the files, copying the files to another location over the network, or searching through the files for a specific key term become problematic and incredibly time consuming. Administrators are turning toward third-party solutions to help.

  • Inability to use audit data in a timely fashion.

Imagine a call from the security team about an employee that has potentially viewed confidential HR data. They ask you to pull up audit data for the user over the last few weeks. Not a big deal if you have 1GB worth of audit data. But when you have 500GB worth of audit data, it suddenly becomes your full time job for a few weeks.

The advanced audit policy settings can help. By offering more granular auditing options, you can greatly reduce the amount of data gathered. This minimizes the struggles mentioned above.

But, there is a big investment in time to switch over to the advanced audit policy settings. For some organizations, that investment will pay for itself and more.

Advanced audit policy settings

Let’s take a quick look at how this impacts the number of events captured. In this first example, in a Windows Server 2003 R2 domain named adatum.com, I set basic audit settings so that only account management success events are being audited, as shown below. There isn’t any significance to the operating system version because the basic audit settings shown below are available in every version of Windows Server since Windows 2000 Server.

Then, I created a new computer object and refreshed the Security event log. Below are the entries related to the new computer object creation.

There are 5 events.

Next, in a Windows Server 2012 R2 domain named contoso.com, I created an advanced audit policy based on wanting to audit only successful user account management events, as shown below.

Then, I created a new computer object and refreshed the Security event log. Below are the entries related to the new computer object creation.

With the advanced auditing policy, only 2 events were logged. That’s a big difference, especially when you think about how that would extrapolate once all auditing categories were configured.

Note that not only would we save some time with the granular approach, but we will also save quite a bit more time later after the other auditing categories are configured.

Now, you may be wondering why creating a computer account is showing up in user account auditing? That’s because computer objects are part of the AD DS user class along with user objects!

You may also be wondering why the event log IDs are different for each environment? This is unrelated to the auditing configuration and instead is because of a change in the event log IDs used in Windows Server 2008 and newer. Many of the event IDs changed between versions of Windows Server.

More information about Active Directory basisc you will find in our AD tutorial for beginners.