How to change service accounts and their passwords in MOSS and WSS 3.0

How to change the Application Pool Identity of a WSS or MOSS web application

  1. Open SharePoint Central Administration, click Operations.
  2. Under Security Configuration, click Service accounts.
  3. Click the radio button beside Web application pool. Select Windows SharePoint Services Web Application. Select the application pool where you want to change the identity, for example: Sharepoint - 80.
  4. Make a note of the existing settings in case you need to unwind your changes.
  5. Select the Configurable radio button. Provide the user name and password. It helps to be explicit here and use the domain\account format (e.g. mydomain\SPService). Also be sure to use a strong password. Click OK.
  6. To restart the application pool, either open IIS and recycle the application pool, or open a command prompt and type iisreset -noforce.
  7. Open your SharePoint site in a browser to confirm that the change was successful.  

This change will be automatically propagated to all web front-ends.

 

How to change the Application Pool Identity for SharePoint Central Administration (SCA)

Repeat these steps on each server which hosts the SharePoint Central Administration web application. If the web front-end (WFE) and application (APP) server roles are served by separate machines, SCA should be enabled on one APP server (or more) and stopped and/or removed from the WFE servers. This allows control over access to the SCA. The SCA service account should not be the same as that used for the SharePoint application pool so even if one is compromised, the other remains secure.

  1. Open a command prompt.  
  2. Run: stsadm -o updatefarmcredentials -userlogin domain\username -password password
  3. Be patient. This may take a few minutes to run.
  4. To restart the application pool, either open IIS and recycle the application pool, or open a command prompt and type iisreset -noforce
  5. Open SharePoint Central Administration in a browser to confirm that the change was successful.  

The above steps create an Administration Application Pool Credential Deployment timer job. You can see this in the Timer Job Definitions page. The job is complete when it no longer appears in the list of definitions (refresh the browser, this isn't automatic).

 

How to change the default content access account for MOSS search

The content access account is used to crawl and index SharePoint content for a given Shared Service Provider (SSP). It should be different from the application pool identity and configured so that only the most recent version of each document is indexed, otherwise old versions will appear in search results.

  1. Open SharePoint Central Administration (SCA), and on the left below Shared Services Administration click on the Shared Service Provider with the search configuration you want to change (e.g. SharedServices1).
  2. Under Search, click Search settings. Click Default content access account.
  3. Enter the credentials, confirm the password and click OK.

 

How to change the Search Service account for MOSS

Note that this is the identity used to run the Search Service, it is not the identity with which content is actually crawled and indexed. This account must be a local administrator (not a domain administrator) on both the query server and the index server in order for index propagation to work. This is set automatically for you when you click OK (below), but is the first thing to verify if you get a "Query server not responding" error (see Chris Gideon's post).

  1. Open SharePoint Central Administration, click Operations.
  2. Click Services on server, and then Office SharePoint Server Search.
  3. Configure the Farm Search Service Account. It is okay to use the same account as the SharePoint application pool identity.
  4. Scroll down and click OK.
  5. Wait while your changes are processed.

 

How to change the default content access account for WSS search 

Note that the Search Service account (which runs the WSS search application) is not the same as the Content Access account (which actually indexes the content). The Search Service account may be the same as the SharePoint application pool identity. The Content Access account should be different from the SharePoint application pool identity.

  1. Open SharePoint Central Administration, click Operations.
  2. Click Services on server, and then Windows SharePoint Services Help Search.
  3. Configure the Service Account.
  4. Configure the Content Access Account.
  5. Scroll down and click OK.
  6. Wait while your changes are processed.

or

  1. Open a command line.
  2. Run: stsadm.exe -o spsearch -farmserviceaccount domain\username -farmservicepassword password
    It is okay to use the same account for this service as the SharePoint Application Pool identity.
  3. Run: stsadm.exe -o spsearch -farmcontentaccessaccount domain\username -farmcontentaccesspassword password
    This account should be different from the SharePoint Application Pool identity.
  4. Repeat these steps for all servers in the farm.
 

Many of the above steps are also documented in the MSDN KB Article 934838: How to change the passwords for service accounts in SharePoint Server 2007 and in Windows SharePoint Services 3.0, which could just as well be titled "How to change passwords or accounts for service accounts. . . ." But note that the KB article doesn't explain why you would make changes in the first place, only the how-to.

KB 934838 also contains a nice batch file you can customize to make many changes at once. Of course, please, please, please don't do something incredibly silly with it like saving your passwords in cleartext.

 

Background

There are a variety of reasons to change the accounts used by SharePoint's many services. The "best practice" is to use the same account wherever you have the same permission or auditing requirements for two operations, and distinct accounts for each potential attack surface.

Example 1: Two SharePoint application pools might use the same identity, unless the breach of one should absolutely not affect the breach of another. For example, the compromise of a web front-end should not also allow the compromise of central administration (and vice versa), therefore these two applications should run in separate pools with separate identities.

Example 2: Content crawler accounts need only read SharePoint content, so assigning any more rights or allowing the crawler to run as an administrator or database owner (e.g. using the application pool identity) creates a prime attack surface. Don't do that.

On a standalone WSS or MOSS configuration, local accounts work just fine. This is typical for a developer environment. When you need to more fully replicate a production environment, it's a good idea to join such a machine to a domain and configure the farm accordingly with similar domain accounts and often Kerberos.

There are some useful rules of thumb to follow in configuring SharePoint accounts.

Rule #1: Don't change account pool identities directly in IIS (unless it's the only way).
I've taken some pains to describe what I think are the best ways to configure accounts. Commands aren't generally added to STSADM or SCA on a whim (though I'll concede the possibility). If there's a SharePoint way of doing something, it's usually best to do it SharePoint's way and not the alternative. A similar rule is "never touch the database."

Rule #2: Make the changes while logged in as a domain administrator.
The service accounts must be granted rights and be named in policies. If you use SharePoint's interfaces, SharePoint will update the appropriate rights and policies for you, but you must execute the changes while logged in as a user who is able to set these permissions and policies. This usually means being logged in as a domain administrator.

 That's it, have fun.

 

References

Joel Oleson: Password change via stsadm (2006-08-22)

MSDN KB 934838: How to change the passwords for service accounts in SharePoint Server 2007 and in Windows SharePoint Services 3.0


 

No Comments