File-Level Security for SharePoint Servers

As discussed in a previous section, SharePoint controls access to files stored within its database through user authentication, site groups, and similar SharePoint-specific security mechanisms. In addition to these considerations, care must be taken to secure actual file-level access to SharePoint itself. A secured database is useless if an unauthorized user can simply delete it or copy it off. A full understanding of the file-level security inherent in Windows Server 2003 is a must for a complete understanding of SharePoint security itself.

Exploring NT File System Security

The latest revision of the NT File System (NTFS) is used in Windows Server 2003 to provide for file-level security in the operating system. Each object referenced in NTFS, which includes files and folders, is marked by an Access Control Entry (ACE) that physically limits who can and cannot access a resource. NTFS permissions utilize this concept to strictly control read, write, and other types of access on files.

Although SharePoint servers are not often file servers, they can still grant or deny file access in the same way and should have the file-level permissions audited to determine whether there are any holes in the NTFS permission set. Changing NTFS permissions in Windows Server 2003 is a straightforward process; simply follow these steps:

1.	Right-click the folder or file onto which the security will be applied and choose Sharing and Security.
2.	Select the Security tab.
3.	Click the Advanced button.
4.	Uncheck the Allow Inheritable Permissions from the Parent to Propagate box.
5.	Click Remove when prompted about the application of parent permissions.
6.	While you're in the Advanced dialog box, use the Add buttons to give access to the groups and/or users who need access to the files or folders.
7.	Check the Replace Permission Entries on All Child Objects box, as shown in Figure 15.9, and click OK. Figure 15.9. Setting NTFS permissions. NOTE Care should be taken when applying security settings; propogating incorrect security settings can lock out all subfolders on a server. When modifying security, a full understanding of the directory structure is required.
8.	When prompted about replacing security on child objects, click Yes to replace child object security and continue.
9.	Click OK to close the property page.

Comparing Share-Level Security Versus NTFS Security

Previous Windows security used share-level permissions, which were independently set. A share is a file server entry point, such as \\sfofs01\marketing, that allows users access to a specific directory on a file server. Older file systems such as FAT, HPFS, and FAT32 did not include file-level security, so the security was set instead on the share level. While share-level security can still be set on files, it is preferable to use NTFS-level security, where possible. Share-level security is not very secure because it cannot secure the contents of subdirectories easily.

NOTE

Best practice for file servers in Windows Server 2003 is to configure share-level security to be wide open for all domain users but then to set stricter security on the NTFS level. This allows for security to be administered on the NTFS level only, without the fear of share-level restrictions interfering. A dedicated SharePoint server should normally not utilize specific shares.

Auditing File Access to SharePoint Servers

A good practice for file-level security is to set up auditing on a particular server, directory, or file. Auditing on NTFS volumes allows administrators to be notified of who is accessing, or attempting to access, a particular directory. For example, it may be wise to audit access to a critical network share, such as a finance folder, to determine whether anyone is attempting to access restricted information. After auditing has been turned on via a local or group policy, the following steps can be taken to set up simple auditing on a folder on a SharePoint server:

1.	Right-click the folder or file onto which the auditing will be applied and choose Properties.
2.	Select the Security tab.
3.	Click the Advanced button.
4.	Select the Auditing tab.
5.	Uncheck the Allow Inheritable Auditing Entries from the Parent to Propagate box and click Apply.
6.	Using the Add button, enter all users and groups that will be audited. If you're auditing all users, enter the Everyone group.
7.	In the Auditing property page, select all types of access that will be audited. If you're auditing for all success and failure attempts, select all the options, as indicated in Figure 15.10. Figure 15.10. Selecting what to audit.
8.	Click OK to apply the settings.
9.	Check the Replace Auditing Entries on All Child Objects box and click OK twice to save the settings.