Securing Web Applications

Web applications contain all of your valuable user content and also provide the bedrock for the security of your site collections. The foundation of security is authentication, and SharePoint products authentication is usually provided by Internet Information Services (IIS), but can be provided by ASP.NET via pluggable authentication.

Internet Information Services

If your SharePoint servers are Intranet only and therefore private, then you may not need to secure traffic. If your SharePoint servers are Internet-facing, however, you should consider encrypting the inter-server and client-server traffic. Collaborative sites that are Internet-facing sites should always use Secure Sockets Layer (SSL) for communication. Using SSL helps ensure that external traffic does not expose proprietary or confidential organizational content, and it protects user authentication.

Secure Sockets Layer

Secure Sockets Layer (SSL) was developed to transmit data over networks securely. The use of SSL is encouraged for most Web applications, but does add some complexity to your implementation. In addition, because SSL can also affect server performance; always test your design before implementing it on a large scale. To enable SSL for a Web application during creation, check the Use Secure Sockets Layer (SSL) option button and then install the SSL certificate in IIS Manager. To enable an existing Web application for SSL, you must do the following:

1. Open Central Administration from the Start Menu.

2. Go to Operations > Global Configuration > Alternate Access Mappings.

3. Locate the Web application you wish to enable with SSL and edit the default internal URL by clicking the name under Internal URL.

4. Change the URL protocol, as shown in Figure 7-1.

5. Click OK.

6. From IIS Manager, add the certificate to the Web application's IIS virtual server.

Figure 7-1: To edit the default Internal URL, select the hyperlink.

Note 

If your servers need to communicate sensitive data over a public network, as is the case with Inter-Farm Shared Services, you should strongly consider using SSL for every Web server that connects to the Internet.

Integrated Authentication

Integrated authentication provides a transparent authentication mechanism for Intranet and limited Extranet SharePoint applications. Integrated authentication hashes the current username and password and then sends the hash to the authenticating server. When using integrated authentication, the hashing and authentication are done automatically using the currently logged-on username and password. This process increases the transparency to the user because no input is required to visit SharePoint servers. There are two types of integrated authentication:

• Kerberos Kerberos is the preferred authentication mechanism for internal SharePoint Web applications. Because both the client and IIS server must see the Key Distribution Center (KDC), Kerberos does not work with most Internet-facing SharePoint solutions. To enable Kerberos, simply choose the option during Web application creation. Remember, to use Kerberos, you must configure a Service Principal Name (SPN) for the Web application pool identity. To configure an SPN, follow these steps:

  1. Download the Setspn.exe tool from http://www.microsoft.com/downloads/details.aspx?FamilyId=.

  2. From the command prompt, execute setspn.exe -A HTTP/ServerName Domain\username. The username should be the Web application pool identity.

  3. Perform an IISReset.exe from the command line.

  To enable Kerberos for an existing Web application, perform the following steps in addition to setting the SPN:

  1. Find your Web application's IIS virtual server ID. Go to the IIS Manager Web Sites folder, and look for ID in the identifier column.

  2. From the command line, execute

      Cscript c:\intepub\adminscripts\adsutil.vbs set w3svc/<ID>/root/NTAuthenticationProviders "Negotiate,NTLM" 

  If possible, it is a good idea to enable both Kerberos and NTLM. Doing this ensures user authentication if Kerberos fails. Unfortunately, this dual enabling cannot be done from Central Administration. The preceding list explained how to enable Kerberos (Negotiate) and NTLM from the command line. This action must be performed on each server that will serve content via the Kerberos-secured Web application. Note that IIS authenticates from the most-secure protocol to the least-secure protocol. Therefore, your users will authenticate with Kerberos first, if both protocols are enabled.

• NTLM NTLM works with most Windows SharePoint Services and SharePoint Server installations without further configuration. However, NTLM isn't as secure as Kerberos and should be considered insecure unless password lengths are longer than 14 characters. NTLM can also fail when traversing proxy servers, because it is connection-based and proxies don't always sustain connections. Additionally, not all browsers support NTLM and Kerberos and will require basic authentication support on the servers.

Basic Authentication

For remote users, users behind proxy servers, or non-Windows clients or to accommodate a custom program, you may implement Basic Authentication. Basic Authentication supports most browsers and works from almost anywhere on the Internet. Its downside is that the username and password are sent as Base64 clear text. This information is easily compromised, unless it is secured using encryption. Therefore, always use Basic Authentication in conjunction with an SSL-secured Web application. This sufficiently protects the username and password from compromise. To enable Basic Authentication, do the following:

1. Enable SSL, as shown earlier.

2. Open Central Administration, and browse to Application Management.

3. In Application Security > Authentication Providers, choose the Web application to manage, as shown in Figure 7-2.

4. Select the zone to modify, usually Default.

5. From the bottom of the page, check Basic Authentication (Password Is Sent In Clear Text).

6. Click Save.

Figure 7-2: Verify the Web application before modifying authentication providers.

Enabling Anonymous Access

Care should be taken when enabling anonymous access. Although security is always important in a site collection when creating users and groups, it is particularly important when anonymous access is enabled in the Web application and site collection. Be sure to limit access for users with anonymous access. If a site collection is primarily used for collaboration, you should strongly consider limiting anonymous access when possible. Always perform authentication provider changes from Central Administration, not from IIS Manager. To enable anonymous access, you must do so on the Web application and the site collection. To enable anonymous access for a Web application, browse to Central Administration > Application Management > Application Security > Authentication Providers > Edit Authentication. After enabling anonymous access for the Web application, you must then enable anonymous access for a site collection using these steps:

1. From the site collection, open Site Actions > Site Settings.

2. In the Users and Permissions column, select Advanced Permissions.

3. On the Settings menu tab, select Anonymous Access in the drop-down menu. If you do not see Anonymous Access listed, then Anonymous Access is not enabled for the hosting Web application.

4. Select the portion of the site to which you will allow anonymous access: Entire Web site, Lists and Libraries, or nothing.

If you enabled List and Libraries previously, for example, follow these steps to enable anonymous access on a document library:

1. Browse to the document library on which you would like to enable anonymous access.

2. From the Settings drop-down menu, select Document Library Settings.

3. Under Permissions and Management, select Permissions for this document library.

4. If not already done, you must break inheritance by selecting Edit Permissions from the Actions drop-down menu.

5. Select OK when warned that you will create unique permissions for this document library.

6. From the Settings drop-down menu, select Anonymous Access.

7. Select the permission you wish to grant anonymous users.

Configuring User Permissions for Web Applications

When modifying user permissions for Web applications in Central Administration, be aware that changes are applied immediately and can cause site collection failure. User permissions are managed on an individual Web application basis so you may have a unique policy for each Web application. Always verify that you are modifying the correct Web application before modifying permissions. Many an administrator has accidentally modified the wrong Web application.

The permissions available from Central Administration > Application Management > Application Security > User Permissions For Web Applications are those that are available in site collections contained within that Web application. If you disable Delete Versions, for example, that option will not be available to site collections in the selected Web application. Figures 7-3 and 7-4 show the correlation between Web application security settings and site collection security settings.

Figure 7-3: Changing the Web application security settings affects what permission levels are available for site collections within that Web application.

Figure 7-4: If a permission level isn't available, check the Web application security settings for the host Web application.

Re-enabling a permission level for a Web application in Central Administration allows the level to be used once again in all site collections contained in the selected Web application. Be cautious when making changes to large Web applications because every site collection contained in it is then modified by the system. This modification can cause a very large spike in CPU utilization, which possibly may deny service to users.

Configuring Antivirus Settings

The installation of a correctly configured antivirus program is essential to protecting content in your SharePoint environment. To configure antivirus settings, you must have a SharePoint-aware antivirus program. A standard antivirus version for Windows Server 2003 will not scan items in SharePoint databases. When installing the SharePoint antivirus program, the program must exist on all WFE servers before continuing configuration. To configure antivirus for SharePoint products, perform these actions:

1. Open Central Administration from the Start Menu.

2. Browse to the Operations interface, Security Configuration, and select Antivirus.

3. Configure Antivirus Settings.

   These settings allow you to define whether files are scanned on upload, download, or both and to define actions taken on infected documents. It is wise to prohibit users from downloading infected documents, except in special circumstances, such as mission-critical environments.

4. Configure Antivirus Time Out.

   The default is set to 300 seconds, but this length of time should probably be reduced. If your server performance is suffering and you are antivirus-enabled, consider starting at a 60-second time out duration and increasing until performance again decreases.

5. Configure Antivirus Threads.

   The default is set to 5 threads, which is a good choice for medium-scale implementations. If you have a robust hardware environment, you can increase this number. Conversely, you may decrease this value to fit your installation if performance is an issue.

Managing Single Sign-on

The single sign-on (SSO) service has been removed from Shared Services and is now a standalone component. It is now possible for developers to use any SSO provider they choose. To configure the SSO that is included with SharePoint Server, you must first enable the service. Figure 7-5 shows where to configure and start the service in the MMC Services snap-in.

Figure 7-5: You must define the logon account and set the service to automatic.

The specific Log On As: service account depends on the connection you make with the SSO service, but must be a member of the local administrators group on the encryption key server. If connecting to an Enterprise Resource Management system, check with the administrator of that service for an account recommendation. Keep in mind that this account also connects to your default SQL Server installation and must be a member of the SQL Server Security Administrators group and the DB Creator group. SSO allows connections to third-party systems and eliminates the need for the users to enter multiple passwords.

After configuring the SSO service, you must configure the settings for SSO in Central Administration > Operations > Security Configuration > Manage Single Sign-on. From there, you can manage the SSO administrator, which is usually the same account as the service account, and assign an administrator for managing enterprise application definitions. Enterprise application definitions are used in conjunction with the Business Data Catalog (BDC), part of a Shared Services Provider.

For more information on configuring the BDC, see http://msdn2.microsoft.com/en-us/library/ms583986.aspx.

Before you are finished, you must also create an SSO database by specifying a SQL Server and database name. Most implementations use the same database server as the SharePoint server farm, but yours may vary. After creating the database, you can remove the Database Creator permission from the SSO service account.

Configuring Blocked File Types

From Central Administration > Operations > Blocked File Types you can configure, on a per-Web application basis, the types of files that can be uploaded. The default list is too extensive to list here, but a few default blocked file types warrant mentioning:

• .cer These files are usually certificate files and can pose a minor threat if allowed to be served from your SharePoint installation. The downside to blocking .cer files is the inability to post root Certificate Authority certificates for users to install in their local browser.

• .com, .dll, and .exe These file name extensions should never be allowed on your SharePoint installation. Allowing .com or .exe files can cause catastrophic security consequences should a hacker find and execute code, such as a cross-domain (site) scripting attack, on your server.

• .pst It is unwise to allow users to upload .pst files to any site collection. Doing so can take significant amounts of storage. In addition, users cannot use a .pst over HTTP in Microsoft Outlook.

Tip 

Blocked file types can also be managed from the command line:

 stsadm -o blockedfilelist -extension <extension> - [add | delete] -url <web application URL> 

Note 

Users can change the extension of any file and circumvent your blocked file type configuration. To prevent uploads of file types based on the binary and not the file extension, consider a Content Policy software suite, such as Microsoft ForeFront.

Updating the Farm Administrator's Group

By default, the local administrators are part of the farm administrators group. This is not required in the new versions, however, and you may remove them. You can also add Active Directory groups as farm administrators, which eases administration. One downside to using Active Directory groups is that domain administrators can easily escalate their privileges by adding themselves to the farm administrator's Active Directory group. To update the farm administrator's group, browse to Central Administration > Security Configuration > Update Farm Administrator's Group and select New > Add Users.