Windows & Active Directory Auditing
If you are like most administrators, you want to know who is logging on, to which computer, and accessing resources on your servers. For your Windows computers and Active Directory environment, you have options to help you determine what you want to know.
If you fall into the category of a highly-secure environment, where you need to track access to some or all of the resources on the network, you also have options to help you track the access to the resources. The feature in Windows that provides this tracking and logging of who is accessing which resource from computers on the network is called auditing. There are numerous auditing options and configurations that you can choose from. We will take a look at each option and go over what each option can provide for you. Your Auditing Buffet Options
When you set out to configure auditing for computers on your network, you will find that there are numerous options for you to choose from. This granularity helps in many ways. First, it allows you to target specific activities, instead of taking a wider sweep of all activity on a computer. Second, with a narrower scope of what you are auditing, will result in smaller logs which make reviewing the logged information more efficient. Finally, reducing the auditing options to just what you need will reduce the load on the computer, allowing it to provide more resources to other activities.
Audit account logon events – This will audit each time a user is logging on or off from another computer in which the computer performing the auditing is used to validate the account. The best example of this is when a user logs on to their Windows XP Professional computer, but is authenticated by the domain controller. Since the domain controller is validating the user, the event would be generated on the domain controller. This setting is not enabled for any operating system, except for Windows Server 2003 domain controllers, which is configured to audit success of these events. It is common and a best practice to have all domain controllers and servers audit these events. I also find that in many environments clients are also configured to audit these events. Audit account management – This will audit each event that is related to a user managing an account (user, group, or computer) in the user database on the computer where the auditing is configured. Examples of these events include:
* Creating a user account * Adding a user to a group * Renaming a user account * Changing a password for a user account
For domain controllers, this will audit changes to domain accounts, as described in the following article named Auditing Users and Groups with the Windows Security Log. For a server or client, it will audit the local Security Accounts Manager and the accounts that reside there. This setting is not enabled for any operating system, except for Windows Server 2003 domain controllers, which is configured to audit success of these events. It is common and a best practice to have all domain controllers and servers audit these events. For auditing of the user accounts that the security logs and audit settings can’t capture, refer to the article named Auditing User Accounts.
Audit directory service access – This will audit each event that is related to a user accessing an Active Directory object which has been configured to track user access through the System Access Control List (SACL) of the object.
The SACL of an Active Directory object specifies three things:
* The account (typically user or group) that will be tracked * The type of access that will be tracked, such as read, create, modify, etc * Success or failure access to the object
Since each object has its own unique SACL, the level of control over which Active Directory object will be tracked can be very precise. This setting is not enabled for any operating system, except for Windows Server 2003 domain controllers, which is configured to audit success of these events. It is a best practice to enable both success and failure auditing of directory service access for all domain controllers.
Audit logon events – This will audit each event that is related to a user logging on to, logging off from, or making a network connection to the computer configured to audit logon events. A good example of when these events are logged is when a user logs on interactively to their workstation using a domain user account. This will generate an event on the workstation, but not on the domain controller that performed the authentication. In essence, logon events are tracked where the logon attempt occurs, not where the user account resides. This setting is not enabled for any operating system, except for Windows Server 2003 domain controllers, which is configured to audit success of these events. It is common and best practice to log these events on all computers on the network.
Audit object access – This will audit each event when a user accesses an object. Objects include files, folders, printers, Registry keys, and Active Directory objects. In reality, any object that has an SACL will be included in this form of auditing. Like the Auditing of directory access, each object has its own unique SACL, allowing for targeted auditing of individual objects. There are no objects configured to be audited by default, which means that enabling this setting will not produce any logged information. Once this setting is established and a SACL for an object is configured, entries will start to show up in the logs on access attempts to the object. It is not common to configure this level of auditing until there is a specific need to track access to resources. In highly secure environments, this level of auditing is usually enabled and numerous resources are configured to audit access.
Audit policy change – This will audit each event that is related to a change to one of the three “policy” areas on a computer. These policy areas include:
* User Rights Assignment * Audit Policies * Trust relationships
This setting is not enabled for any operating system, except for Windows Server 2003 domain controllers, which is configured to audit success of these events. It is common and best practice to configure this level of auditing for all computers on the network.
Audit privilege use – This will audit each event that is related to a user performing a task that is controlled by a user right. The list of user rights is rather extensive, as shown in Figure 3.
This level of auditing is not configured to track events for any operating system by default. It is common and a best practice to configure this level of auditing for all computers on the network.
Audit process tracking – This will audit each event that is related to processes on the computer. Examples would include program activation, process exit, handle duplication, and indirect object access. This level of auditing produces an excessive number of events and is typically not configured unless an application is being tracked for troubleshooting purposes.
Audit system events – This will even audit an event that is related to a computer restarting or being shut down. Events that are related to the system security and security log will also be tracked when this auditing is enabled. This is a required audit configuration for a computer that needs to track not only when events occur that need to be logged, but when the log itself is cleaned. This setting is not enabled for any operating system, except for Windows Server 2003 domain controllers, which is configured to audit success of these events. It is a best practice to configure this level of auditing for all computers on the network.
Success or Failure Auditing?
Each of these options provide two configuration settings: Success and/or Failure. These options are essential to help you track the required information that is generated from a user performing a task. Tasks are typically related to one of the following:
* Permissions configured on the Access Control List of a resource * User Rights configured for a specific computer * Administrative privileges, typically granted through group membership
If the user attempts to perform a task which they have not been granted permission for will result in a failure to perform the task. For example, if a user attempts to change the time on their laptop, but they are not in the local Administrators group, this will generate a failed attempt to “Change the System Time,” which is a User Right granted directly to users or groups of users, including the Administrators group.
The flip side of this is also true, where if a user attempts to perform a task which they have been granted the appropriate permission, they will generate a success trigger for that task. A good example here might be a user that has been delegated permissions to modify the membership of a group located in Active Directory.
As you can see, depending on what you want to track, success or failure, will need to be setup when you enable the specific auditing setting. Conclusion
With so many options for tracking events in a Windows environment, it is important to understand what each option provides through the security log of the event viewer. It is also important to know and recognize the default settings, which are not always set to properly track events for your important member servers. Finally, you were provided with some best practice recommendations for these settings, which you should decide if your environment should accept the same settings.