WSS Search Accounts
WSS Search accounts are granted high-level rights on the server and in SharePoint because they require access to all of the available content for search indexing, regardless of applied permissions. The WSS search account is used to control the WSS Search service and to access content in SharePoint sites. This account must be a domain user account that’s not a member of the Farm Administrators group. Database permission, including read access to the configuration database and the SharePoint_Admin content database and membership in the db_owner role for the SharePoint Services search database are all granted automatically. As with the Office SharePoint Server Search service account, there’s only one WSS search account in a farm.
The WSS Search Content Access account is used to crawl content across the various SharePoint sites, which might require distinct credentials. Typically, these accounts are used when crawl rules specifying login credentials are created. The requirements for this account are the same as the requirements for the WSS Search service account above. This service account is automatically added to the web application’s full-read policy for the farm if MOSS isn’t installed. If MOSS is installed, the WSS Search service account is used to index Help content for searching inside of the Help popup, and the Content Access account isn’t used.
IIS Application Pool Accounts
IIS application pools are used to provide process isolation in IIS. Process isolation prevents an error in one application from affecting applications running in a different process. The IIS application pool service accounts are typically granted a reduced set of server privileges and are used as the actual database owner of the SharePoint content database for the appropriate sites. The primary use for this service account is to provide SharePoint with read and write access to the content databases associated with the web applications that reside in that particular application pool. Joel Oleson, formerly from Microsoft, recommended in his blog that a single SharePoint server not attempt to use more than four distinct application pools (with 10 being the maximum) to prevent potential performance problems. (This recommendation doesn’t include the Central Administration or SSP application pools because these applications are used infrequently.) Each SharePoint application pool uses an average of 800MB of RAM, severely limiting 32-bit systems. Following these recommendations, you’ll likely want to group your SharePoint web applications under a single application pool.
Configuring Security in SharePoint
Securing SharePoint begins with the definition and assignment of AD service accounts but doesn’t end there. SharePoint also has many different internal security layers, including the server or server farm level, the shared services level, and the site level. (For more information about SharePoint’s logical layers, see "Logical architecture components.") Administration actions can occur on any of these layers, so SharePoint provides a security infrastructure to help control access to these locations.
Security in SharePoint is handled by the assignment of rights and roles. Foremost among these rights are the administrative permissions, which provide control over SharePoint’s functionality. The individuals performing administrative actions at any of these levels might or might not be the same individual. Users and groups can be granted administrative permissions on the following layers in SharePoint.
Farm level. Members of the Administrators group on the local server have the ability to change any aspect of SharePoint, including the fundamental building blocks upon which SharePoint relies, SQL Server, and IIS. Despite this enormous level of power, server administrators aren’t automatically granted access to the content stored in SharePoint sites.
Farm Administrators are identified in Central Administration. These users have permission to perform any administrative task in Central Administration. Members of this group can also use the Stsadm command-line tool to perform tasks such as scheduled solution deployments and unattended SharePoint backups. Similar to members of the local server’s Administrators group, farm administrators don’t automatically have access to site content.
Shared services level. SSP administrators are defined within the SSP itself and can control which services are included in the SSP, such as Excel Services and User Profile Imports. (For more information, see "Shared Service Providers and Delegation.") Service administrators at the shared services level are able to configure settings for a specific service within an SSP. Frequently, users are granted service administration permissions so that they have the ability to tune SharePoint’s search functionality for the SSP by defining authoritative pages and search keywords.
Site level. Site collection administrators are defined in Central Administration for each site collection in every web application and are given Full Control of every site within that site collection. Site collection administrators don’t require additional permissions at the site level to have access to that site’s content as their level of control is granted centrally. Because site collection administrators might be defined in Central Administration, a farm administrator or local server administrator could add themselves to this group to access otherwise unavailable content and perform site level administration activities.
The Home Owners group is automatically created on every SharePoint site in the People and Groups area. Members of the Home Owners group are site owners and are granted Full Control on that site. Site owners can be distinct for every site in a site collection or can be inherited from the top-level site. These users have access to the site settings menu and can modify the settings of any list or library on the site. In addition, custom groups can be created and assigned Full Control permissions, which equal the default permissions of the Home Owners group. The main difference between the Home Owners group and custom groups with Full Control and site collection administrators is that subsites can opt to specify unique site permissions that exclude the parent site’s Home Owners group. Site collection administrators can exercise Full Control through every site in the collection.
SharePoint’s Policy for Web Applications Feature
Although it’s not truly an administrative level, SharePoint’s Policy for Web Application feature deserves a mention here. Defined in Central Administration’s Application Management tab, members of the Read policy group or Deny policy group can be granted read access to the entire farm or denied read access to the entire farm. These policy settings override site-level permissions. A scenario in which you might use these settings is to provide an auditor access to the entire site for a short period of time. You wouldn’t want to navigate to each location the auditor needed but rather grant the auditor access for the time they’ll be on site and then remove the auditor’s rights once they leave. Another reason to add a user to a policy group might be if someone leaves your company and you need to remove their access rights immediately. In that case, you can deny the user’s rights in the policy of the web application without going to each location to remove them. Doing so prevents the user from using the site while giving you time to correctly remove the user from the site.
A Secure SharePoint Environment
DBAs and IT pros are increasingly finding themselves associated with SharePoint projects. SharePoint is a complex system that requires some serious study to follow Microsoft’s best practices. There are twelve different types of service accounts available on the network, three distinct levels of security configuration in SharePoint itself, and a host of data connection capabilities for extensibility. Gaining an understanding of the various surfaces for security configuration is an important aspect of an effective SharePoint installation.