Auditing the Environment

Auditing is a way to gather and keep track of activity on the network, devices, and entire systems. By default, Windows Server 2003 enables some auditing, whereas many other auditing functions must be manually turned on. This allows for easy customization of the features the system should have monitored.

Auditing is typically used for identifying security breaches or suspicious activity. However, auditing is also important to gain insight into how the network, network devices, and systems are accessed. As it pertains to Windows Server 2003, auditing can be used to monitor successful and unsuccessful events on the system. Windows Server 2003's auditing policies must first be enabled before activity can be monitored.

Auditing Policies

Audit policies are the basis for auditing events on a Windows Server 2003 system. Depending on the policies set, auditing may require a substantial amount of server resources in addition to those resources supporting the server's functionality. Otherwise, it could potentially slow server performance. Also, collecting lots of information is only as good as the evaluation of the audit logs. In other words, if a lot of information is captured and a significant amount of effort is required to evaluate those audit logs, the whole purpose of auditing is not as effective. As a result, it's important to take the time to properly plan how the system will be audited. This allows the administrator to determine what needs to be audited, and why, without creating an abundance of overhead.

Audit policies can track successful or unsuccessful event activity in a Windows Server 2003 environment. These policies can audit the success and failure of events. The types of events that can be monitored include

• Account logon events Each time a user attempts to log on, the successful or unsuccessful event can be recorded. Failed logon attempts can include logon failures for unknown user accounts, time restriction violations, expired user accounts, insufficient rights for the user to log on locally, expired account passwords, and locked-out accounts.

• Account management When an account is changed, an event can be logged and later examined.

• Directory service access Any time a user attempts to access an Active Directory object that has its own system access control list (SACL), the event is logged.

• Logon events Logons over the network or by services are logged.

• Object access The object access policy logs an event when a user attempts to access a resource (for example, a printer or shared folder).

• Policy change Each time an attempt to change a policy (user rights, account audit policies, trust policies) is made, the event is recorded.

• Privileged use Privileged use is a security setting and can include a user employing a user right, changing the system time, and more. Successful or unsuccessful attempts can be logged.

• Process tracking An event can be logged for each program or process that a user launches while accessing a system. This information can be very detailed and take a significant amount of resources.

• System events The system events policy logs specific system events such as a computer restart or shutdown.

The audit policies can be enabled or disabled through either the local system policy, domain controller security policy, or Group Policy Objects. Audit policies are located within the Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy folder, as shown in Figure 22.4.

Figure 22.4. Windows Server 2003 audit policies.

Tracking Logon and Logoff Events

As mentioned earlier, both successful and unsuccessful account logon and logoff events can be audited. By default, Windows Server 2003 audits successful account logon and logoff events. When the audit policy is enabled, events are cataloged in the Event Viewer's Security log.

Monitoring Resource Access

After enabling the object access policy, the administrator can make auditing changes through the property pages of a file, folder, or the Registry. If the object access policy is enabled for both success and failure, the administrator will be able to audit both successes and failures for a file, folder, or the Registry.

Note

Monitoring both success and failure resource access can place additional strain on the system. It is therefore recommended to test this in a segmented lab environment prior to implementing this level of auditing in the production environment.

Monitoring Files and Folders

The network administrator can tailor the way Windows Server 2003 audits files and folders through the property pages for those files or folders. Keep in mind that the more files and folders that are audited, the more events that can be generated, which can increase administrative overhead. Therefore, choose wisely which files and folders to audit. To audit a file or folder, do the following:

1.	In Windows Explorer, right-click the file or folder to audit and select Properties.
2.	Select the Security tab and then click the Advanced button.
3.	In the Advanced Security Settings window, as shown in Figure 22.5, select the Auditing tab. Figure 22.5. The Advanced Security Settings window.
4.	Click the Add button to display the Select User or Group window.
5.	Enter the name of the user or group to audit when accessing the file or folder. Click the Check Names button to verify the name.
6.	Click OK to open the Auditing Entries window.
7.	In the Auditing Entries window, shown in Figure 22.6, select which events to audit for successes or failures. Figure 22.6. The Auditing Entries window.
8.	Click OK three times to exit.

When the file or folder is accessed, an event is written to the Event Viewer's Security log. The category for the event is Object Access. An Object Access event is shown in Figure 22.7.

Figure 22.7. An Object Access event in the Security log.

Monitoring Printers

Printer auditing operates on the same basic principles as file and folder auditing. In fact, the same step-by-step procedures for configuring file and folder auditing apply to printers. The difference lies in what successes and failures can be audited. These events include

• Print

• Manage printers

• Manage documents

• Read permissions

• Change permissions

• Take ownership

These events are stored in the Event Viewer's Security log.