Find the Who, What, Where and When of Your Active Directory

Do you only look at log files when you have been attacked?

You can use Active Directory to capture information about every attempt to access a network or any computer resource. This is a good news and bad news situation. The good news is that you can capture in log files and all the data you could ever possibly need, the bad news is that the amount of data you collect can be overwhelming and require a seasoned professional to understand and interpret. Given this, the challenge is not can you capture the data, rather the challenge is do you know what data you need to capture in your log files.

The security logs created by Active Directory are central to an organization’s security policies. They guard against unauthorized access, data leakage, policy violations and other fraudulent activities. Compliance to legal and regulatory requirements, such as data protection laws, is compulsory and generally requires audit events to be captured and securely stored in log files. All businesses are concerned with operational effectiveness and most cannot afford to have administrative staff constantly monitoring every service they are running. It is therefore critical for operational efficiency that organizations deploy tools that help monitor and analyze their Active Directory log files to identify issues needing administrator attention. Examining events in log files is invaluable in troubleshooting Active Directory problems. Log files enable you to see what was happening prior to the problem occurring, which then helps you replicate and subsequently resolve the issue.

Windows Server 2008 has several different log files. There are five Windows logs that record events that happen on the computer such as a database error, a user logging on, or a failure of a driver to load correctly. There are also seven applications and services logs that capture events such as a printer was added to the network. This article is about helping you find out who, what, where, and when of your Active Directory system. To do this you will need to look at the security log and the directory service log.

Who is changing your Active Directory system?

The directory service log captures all of the operational transactions of Active Directory. For example it will capture if a user has been created, if a user has been assigned to a group, or if a user’s information has been changed.

The directory service log contains three types of events, namely information, warnings and errors. Information events are the lowest priority and errors are the highest priority. You can display the directory service logs with the event viewer by selecting Applications and Service Logs > Directory Service as shown in figure 1.

Figure 1: Accessing the Directory Service log

There are six logging levels, 0 to 5. The level 0 provides the minimum amount of information and level 5 provides the greatest amount of information. By default, the logging levels for each event category, such as security events and internal configuration events, are set to 0. You can increase the event logging level for an entry category by editing the Active Directory registry. This can be particularly useful if you are using the logs to troubleshoot problems.

It is a best practice to have a policy in place that allows only experienced administrators change your Active Directory registry and that a backup of the system should be done before changing the registry. Also be warned that raising the logging level will create significantly increase the data being captured, which means that you will need to increase the size of your log file. To increase the size of your log file simply right click on the directory services log in the event viewer, and select properties. You can then select the maximum log file as well as the action you want taken when the log file reaches its maximum size. If you are not archiving your log files then you should select the option “overwrite events as needed”. If you plan to archive your log files then you should select the option to archive the log when full.

What events will you capture in your log file?

The security log is one of the five Windows logs that you can also look at in the event viewer. Events captured in the security log are called audit events, and the event is either a success or a failure. For example did the user logon successfully or did someone attempt but failed to logon. Depending on your security and IT needs, you will need to enable the Audit Policies that defines the audit events that you wish to capture.

To enable an audit policy you need to open Group Policy Management Editor and select Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies, as shown in figure 2 below. You can see in this figure that you can set up the audit policies to capture several event categories. These categories include account management such as adding or deleting a user or group; account logon events that capture user logons on a domain and logon/logoff events that capture user logons to a computer, policy change events that tracks changes to policies such as user rights and privileges, and system events capture events that impact system resources such as system startups and full log files. The object access category allows you to create audit events when users access specific Active Directory objects such as an organization unit. You can also use the object access category to create audit events to track when specific computer resources are accessed, such as a confidential personal files or folders, or sensitive resources such as registry keys.

Figure 2: Audit event categories.

Who is accessing your computer resources?

If you wish to create an audit event when a user attempts to logon to a computer you would click audit logon/logoff and then audit logon. This is illustrated in figure 4. In this example, the pop-up window gives you the opportunity to log an audit event every time a user successfully logons and/or every time someone fails to logon. For example many businesses closely monitor failed logons but not successful logons, as they are looking for maliciously attempts to access the system. Once you apply these settings you will be able to see logon attempts in your security log file.

Figure 3: Configuring an audit policy for user logons.

If you want to see which users are assessing a computer resource such as a printer, a file system or a specific folder you would set the audit policy that is called Object Access. However an audit event is only created for objects that have System Access Control List (SACL) associated with them and you have configured the audit setting.

You can set a SACL and audit setting for a folder or file by right clicking the folder that you wish to protect, selecting properties and then selecting the security tab. To set the SACL you need to select edit. In the illustration shown in Figure 4, the selected folder is called “Avril Secrets”. You can now set up a SACL for the selected folder. The SACL for a folder can be defined such that the permissions are propagated to all of the subfolders. It can also be set up such that permissions on the folder cannot be changed. Click OK to save your changes.

Figure 4: Configuring a System Security Access Control List (SACL).

Having set up the SACL, you now need to specify the auditing policy. You set the audit settings in the same security tab but you click the advanced button, and then select the Auditing tab. You can now add the users, groups or computers that you wish to audit. Figure 5 below shows that the users object has been selected and in this illustration both the successful and the failed attempts to access the “Avril Secrets” folder will be logged.

Figure 5: Defining your audit entries.

Reasons you may wish to capture successful accesses to a specific folder may include the ability to track the access to the folder for billing purposes, for auditable proof that the resource was used, and to identify changes in access behavior. Reasons that you may wish to log access failures may be to identify if there have been fraudulent attempts to access or damage a resource.

Now you have defined the auditing events, the final step is to enable your audit policy object access. This step is illustrated in figure 6. Your Active Directory will now begin to log access to your files or folders.

Figure 6: Configure the audit file system events.

Turning log files into meaningful business information

You can see that it would be easy to create huge log files that are impossible for an administrator to manually inspect and identify problems. Fortunately event viewer provides you with the ability to filter the log files and create customized views of the data and this alleviates the problem to some extent. However if you are capturing large amounts of data in log files it is burdensome on an administrator to filter out all the different events. To manage this situation most enterprises invest in tools that monitor, analyze and report on the captured data.

The types of tools that you select will vary depending on your business needs and the amount of data you are collecting. For example a financial institution may be legally required to maintain their log files for several years. In this situation they would benefit from a log management tool that automated the archiving, retrieval and disposal of their log files in a highly secure manner.

Independent of your specific business needs, there are four things that should be part of any log management tool. First, the tool should provide real-time monitoring of your logs and alert when certain events happen. For example if you provide online webcasts you may need to monitor access to specific folders or files for billing purposes, or if you may wish to know if an unauthorized person is trying to gain access to your sensitive data. The tool should also be meaningful to both business staff and IT administrators. Logs can be quite cryptic and difficult to interpret, therefore how the tool analyses the data and presents the data is an essential consideration in selecting any log management tool. In addition the tool should be capable of analyzing log files in multiple formats from multiple sources. For example, if you are investigating a security breach ideally you need a tool that can look at data from your security log along with data from your directory service log. Lastly you need a tool that has powerful filtering and search options.

The ability to collect, monitor and analyze log files is essential in all business environments. It will help you improve your operational effectiveness, troubleshoot problems and flag security concerns. Remember however, capturing data in log files is only one part of the solution. You will also need to define best practices and operational policies for handling your log files. For example, who can access your logs, how long will you keep your logs, where will you keep them and how will you dispose of them. This may be a subject for a later article.

About the Author