Until Windows Server 2008, there were no specific events for file shares. But in Windows Server 2008 and later, there are two new subcategories for share related events:

• File Share
• Detailed File Share

File Share Events

This subcategory allows you to track the creation, modification and deletion of shared folders (see table below). You have a different event ID for each of those three operations. The events indicate who made the change in the Subject fields, and provides the name the share users see when browsing the network and the patch to the file system folder made available by the share. See the example of event ID 5142 below.

A network share object was added.


Subject:
Security ID:  W8R2\wsmith
Account Name:  wsmith
Account Domain:  W8R2
Logon ID:  0x475b7


Share Information:
Share Name:  \\*\AcmeAccounting
Share Path:  C:\AcmeAccounting

The bad news is that the subcategory also produces event ID 5140 every time a user connects to a share. The data logged, including who accessed it, and their client IP address is nice, but the event is logged much too frequently.

Since Windows doesn’t keep network logon sessions active if no files are held open, you will tend to see this event frequently if you enable the “File Share” audit subcategory. There is no way to configure Windows to produce just the share change events and not this access event as well.

• 5140: A network share object was accessed.
• 5142: A network share object was added.
• 5143: A network share object was modified.
• 5144: A network share object was deleted.

Detailed File Share Events

Event ID 5140, as discussed above, is intended to document each connection to a network share, and as such it does not log the names of the files accessed through that share connection. The Detailed File Share audit subcategory provides this lower level of information with just one event ID – 5145 – which is shown below:

A network share object was checked to see whether client can be granted desired access.


Subject:
Security ID:  SYSTEM
Account Name:  WIN-KOSWZXC03L0$
Account Domain:  W8R2
Logon ID:  0x86d584


Network Information:
Object Type:  File
Source Address:  fe80::507a:5bf7:2a72:c046
Source Port:  55490


Share Information:
Share Name:  \\*\SYSVOL
Share Path:  \??\C:\Windows\SYSVOL\sysvol
Relative Target Name: w8r2.com\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\Machine\Microsoft\Windows NT\Audit\audit.csv


Access Request Information:
Access Mask:  0x120089
Accesses:  READ_CONTROL
SYNCHRONIZE
ReadData (or ListDirectory)
ReadEA
ReadAttributes


Access Check Results:
READ_CONTROL: Granted by Ownership
SYNCHRONIZE: Granted by D:(A;;0x1200a9;;;WD)
ReadData (or ListDirectory): Granted by D:(A;;0x1200a9;;;WD)
ReadEA: Granted by D:(A;;0x1200a9;;;WD)
ReadAttributes: Granted by D:(A;;0x1200a9;;;WD)

This event tells identifies the user (Subject fields), the user’s IP address (Network Information), the share, and the actual file accessed via the share (Share Information) and then provides the permissions requested and the results of the access request. This event actually logs the access attempt and allows you to see failure versions of the event as well as success events.

Be careful about enabling this audit subcategory because you will get an event for every file accessed through network shares each time the application opens the file. This can be more frequent than imagined for some applications like Microsoft Office.

Conversely, remember that this category won’t catch access attempts on the same files if a locally executing application accesses the file via the local patch (e.g. c:\docs\file.txt) instead of via a patch.

You might also want to consider enabling auditing on individual folders containing critical files and using the File System subcategory. This method allows you to be much more selective about who, which files and what types of access are audited.

For most organizations, enable the File Share subcategory if it’s important to you to know when new folders are shared. You will probably want to filter out the 5140 occurrences.

Then, if you have file level audit needs, turn on the File Access subcategory, identify the exact folders containing the relevant files and enable auditing on those folders for the specific operations (e.g. Read, Write, Delete) needed to meet your audit requirements. Don’t enable the Detailed File Share audit subcategory unless you really want events for every access to every file via network shares.

Enable Audit Policy

Create a Group Policy Object and name it something to the effect of File Server Audit Policy.

We will use the Advanced Audit Policy Configuration section from now on for greater control of what we will audit on our systems: audit policy settings under Security Settings\Advanced Audit Policy Configuration are available in the following categories:

• Account Logon
• Account Management
• Detailed Tracking
• DS Access
• Logon/Logoff
• Object Access
• Policy Change
• Privilege Use
• System
• Global Object Access Auditing

Edit the GPO, browse to Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\ and define the following Audit Policy settings:

The settings below are from the Member Server Security Compliance baseline of the Security Compliance Manager (SCM) - (http://technet.microsoft.com/en-us/solutionaccelerators/cc835245.aspx) with the exception of Object Access: File System which is Enabled for Success:

Server Security Compliance:

Also remember to set the following settings, as well under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options:

• Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings to Enabled.
• Audit: Shut down system immediately if unable to log security audits to Disabled.

Event Log Size

You may need to increase the size of the Security event log to accommodate the new events generated configure the following group policy settings. This can be done with the policy setting Computer Configuration\Administrative Templates\Windows Components\Event Log Service\Security - Maximum Log Size (KB). For maximum supported sizes see http://support.microsoft.com/kb/957662.

Note: if you wish to archive old events, set Retain old events to Enabled and Backup log automatically when full to Enabled. By doing so, the event log file is automatically closed and renamed when it is full and a new file is then started. If you do not wish to retain old events, set Retain old events to Disabled.

Description Fields in 5140

Subject:

The user and logon session that accessed the share.

• Security ID: The SID of the account.
• Account Name: The account logon name.
• Account Domain: The domain or - in the case of local accounts - computer name.

Logon ID is a semi-unique (unique between reboots) number that identifies the logon session. Logon ID allows you to correlate backwards to the logon event (4624) as well as with other events logged during the same logon session.

Network Information:

• Source Address: IP Address of the client computer where the user initiated the access.
• Source Port: source TCP port of the connection - not useful.

Share Name:

The name of the share.

Description Fields in 5142

Subject:

• Security ID: The security ID of the user that added the share (If available, Active Directory is queried and the Domain\Account Name is displayed rather than the SID).
• Account Name: The user that added the share.
• Account Domain: Domain of the user that added the share.
• Logon ID: ID for the session of the user that added the share.

Share Information:

Share Name: the public name of the share.
Share Path: the UNC path of the share.

Description Fields in 5144

A network share has been deleted.

Subject:

Share Information:

Share Name: the public name of the share.
Share Path: the UNC path of the share.

Enabling File and Folder Auditing

In order to track file and folder access on Windows Server it is necessary to enable file and folder auditing and then identify the files and folders that are to be audited. Once correctly configured, the server security logs will then contain information about attempts to access or otherwise manipulate the designated files and folders. It is important to note that file and folder auditing is only available for NTFS volumes.

File and folder auditing is enabled and disabled using either Group Policy (for auditing domains, sites and organizational units) or local security policy (for single servers). To enable file and folder auditing for a single server, select Start -> All Programs -> Administrative Tools -> Local Security Policy. In the Local Security Policy tool, expand the Local Policies branch of the tree and select Audit Policy.

Double click on the Audit Object Access item in the list to display the corresponding properties page and choose whether successful, failed, or both types of access to files or folders may be audited:

Once the settings are configured click on Apply to commit the changes and then OK to close the properties dialog. With file and folder auditing enabled the next task is to select which files and folders are to be audited.

Configuring which Files and Folders are to be Audited

Once file and folder access auditing has been enabled the next step is to configure which files and folders are to be audited. As with permissions, auditing settings are inherited unless otherwise specified. By default, configuring auditing on a folder will result in access to all child subfolders and files also being audited. Just as with inherited permissions, the inheritance of auditing settings can be tuned off for either all, or individual files and folders.

To configure auditing for a specific file or folder begin by right clicking on it in Windows Explorer and selecting Properties. In the properties dialog, select the Security tab and click on Advanced. In the Advanced Security Settings dialog select the Auditing tab. Auditing requires elevated privileges.

If not already logged in as an administrator click the Continue button to elevate privileges for the current task. At this point, the Auditing dialog will display the Auditing entries list containing any users and groups for which auditing has been enabled as shown below:

To add new users or groups whose access attempts to the select file or folder are to be audited click on the Add... button to access the Select User or Group dialog. Enter the names of groups or users to audit, or Everyone to audit access attempts by all users. Click on OK to display the Auditing Entries for dialog as illustrated below:

Use the drop down list to control whether the auditing setting is to be applied to the current file or folder, or whether it should propagate down to all children files and/or sub-folders.

Finally, select which types of access are to be audited and, for each type, whether successful, failed or both kinds of attempt are to be audited. Once configured, click on OK to dismiss current dialog and then Apply the new auditing settings in the Auditing Entries dialog.

From this point on, access attempts on the selected file or folder by the specified users and groups of the types specified will be recorded in the server's Security logs which may be accessed using the Events Viewer, accessible from Computer Management.