Active Directory Tools Versus Native Auditing

This is re-posted from an earlier post but seems as relevant as ever. If you’re thinking about monitoring Active Directory events, you’ll no doubt consider what’s involved in leveraging native event logging and how that relates to tools that are designed for AD event monitoring. In that context, below, we describe a few of the steps involved in setting up native event logging for Active Directory.

Determine Which Events You Need

First, you need to understand which events you need to keep track of, and the associated event IDs. Complicating this task is that the event ID numbering is different between versions of Windows. For example, in Server 2008, four digit event IDs are introduced along with audit subcategories on the main audit categories. There are many events that look similar to each other, so you really need to know what you’re looking at, and often a single act will generate numerous events in the log.

The subcategories can be useful because you can enable auditing on some events but not others, which is a step in the right direction for Microsoft auditing, albeit a baby step. For example, instead of treating all Account Management events the same, you can enable audit on Security group management but disable audit on Distribution group management. You have to use a command line tool to apply audit settings via subcategories and you don’t get advanced filtering such as the ability to alert on changes to high-risk groups (something STEALTHbits can easily do), but it’s better than the Server 2003 capabilities.

Complicating matters further is that there are Account Management audit events and Directory Service Access audit events which overlap. So, if both are enabled, you may see even more duplicate events with some confusion about where to find the best event data. And “before” and “after” values are written to different events. So, in some cases, you’ll need to correlate multiple events in order to get the answers you seek.

Enable Auditing on Desired Objects

Once you have the set of events that you want enabled, you also have to enable auditing on the objects themselves. In other words, if you enable auditing on security groups, you still need to ensure that auditing is enabled on those security groups. Typically, enabling audit on directory objects is as simple as enabling “Audit Account Management” in the appropriate GPO but keep in mind that audit settings differ slightly in various versions of Windows, so if you have a mixed environment, be sure to consult each versions’ documentation for appropriate audit settings. And be sure that the GPO is configured appropriately on each Active Directory Domain Controller.

Additionally, you can utilize ADSIEdit to apply a “don’t audit” flag on attributes that you’d like to have filtered out of auditing. Note that this removes ALL auditing of that attribute for ALL objects. You cannot distinguish, for example, between administrative user accounts and other accounts (again, something that’s easy for STEALTHbits).

Configure Event Log Settings

The third step is to configure log settings. You need to set appropriate access permissions so that advanced users looking to cover their tracks cannot clear logs which may hold vital evidence. If the log security policy is not enabled, all authenticated users would have access to write & clear application logs. System and Security logs can be cleared by system software or administrators. You also need to set maximum log size and retention rules. These settings enable you to control how large the log files will grow and what happens when they reach their maximum. This is critical because logs need to be efficiently handled by log collection systems.

Conclusion

There’s no ON switch for Windows auditing. There’s a number of steps and methods by which to implement auditing. There is even a TechNet article on the complexity of determining the effective audit policy in Windows 2008. The author makes the point that “you should not trust any of the Group Policy reporting tools when it comes to audit settings.” If you love Windows event logs and have a complete mastery of how they work (you know who you are), that’s great. If not, I would think twice before making a decision to rely on Windows event logging. I certainly wouldn’t go down that path with the expectation that it’s the easy way. It’s clearly not.

Learn about STEALTHbits’ Active Directory security solutions here!

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

Name

Email*