转子：http://www.shareesblog.com/?p=247

 

SharePoint uses service accounts to run specific services behind the scenes. SharePoint does not function under the practice of “running everything as administrator”. There are several documents regarding all of the different service accounts that are recommended for SharePoint, but for some organizations the sheer number of accounts is simply not manageable. So I’ve put together a list of what I would consider the minimum accounts (and rights) for a typical SharePoint installation. The account you use to run setup on any server where MOSS needs to be installed must belong to the local administrators group. In addition, this account must be a Domain User and be a member of the following SQL server security roles: Logins, Securityadmin & Dbcreator. This account is responsible for creating new databases and creating new IIS sites so it is important to make sure the right permissions are set.

Typically, an account such as the domain administrator is used to run the installation; however it is strongly recommended that you use a dedicated account to log in and install Windows SharePoint Services and Office SharePoint 2007 servers. This account can also be used as the identity of the Central Administration site application pool, or it can be unique. You should always use the service account that you create to run all the WSS 3.0 services instead of a regular user account.

To deploy Office SharePoint Server 2007 in a server farm environment, you will need one or more security accounts that will be used in the following context:

  • A user account that you can use to install Office SharePoint Server 2007 and run the SharePoint Products and Technologies Configuration Wizard. This account must be:
    • A domain user account.
    • A member of the Administrators group on each of your Web and application servers.
    • A member of the SQL Server Logins.
    • A member of the SQL Server Database Creator server role.
    • A member of the SQL Server Security Administrators server role.
  • A domain user account that you can specify as the Office SharePoint Server 2007 service account.
  • A domain user account under which the Office SharePoint Server Search service can run.
  • A domain user account that is used to crawl content on your sites and create indexes.
  • A domain user account that acts as the application pool identity for your site collection’s Web application.
  • A domain user account that acts as the application pool identity for the Shared Services Provider application pool.
  • A domain user account under which the Shared Service Provider runs.

Listed below are a few of the most common accounts you will need for your installation. A complete list of accounts can be found on the Microsoft TechNet site. There is also a great blog on SharePoint Services and App Pool Account Permissions. Finally, you may want to check out this TechNet Web Cast on SharePoint Security: From Service Accounts to Item-Level Access.

Account/Group

 Purpose Group Rights Domain Rights SQL Access
Central Admin Application Pool Account (SPCAAppPool) Run the CA Site Application Pool (in IIS) Domain UsersMember of IIS_WPG, WSS_SPG and WSSAdmin_WPG Impersonate a client after authentication. Log on as a service SQL Rights: Public DB Rights: WSS_Content_Application_Pools
Application Pool Account (SPAppPool) Runs Site Application Pool(s) (in IIS) Domain UsersMember of IIS_WPG, WSS_WPG, and WSSAdmin_WPG Impersonate a client after authentication. Log on as a service SQL Rights: Public DB Rights: WSS_Content_Application_Pools
Administrator Account (SPAdmin) Master Administrator Account (suggested) Domain UsersMember of IIS_WPG, WSS_WPG, and WSSAdmin_WPGDomain Admins (suggested) Remote Desktop Users (suggested)VSDevelopers (for Development Systems only) Impersonate a client after authentication SQL Rights: Public, DBCreator  DB Rights: db_datareaderdb_datawriterdb_ddladmin
Install Account(SPInstall or SPConfig) Temporary account used for installing SharePoint Domain UsersDomain Admins (suggested)Local Administrator on each front-end serverRemote Desktop Users (suggested)  Log on locally. Impersonate a client after authentication. Log on as a service SQL Rights:DBCreatorSysadmin (suggested) DB Rights:Dbo
Services Account (SPServices) Used to run the SQL and SharePoint Services (not search) Domain UsersDomain Admins (suggested) Local Administrator on each front-end serverMember of IIS_WPG, WSS_WPG, and WSSAdmin_WPG Log on locally.Impersonate a client after authentication. Log on as a service SQL Rights:Public DB Rights:db_datareaderdb_datawriterdb_ddladmin
Search Service Account (SPSearch) Runs the SharePoint Search Service Domain UsersLocal Administrator on each front-end serverMember of IIS_WPG, WSS_WPG, and WSSAdmin_WPG Impersonate a client after authentication. Log on as a service SQL Rights:Public DB Rights:db_datareaderdb_datawriterdb_ddladmin
Content Account (SPContent) Used when crawling content for indexing Domain Users Must be granted access to any content source to be crawled SQL Rights:Public DB Rights:db_datareaderdb_datawriterdb_ddladmin

By default, the Welcome menu displays “system account” if that account is used to log on to any application pool or Web site. This behavior continues even if the application pool identity is changed to the Network Service. This means your administrator account should not be used as an application pool identity or to install a Office SharePoint 2007 server.

 

It has been my experience to use the install account as a temporary account simply to install SharePoint. It is never used again, so I haven’t had any issues making it an interactive login account because I removed the account once SharePoint is installed.