What is Windows Auditing?

Security is an ever increasing concern in almost every area of society today and computers are no exception. A detailed computer security plan should not only include policies and procedures to ensure that proper access rights are configured for all users, it must also include methods for verifying that these rights are effectively deployed throughout the network. Being able to see what your network users are doing is not a bad thing either.

Windows auditing is one such method for obtaining information about how effective your security practices are. In this article I will give a quick overview of Windows auditing and what it can do for you.

What Is It?

Windows auditing is a mechanism for tracking events. Knowing when and where these events occurred and who triggered them can help when doing Windows network forensics. It can also be very helpful with detecting certain types of problems like improper rights assignments in the file system.

Dozens of events can be audited in Windows. The events fall into several categories:

  • Audit account logon events – audit each instance of a user logging on to or logging off from another computer in which this computer is used to validate the account. This event category is applicable to domain controllers only since DC’s are used to validate accounts in domains.
  • Audit account management – audit each event of account management on a computer. Examples of account maintenance include password changes, user account and group modifications.
  • Audit directory service access – audit the event of a user accessing an Active Directory object that has its own system access control list (SACL) specified.
  • Audit logon events – audit each instance of a user logging on to or logging off from a computer. Note that this is different than the ‘Audit account login events’ category. This tracks the logon event to a specific server. The former tracks which domain controller authenticated the user.
  • Audit object access – audit the event of a user accessing an object that has its own system access control list (SACL) specified. Examples of objects are files, folders, registry keys, printers, etc.
  • Audit policy change – audit every incident of a change to user rights assignment policies, audit policies, or trust policies.
  • Audit privilege use – audit each instance of a user exercising a user right.
  • Audit process tracking – audit detailed tracking information for events such as program activation, process exit, handle duplication, and indirect object access.
  • Audit system events – audit when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log.

    • Each category has several event types that may be triggered. Each category may be enabled for auditing of successful of failed events. This allows you to track when a user was able or unable to do or access something. Enabling any of these audit categories will cause Windows to write messages to the event log whenever an audited event occurs.

    Why You May Need It

    There are dozens of events that may be audited in Windows, but I can see a strong reason to use only but a few of them.

    For example, using the ‘audit account logon’ and the ‘audit account management’ events are very helpful in determining when and where a user was logged on when some network infraction occurred. Similarly, auditing object access can also produce useful forensic data. However the ‘audit process tracking’ setting probably only has usefulness when debugging applications.

    In any event (no pun intended), having access to a wealth of audit data is much better than having too little or none at all. Windows auditing does make it possible to monitor many aspects of Windows network usage. This is especially useful in large Windows shops where multiple groups may administer different portions of the Windows network and all groups have to provide information about their activities to an audit team. In this scenario, Windows auditing can be used to provide empirical data to help prove that each admin team is in compliance with company standards and best practices.

    What You Can Do With It

    I’ve already discussed a bit about what you can use Windows auditing for. However, let’s take a closer look at auditing logon events.

    Several years ago I was asked to provide reports about who attempted and failed to access certain Domino (Domino is IBM’s competitor to MS Exchange) servers and databases. I thought that this was a silly thing to do. If the user failed to get access to a resource, more than likely it was because the user had no access rights to the resource. This meant that Domino was working as designed. If the user should have access to the resource, he could call the service desk and open a ticket in order to get access. Why then would we need to track this?

    As it turns out, this was an excellent thing to do. I enabled Domino events (the equivalent of Windows auditing) on a few servers and sent the data through a series of processes that parsed and then exported the data to a SQL server. Once in a relational database, I could query the data as I saw fit.

    Well, the reports showed that we had some very curious (devious?) users that would attempt to access all sorts of things (the president’s email) that they should not have been. In short we impressed the auditors and turned the proper corporate authorities on to these evil users. Score one for the good guys.

    Do you see the point of this story? This basic technique can be applied to any system that produces audit logs. And therefore it also applies to Windows.

    What’s Next

    There is not a central repository for audit event data in Windows. Events are logged on the server for which the event occurred. So you will need some sort of tool to gather events from all relevant servers.

    That brings us to a quick discussion of EventComb. EventComb is a free tool from Microsoft that can pull specified event log records from any number of servers into a text file. This tool will handle gathering the event data into a centralized spot. At this point you’ve got a few options to review the data EventComb has retrieved.

    1. You could manually view the log file that EventComb creates.  
    2. You could process the data with a tool like grep or the Windows find shell command to look for interesting text strings (I.e. Failed network logon)  
    3. You could process the entire file with a script that is set to look for certain strings  
    4. You could parse the whole thing and send it off to relational data base so that querying and archiving is much easier

    The option you choose is heavily dependant on the size of you network. For a small network, it may not worth the time to setup a system as described in option four. It is probably enough to use EventComb and view the log file manually. I even know of some single Windows server shops in which using EventComb is overkill.

    For More Information

    The best sources of information about Windows auditing are The Windows product documentation and Mark Minasi’s book Mastering Windows Server 2003.

    For more information about EventComb, search the Microsoft website.

    For information about the grep tool, check the grep page at the free software foundation website at http://www.gnu.org/software/grep/.

    For information about the find shell command, read the help screen on the find command by typing the following in a Windows command line ‘find /?’. The book NT Shell Scripting by Tim Hill is quite good as well.

    Importing audit data into a relational database such as MS SQL Server is way beyond the scope of this article. To accomplish that task, you would need to know a programming language such as vbscript, SQL, and either SSIS or DTS. However, in a large environment it is well worth the effort to pursue this option.

    Recent Security Forum threads

    Got a question? Post it on our Security Forums!