Active Directory auditing: No simple road to success

Auditing Active Directory almost always finds place at the top of the administrator’s to-do list. There are a number of pressing needs that make auditing indispensable. For instance, a single unwanted change such as user deletion or access right modification may have monumental effect on the health of the network and may lead to long downtime and system unavailability ultimately resulting in business loss. If not for the security issues and vulnerability to rogue users with malicious intent, government regulations and compliance standards definitely call for an elaborate and well defined audit policy that brings entire Active Directory environment under administrator’s control.

To that end it becomes important to go for a three-pronged approach – firstly, track all changes executed in Active Directory and keep it for later reference; secondly, analyze it in detail to ascertain who changed what object at what time and from where; and thirdly, have provisions in place to rollback an unwanted change before it causes any damage to the network. Auditing in real sense covers only the first two parts i.e. tracking, storing and analyzing. The third objective – to restore changed objects to original state – though not a part of auditing in true sense is not less important as that is where you prevent the disruptive changes from damaging the environment. It also requires real time alert feature to inform you of the changes so that corrective measures could be taken within proactive time frame.

Though the importance of auditing Active Directory changes cannot be over emphasized, the question what to audit? Unfortunately, has no easy answer. A simple change from human perspective such as deleting a user account can generate multiple log entries. Moreover, ‘before’ and ‘after’ values of the objects are stored in different log entries, thus any attempt to reconstruct the change from human perspective requires collating data from multiple entries. Also, Admins need to move to individual Domain Controllers to set the audit policy and collect the audit data. If these factors were not enough, then the fact that different versions of Windows server from 2003 to 2012 have different ways to configure audit policy doesn’t help either.

Even after you manage to move past these hurdles, managing event logs is another tricky affair. Windows offers you three options to manage event logs – 1. The log gets overwritten after the specified storage limit has been reached. This option suffers from inherent drawback of losing important information after the previous log is overwritten starting from the oldest. 2. The log is archived. In this case you need to search and refer to the archived log which is again not easy. 3. System asks you to take a call once storage limit has been reached. Again, delaying the decision and manually deciding what to delete and what not – clearly not the best option. To sum it up, if you were looking for an easy way to design and implement an audit policy for your Active Directory environment, you are likely to get disappointed.

So, what is the way forward? Going for a piecemeal approach might be a good option to start with. But then, it depends on what version of Windows Server you have deployed. If you are using Windows Server 2003 or previous versions, then it’s hardly an option since all the audit policies have been categorized only under nine heads. So, enabling any single one would lead to enormous amount of log being generated on the system. For example, enabling only Account Management audit policy would enable auditing for forty-three different events from user account creation to account name change. But as far as requirement goes, you might need to audit only two event types: user account deletion and password change. Starting with Windows Server 2007 to Windows Server 2012, the auditing options have been made more precise. In Windows Server 2007 and 2008, there are fifty three different event categories instead of the nine that were there in previous versions giving you the choice to be more specific while deciding on event auditing.

Still, Windows event handling might not be the best option when it comes Active Directory change auditing. It’s certainly not easy and far from being perfect considering the time and resource constraints under which Active Directory administrators work. There are specialized third-party tools like LepideAuditor for Active Directory that offer far better results with small investments that they require. There are proactive change alerts, and canned reports for specific single events. Different options to deliver reports to various stakeholders and detailed event analysis to answer all audit questions to satisfy compliance. Such applications work from a central platform and can audit mixed environment having different versions of Windows Server. Overcoming all shortcomings of native auditing these tools have been designed to offer much more and act as a catalyst towards achieving IT infrastructure goals of the organization.

  • Stan Heskey

    Thank you for sharing this information.

    • Brian Jackson

      You are welcome.

  • jimconell

    Thanks Steve, It is very helpful to understand the overall concept while auditing requirements by continuous tracking and collect the audit data. This article provides instructions for implementing this audit policy.