Executive Summary:
Find out what you need to consider from a security standpoint before installing and administering Windows SharePoint Services (WSS) and Microsoft Office SharePoint Server (MOSS) 2007. This article explains what you need to know about SharePoint’s architecture and defining AD accounts, such as server farm–level, SSP, IIS, and WSS accounts. You’ll also learn how to configure security in SharePoint by assigning users rights and roles.
|
Microsoft’s SharePoint technologies are among the fastest growing products released by the company. As organizations around the world adopt SharePoint as the platform for intranet, extranet, and Internet sites, DBAs and IT pros are stepping in as SharePoint administrators for their organizations. This article is an introduction to the security considerations associated with the installation and administration of Windows SharePoint Services (WSS) and Microsoft Office SharePoint Server (MOSS) 2007.
Understanding SharePoint’s Architecture
SharePoint is an n-tier client-server application that allows for redundancy at each of its layers. Although not technically part of a SharePoint server farm, the first tier is the client-workstation tier, which represents the myriad types of machines that can be used to access SharePoint. (Note that SharePoint automatically enables mobile access to its content.) The second tier is where the web servers, known as web front ends, serve up SharePoint content in the form of web pages, documents, images, and RSS feeds. The third tier is the application tier, on which servers such as the SharePoint Search Index service and Excel Calculation Services (ECS) server are found. Finally, the back-end data is stored in SQL Server on the fourth tier. Note that this simplified model leaves out services, such as Active Directory (AD), network load balancers, firewalls, and monitoring solutions (e.g., System Center Operations Manager). Even this simplified model hints at the complexity of SharePoint and the need for a careful approach to security during the setup, administration, and connection to external systems. Controlling access to these external systems begins with the definition of service accounts.
Defining AD Service Accounts
When adding SharePoint to your environment, it’s important to identify and document the service accounts you’ll be using to install SharePoint, to connect SharePoint to the various applications and services it needs, and to provide SharePoint with access to external systems and repositories. Microsoft has identified four categories of SharePoint security accounts: server farm–level accounts, Shared Service Provider (SSP) accounts, WSS search accounts, and application pool accounts. (For more information, see "Plan for administrative and service accounts" and "planning spreadsheet.") Let’s look at how these AD service accounts should be defined.
Server Farm–Level Accounts
The server farm–level service accounts are used to set up SQL Server and SharePoint and to provide an identity to SharePoint’s administrative tools such as Central Administration and the WSS Timer service. These accounts are typically domain user accounts that belong to a variety of AD groups, including the local Administrators group. In SQL Server, these service accounts can operate with the least privilege administration rights by granting db_owner privileges inside of the various SharePoint databases and securityadmin and dbcreator fixed server roles. Although these seem to be powerful rights, they’re the least privileges required by SharePoint. SharePoint takes over the creation and ownership of its back-end databases on SQL Server.
The SQL Server service account is required during the installation of SQL Server and isn’t utilized by SharePoint. SQL Server will prompt for this Local System or domain user account. A domain account is preferred because only domain user accounts can make remote procedure calls, back up to network drives, participate in replication, use the SQL Mail features, or any other activity requiring network resource access controlled by Windows domain authentication. This service account is used to run some of the ten SQL Server services, including MSSQLServer, SQL Server Agent, and potentially MSSQLServerOLAPService, ReportServer, and SQLBrowser. This service account should be kept completely separate from SharePoint. The different SQL Server component services might run under different service accounts to provide more granular security. These service accounts are the basis for security in SQL Server. The rights assigned to these accounts and the context associated with each one defines which resources are available on your server. If your other layers of security are penetrated by a malicious program or attacker, the different limits on each service account help to limit the attack surface.
The SharePoint Setup user account is the account used by IT staff to log into the server and to run the setup application for the SharePoint installation process. It must be a domain user account and a member of the Administrators group on the local server(s). In addition, this account must be made a member of the securityadmin and dbcreator fixed server roles inside of SQL Server and must be granted db_owner privileges for any database that might be affected by SharePoint or the SharePoint command-line utilities. By default, these fixed server roles and database privileges are granted during the installation of the SharePoint software if you choose the simple (SQL Server Express) installation. However, when choosing the more complex server farm installation, the Setup user account must have the required access to the database before beginning the install. The Setup user account also runs the Stsadm and PSConfig command-line utilities. The Microsoft article "How to change service account and service account passwords in SharePoint Server 2007 and Windows SharePoint Services 3.0" outlines the procedure to change the passwords for MOSS 2007 service accounts using the Stsadm UpdateFarmCredentials command.