Every service which runs on a Windows server requires an account. While there are built-in accounts designed to facilitate these services ("Local Service" and "Network Service"), many times you will find it is better to use a domain user account when setting up services. This is especially true with Microsoft SharePoint products and technologies.

Whether it is Windows SharePoint Services, Search Server, or Office SharePoint Server, there are a number of places where you can specify a distinct account. In theory, it is possible to use the built-in accounts under some circumstances; however, it is rarely advisable. In fact, if you are setting up multiple servers in a farm, you must use domain accounts. In that instance, is also possible to use the same domain account for all of these functions, and SharePoint will "work". Doing so, however, is asking for trouble down the road.

On the other side of the scale, you could define separate accounts for virtually every aspect of SharePoint. That could quickly become an administrative nightmare.

The Big Three

While the exact set of accounts required will vary somewhat based on your individual company's requirements, for most installations you should count on setting up at least three accounts. These are for some roles that should always be kept separate:

• The Setup User account
• The Server Farm account
• The Default Content Access account (for versions of SharePoint that include Enterprise Search - MSS/X, MOSS)

Combining these roles could result in administrative confusion, and/or excess information disclosure.

The Setup User Account

The Setup User account is unique among these accounts in that it is not a service account. Let me say that again: the Setup User account is not a service account. This is the account you use to log into your server(s) when you set up SharePoint.

This account is very powerful. You could think if it as a SharePoint Administrator, but it is even more. During setup, it gains some implicit power over SharePoint that cannot be removed. Even before starting setup, you need to assign the following permissions to it:

• The Setup User must be a local administrator on each server in the SharePoint farm (SQL Servers not running SharePoint components not included)
• The Setup User needs to have the Dbcreator and Securityadmin roles in SQL Server

While the Setup User account needs to be a Local Administrator on the SharePoint servers, it does not need to be a Domain Administrator. If your SQL Server environment is separate from your SharePoint farm (which it should be in most production environments), this account does not need to be an administrator on your SQL Servers. Instead it only needs the roles mentioned above. Finally, even though it is a is used to log into the SharePoint servers for installation and administrative purposes, it should not be the "day to day" account of any user. (Note, this separation is good practice for any administrative account - not just SharePoint.)

You can assign additional users to administrative roles within SharePoint following installation The Setup User account will always have that level of control, however, even if removed from administrative user listings.

Even after setup is completed, a user account with comparable capability will need to be maintained in order to provide full administrative functionality. In particular, services need to be started and stopped, IIS web applications and application pools need to be created and removed, etc...

This is the only account that needs permissions pre-allocated (as described above).

The Server Farm Account

The Server Farm account is a true service account in that it is not used by a user to log in. As noted above, you do not need to do any manual configuration of this account beyond its creation. When you specify this account during setup, it will be assigned appropriate rights and permissions. In particular, this account is used for the Central Administration site's application pool, and is assigned to the SharePoint Timer service. If someone does log into SharePoint using this account, they will be identified in the top navigation bar as "System Account", rather than with the "real" name or ID of the user.

There are other disadvantages of logging in with that account. Certain functions are restricted. For example, in SharePoint Designer (if you can open the site at all), contributor settings limit the kinds of customization allowed unless the account is also designated as the Site Owner - not recommended.

The Default Content Access Account

On versions of SharePoint that include Enterprise Search functionality, such as Microsoft Search Server 2008 (including Express), and Microsoft Office SharePoint Server 2007, you will also need to designate a Default Content Access account. This is the account used by the Indexing service to crawl SharePoint, as well as any other content sources (unless otherwise specified). It is given read access to all content in the SharePoint farm. Like the Server Farm account, while it should be a domain account, it should not be used by any users to actually log in to SharePoint.

Other Possible Accounts

Once you get past the big three, there are many other places in SharePoint where you can designate service accounts. The Search Services (crawl and query) themselves, for example, need an account which should not be the the same as the default content access account. Application Pool accounts can also each be assigned their own accounts, and this may be appropriate in your environment. In many cases, however, you can simply reuse the Server Farm account for these processes. Be aware, though, that you should never assign the Setup User account to any services in a production environment.

Summary

In this article, I have explained some of the accounts you should consider when planning your SharePoint deployment. In a single-server test or demonstration environment, you might be able to get by with built-in accounts, or a single domain account. But in production, you should have separate accounts for the major roles. While you can go overboard and assign distinct accounts to every possible aspect of SharePoint, most of the time, the three described above will be sufficient.

For more information, you should see the Microsoft guidance for the particular product you are configuring:

Plan for administrative and service accounts (Office SharePoint Server)

Plan for administrative and service accounts (Windows SharePoint Services)

Plan for administrative and service accounts (Project Server)

Plan for administrative and service accounts (Search Server 2008 including Express)