AD Auditing
Chalk it up to human nature, but all part of the job when you are running servers. Political scientists put it nicely when they ask, “Where and when does who gets what?” Who’s logged onto which computer? Which resources are they requesting?
Of course, we know there are all sorts of logging and auditing tools lying around. The problem doesn’t lie in accessing the information, but rather picking out the useful bits. If you run a high-security environment, for example, you will have to figure out how to track access to specific resources. Essentially, an audit is a systematic approach to the question of “who got what?”
Within the Windows infrastructure there are plenty of efforts directed towards this inquiry, and in most cases the inbuilt mechanisms suffice once properly configured. In this article we’ll see how far you can take these features.
On the surface, auditing configurations for Active Directory feels rather cumbersome if not downright haphazard. But this approach is actually the saner way out. Auditing differs from general logging in that you only get answers that are as helpful as your questions, so the higher resolution of options gives you room to ask yourself exactly which activities you’d like to target. It’s not just a matter of smaller, more readable logs: the complexity of modern servers means that the good old “I’ll log them all” approach is gobbling an ever increasing share of resources.
The big nine
Audit account logon events: every time a user logs on or off elsewhere, using the auditor to validate the account. It is a very common scenario, e. g.; when a log-on from an XP machine is authenticated by a domain controller. Curiously, with the exception of Server 2003, the audit is disabled by default. Do as your foreparents did and have every one of your domain controller and server audit them. You can go a bit further and have clients to do the same.
Audit account management: anything that goes on when a user manages a user, group or computer account in the auditor’s database. Creating or renaming, joining groups, and changing passwords are common examples. In this option, domain controllers behave differently from servers or clients, the former auditing to domain accounts while the latter two auditing local accounts and the Security Accounts Manager. The best practice is to have your domain controllers and server audits everything; however, bear in mind that the logs can’t capture certain user accounts.
Audit directory service accesses anything that relates to a user’s access to an Active Directory object. You have to specify all concerned objects through the System Access Control List of inpidual objects. The SACL describes three things: the user or group account under surveillance (though you can track a computer account), the type of access (r/w/etc.), and the success or failure of the access attempt.
The compartmentalized nature of the SACL translates to a very high resolution and level of control. Again, this option is disabled across all but not 2003 domain controllers. Directory Service access should be monitored for all domain controllers.
Audit logon events – records all occasions where a user logs on to, logs off from, or connects to the auditor. Perhaps a user logs on to a workstation using a domain user account. For this option, it is the workstation and not the domain controller that records the event. Put another way, unlike an audit of account logon events, an audit of logon events describes where the logon events occur, and not where the user account resides.
Audit object access – a favorite for control freaks, this option audits everything that moves. Whenever a user accesses an object, it goes down in the book.
Apart from Active Directory objects, everything in your file system, your peripherals, and even your registry keys count as an object. So long as you append a unique SACL to it, it gets monitored on access attempts.
Understandably, this option is disabled by default, and even the holiest of administrators would think it a tad over the top. If you are running an operation with very high security requirements, however, you might want to give it a go. As with all auditing at large, only track an object when you’ve got a legitimate concern, or risk spending an eternity reading logs. Of course, the real risk is when you give up the whole enterprise, thereby throwing out the baby with the bath water.
Audit policy change – any change to the triumvirate of computer policy gets logged, namely user rights assignment, trust relationships, and (behold the infinite loop) audit policies. These changes are all rather closed to the administrator’s bones, so switch it on.
Audit privilege use – in keeping with the right approach of Active Directory, this mother lode of an option logs events when users execute tasks controlled by user rights. Anything that can be restricted can be logged. While the log file comes in handy when troubleshooting, its potential size means caution discretion must be exercised.
Audit process tracks anything to do with processes: running and killing one, duplicated handles, and indirect objects. This is a long way from the realm of auditing, and you’re better off switching it on only when an application-specific issue crops up.
Audit system events – a meta-audit: System operations such as restart are pretty self-explanatory, but the option also includes security information and the last time the event log itself was cleared. For completeness, you might want to consider switching this on across all computers.
Conclusion
Essentially, auditing is measured on a task by task basis, whether it is authorized by SACL permissions, user rights on specific computers, or administrative privileges through groups. You can log success and/or failure depending on your concerns. Which is worse: someone’s accessing resources illegally? Or someone’s successfully modified core policies?
Never mind best practices. Just go through the lists, and ask yourself one paramount if confusing question on the list: what don’t I know that I would have liked to know? Then set your audit options correspondingly.
