Planning Security

This section is not meant to be exhaustive because system security is very dynamic. It is provided as an overview to securing SharePoint Server 2007. Security can always be improved, but too much security can affect the usefulness of the product. This section assumes you have already secured your Windows servers and are installing updates regularly.

More Info 

For more information on securing Microsoft products, visit http://www.microsoft.com/security/default.mspx.

Planning and Implementing Security Accounts

SharePoint Server 2007 was designed with security in mind by isolating the three tiers of administration: Central Administration, Shared Services Provider Administration, and Site Administration. This process isolation requires several security accounts to authenticate and connect services such as SQL databases, Web content, and Shared Services. Proper creation and permission settings are critical in protecting your SharePoint Server 2007 server farm from intentional or accidental intrusions. Provide these accounts with least privilege, and escalate those privileges only when necessary.

Note 

After creating Shared Services Providers (and My Site if a separate Web application), you must add the administrators manually in Central Administration, under Application Management. This prevents accidental unauthorized access.

The following list details the security accounts used by SharePoint Server 2007:

• Microsoft Office SharePoint Server 2007 Setup User Account This account must be an administrator on all servers in the farm.

• Server Farm Account The farm account is used by the Central Administration Web application and SPTimer service. (SPTimer is responsible for sending notifications and scheduling tasks.) This account must be an administrator on all servers in the farm and have Database Creator and Security Admin rights on the SQL Server server.

• SharePoint Admin Account The admin account is defined as 'localsystem' on all servers and is used to propagate changes and administrative tasks across servers in a farm.

• Shared Services Provider Process Account The Shared Services Provider (SSP) process account is used by the SSP Web administration application. It has full access to the SSP configuration database and must be secured. It cannot be Network Service (default) in a farm configuration.

• Shared Services Provider Web Content Account The SSP Web content account provides the access to consumers of Shared Services. It requires the Network_Service logon type.

• Web Application Process Account (Sites) The Web application process account provides for isolated IIS application pools and content database access. A best practice is to have a Web application process account for each Web application created, providing application isolation.

• Search Content Access Accounts You must define a default content access account when enabling an indexing service. This should be an account with broad access and the password should not expire. You may also need to define content access accounts when crawling any data the default content access account cannot successfully authenticate and is authorized to view. You may define as many additional search content access accounts as required, but only one may be defined per crawl rule.

• User Profile and Properties Access Account If you need to import users from a 3^rd party LDAP or another Active Directory Domain, you will need to specify the import connection account in SSP Administration when creating the data connection.

• Excel Calculation Services Unattended Process Account If you need to connect to external data sources with Excel Calculation services, you will need to define an additional account in SSP Administration. By default, the above defined SSP Process account will be used.

• Office Web Server Process Account This account runs under the Network Service user context and does not have to be changed.

SharePoint Server 2007 creates and connects to several SQL Server databases. Several of your existing security accounts will require permissions to access SQL Server databases. Table 3-2 details the permissions required.

Table 3-2: SQL Permissions
Open table as spreadsheet

Account Name	Configuration Database	Central Admin Content Database	SSP Configuration Database	SSP Content Databases	Web Content Databases
Farm Account (SQL Server Database Creator and Security Admin)	DBO	DBO	DBO	DBO	DBO
SSP Process Account	R	R/W	R/W	DBO	R/W
SSP Web Content	R	R/W	R/W	R/W	R/W
Web App Account	R	R/W	R/W	R/W	DBO
					*
DBO=Database Owner
R=Read
W=Write
* R/W for all other Web Application Content Databases

Securing Internet Information Services

Securing Internet Information Service (IIS) is critical to meeting your organizational goals of data integrity and availability. SharePoint Server 2007 allows you to assign an IP address to all IIS Web applications, except Office Server Web Services. Assigning each Web application an IP address mitigates the risk of an intruder accessing your administrative interfaces via a public IP address. For example, if you don't assign IP addresses to Web applications and leave TCP ports open to a public Web site on the same box as Central Administration, that Web site's IP address can be used to access Central Administration remotely. Using a single IP address for multiple Web Applications introduces complexities when isolating web traffic on firewalls and intrusion detection systems.

More Info 

Visit http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ for more information about security and IIS 6.0.

Several authentication mechanisms are available to you as a SharePoint administrator. How you choose from among these mechanisms will vary depending on your network topology and business requirements.

Anonymous Authentication

Anonymous authentication allows unprompted access to your SharePoint Server 2007 content. This authentication type uses the IUSR_computername system account to allow access to NTFS files and SharePoint Server 2007 content. Public Internet sites often use anonymous authentication, but using it for collaborative sites is a bad idea. Routine audits for IUSR_computername file access and vulnerability scans are considered best practices by the majority of the security community when using anonymous authentication.

Security Alert 

Don't allow unauthenticated public access to a fully enabled collaborative SharePoint Server 2007 farm. Your farm could be vulnerable to hackers, and any information published could be compromised.

Integrated Authentication

Integrated authentication allows users access to sites with their currently logged-on username and password. This is the preferred method for authentication because it reduces the frequency of username/password errors that require Helpdesk assistance. Integrated authentication can use Kerberos or NTLM authentication mechanisms.

Kerberos is the preferred authentication type for internal-facing SharePoint Server 2007 implementations, and it can be used in conjunction with integrated authentication. Keep in mind that the client and IIS server must be able to see the Kerberos Distribution Center (KDC) to successfully authenticate. Kerberos and NTLM are secure, but NTLM passwords sent over HTTP are considered insecure unless the password length is more than 14 characters.

Enabling Kerberos Authentication

Kerberos authentication requires special configuration. When creating a Web application in Central Administration, choose Kerberos as your authentication mechanism and configure a service principal name (SPN) for your Web application pool process account identity.

Configuring an SPN

Using the Setspn.exe tool from the Windows Server 2003 Support Tools, type the following at a command prompt:

 setspn.exe -A HTTP/ServerName CONTOSO\UserName 

ServerName is your IIS system name; CONTOSO is the name of your Active Directory domain; and UserName is the identity of the Web application's application pool.

Configuring an Existing Web Application

If you need to enable Kerberos after the initial creation of a Web application, you must configure an SPN and enable Kerberos for your Web application. First, verify your current NTAuthentication Providers. At the command prompt, type the following:

 cscript c:\inetpub\adminscripts\adsutil.vbs get w3svc/7898/root/ NTAuthenticationProviders. 

The output should look like this:

 NTAuthenticationProviders : (String) "NTLM" 

If the output is "Negotiate,NTLM", your IIS Web application is already configured to use Kerberos. Note that 7898 is our sample IIS virtual server ID (Web Application). The default Web site is 1, and you can find the ID for your Web application by opening the Web Sites folder in IIS Manager and looking in the Identifier column.

To enable Kerberos for this Web application, type the following at a command prompt:

 cscript c:\inetpub\adminscripts\adsutil.vbs set w3svc/7898/root/ NTAuthenticationProviders "Negotiate,NTLM" 

This will allow IIS to authenticate users with Kerberos or NTLM authentication. Do not remove NTLM or Kerberos-only users that cannot see the KDC or have unsynchronized clocks will not authenticate.

Basic Authentication

Many organizations will deploy SharePoint Server 2007 in a large, enterprise environment that is facing the Internet and is well protected by firewalls. In addition, highly compartmentalized organizations might not allow the required ports to enable Kerberos or NTLM authentication over routers. These scenarios require basic authentication to be enabled. The primary flaw with basic authentication is that the username and password are sent in clear text. Because of this, authentication traffic is easily compromised. Implementing SSL is considered a best practice for all public-facing SharePoint Server 2007 implementations, but it's mandatory when using basic authentication.

.NET Forms-Based Authentication

.NET Forms-based authentication provides a method for authenticating users at the application level instead of the at the operating-system level. This arrangement saves processing power and allows extreme scalability.

Important 

Forms-based authentication is sent in clear-text, secure using SSL.

Pluggable Authentication

SharePoint Server 2007 supports the ASP.NET provider model, allowing authentication to any database using pluggable authentication. By using a standalone database, you can keep extranet accounts out of your internal Active Directory.

Understanding Critical Services Placement

Most system administrators today are using screened or dual-screened subnets in securing Internet-facing services. The following topics assume you have a screened subnet using firewalls or routers. If you do not have these in place and are considering an Internet-facing solution, you should consider implementing them.

Securing the Central Administration Interface

The SharePoint Technologies Central Administration interface is a very powerful tool. Securing the location of this interface is very important to the foundation of SharePoint Server 2007 security. Ideally, this interface is on a secured network, not facing the Internet and using SSL for administrative communications. If an intruder gains access to your Central Administration home page, it only takes a username and password to render your security efforts null and void. Protect your Central Administration home page with SSL and never publish the administration TCP port.

Note 

If you have several SharePoint Server 2007 server farms, you will find it beneficial to assign all your farms the same Central Administration TCP port number. Never publicly publish this port.

Securing SQL Server

A significant area of concern when securing your SharePoint Server 2007 server farm is SQL Server. A secure SQL Server server is paramount to system integrity and availability because the majority of your data is there. Use the least permissions required when securing all traffic to the database server, including that which is not related to SharePoint Server 2007. Securing your SharePoint Server 2007 traffic is of little use when another application is the root of a SQL Server server being compromised.

Best Practices 

We have all heard about and felt the pain from TCP 1433 vulnerabilities such as the "slammer worm." Within the computer industry, it is now considered best to block public traffic to your SQL Server server. This is accomplished by blocking TCP 1433 on firewalls and routers while using IPSec to encrypt data going to and from your Web front-end servers, as shown in Figure 3-5.

Figure 3-5: Securing SQL Server via IPSec

Securing Extranets and Internet-Facing Collaborative Solutions

Always use SSL to encrypt Internet-facing or extranet-facing SharePoint Server 2007 solutions. Allowing collaborative access to your SharePoint Server 2007 servers from the Internet can be very beneficial in keeping your data centralized and indexed, but using standard HTTP is an invitation to intrusion. Have a perimeter Active Directory with limited visibility into your organizational network for extranet accounts and service accounts. Establish a one-way trust, with your perimeter Active Directory trusting your internal Active Directory. This configuration allows your organization's users to access the extranet remotely with one username, and it provides for smooth content deployment.

Security Alert 

Never configure your internal Active Directory to trust your perimeter Active Directory.

Extending Existing Web Applications

SharePoint Server 2007 includes the ability to republish content databases with different Web applications using special security controls. Many organizations use Kerberos authentication internally while publishing the same Internet-facing Web application using basic authentication encrypted via SSL. An example of this is shown in Figure 3-6.

Figure 3-6: Extending an existing Web application