Role of Active Directory Auditing in Security
Chalk it up to human nature, but it is 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 on to which computer? Which resources are they requesting? This tracking and logging of who is accessing which resource from computers on the network is called auditing.
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 figure out how to access specific resources. Essentially, an audit is a systematic approach to the question of who got what.
Within the Windows infrastructure, there is plenty of effort directed towards this inquiry, and in most cases, the in-built Mechanism suffice once properly configured. In this article we’ll see how far you can take these features.
Auditing Options:
- Audit account logon events: This will audit each time a user logs on or off elsewhere, using the auditor to validate the account. It is 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.
- Audit account management: This will audit 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 changes to domain accounts while the latter two auditing the Security Accounts Manager and the accounts present there. The best practice is to have your domain controllers and servers audit everything; however, bear in mind that the logs can’t capture certain user accounts.
- Audit directory service access: This will audit 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 (SACL) of individual 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 2003 domain controllers. Directory Service access should be monitored for all domain controllers.
- Audit logon events: This records all occasions where a user logs on to, logs off from, or connects to the auditor. Perhaps a user logs onto 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: This is 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.
- Audit policy change: This audits any change to computer policies, namely user rights assignment, trust relationships, and audit policies. These changes are all rather close to the administrator’s bones, so switch it on.
- Audit privilege use: In keeping with the rights-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 tracking: This will audit anything that has something to do with processes on the computer e.g. running and killing one, handle duplication, indirect objects etc. This is a long way from the realm of auditing, and you’re better off switching it on only when an application-specific issue creeps up.
- Audit system events: System operations such as restarts are pretty self-explanatory, but this 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: what would I like to know? Then set your audit options correspondingly.
