Auditing the SharePoint Server Environment

Auditing is a way to gather and keep track of activity on the network, devices, and entire systems. By default, the operating system for SharePoint, Windows Server 2003, enables some auditing, whereas many other auditing functions must be turned on manually. 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.

Understanding Auditing Policies

Audit policies for Windows Server 2003 are the basis for auditing events on a SharePoint 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. Other wise, it could potentially slow server performance. Also, collecting a lot 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 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 or Group Policy objects in an Active Directory domain, as shown in Figure 18.14.

Figure 18.14. 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 to SharePoint servers. When the audit policy is enabled, events are catalogued in the Event Viewer's Security log.

Monitoring Resource Access

After enabling the object access policy, a SharePoint 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 can 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 on a SharePoint Server

A SharePoint 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 follow these steps:

1.	On the SharePoint server, open 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, select the Auditing tab, as shown in Figure 18.15. Figure 18.15. Configuring auditing in the Advanced Security Settings window.
4.	Click the Add button to display the Select User, Computer, 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 18.16, select which events to audit for successes or failures. Figure 18.16. 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.

NOTE

This procedure enables auditing of files that exist on the SharePoint server itself, not documents within document libraries in the portal. To enable this type of auditing, utilize SharePoint alerts.