Changing SharePoint 2010’s Service Account Passwords

http://www.toddklindt.com/blog/Lists/Posts/Post.aspx?ID=301

We’ve all seen it, it happens every day. A coworker gets mad, throws a burrito at the boss and the next thing you know they’re getting escorted out by security. If that person know your SharePoint service account passwords, and the burrito was big enough, your boss might want you to change them all to make sure the burrito-thrower doesn’t get into SharePoint and cause some problems. In this blog post I’ll walk through how to change all of the passwords in a SharePoint 2010 farm without it exploding in your face Wiley Coyote style.

When writing this blog post I’m basing it on the accounts I suggest in my SharePoint 2010 Service Accounts blog post. If you didn’t follow that guide, your experience might be a little bit different. My intention with this guide is to allow you to change your passwords with as little trouble and user downtime as absolutely possible. I recently walked through all of these steps on a customer’s farm and it went very smoothly and with no problems. Without my guiding hand though, your mileage may vary.  

It’s important to understand how SharePoint stores and changes passwords in case there’s trouble. The passwords themselves are stored, encrypted, in the Config DB. This is necessary so that you don’t have to enter every password when you join a new server to the farm. SharePoint 2003 was this way and it was maddening. In SharePoint 2010 (and SharePoint 2007 to a point) the passwords are stored in the Config DB, and the servers in the farm are updated via Timer Jobs.  When you change any passwords they’re changed in the Config DB and then a Timer Job is created that is run on all the servers in the farm. When you’re executing the steps below, I highly recommend you do them one at a time, and make sure one password is changed on every machine before moving on to the next password. You can keep track of the Timer Jobs in Central Admin > Monitoring > Check Job Status (/admin/Timer.aspx). If one of the Password Timer Jobs fails, do not pass Go, do not collect $200, and do not change the next password. Figure out why the job failed and fix it before moving on.

With that, here’s a list of the accounts, the order I changed them in, how I changed them, and how I verified it worked.

Content crawl account (sp_content)

How to change it

This account is used by the search service to access the content it crawls. Since it isn’t a managed account we have to deal with it manually. We know it’s not a managed account because we didn’t pick it from a list, and we had to enter its password when we set it up. If you don’t have access at the domain level to change other account’s passwords, you can still change this one, as long as it can change its own password. On any domain machine hit Ctrl-Alt-Delete and click “Change a password…” When the change password box comes up, put domain\sp_search (or any of the other accounts we’re changing) in the account box and change the password. This is a pretty low profile account and can safely be changed during the work day.

Once the password is changed in AD we can change it in SharePoint. Go to Central Admin > Application Management > Manage Service Applications (/_admin/ServiceApplications.aspx). Click your Search Service App. For each of your Search service applications there is a Default Content Crawl account. It’s listed on the front of the Search Admin page. Click it to change its password (or identity). Put the new password in. If you have any Crawl Rules that define another account, you’ll need to go through this process again. Also, if you have multiple search service apps, and they use different default crawl accounts you’ll need to repeat the process.

How to check it

This one is pretty easy to check. After AD and SharePoint have both been updated, just kick off a full crawl. If the passwords aren’t correct or don’t match the crawl will end very quickly and you’ll get lots of top level errors.

User Profile Sync Account (sp_userprofile)

This account is used by the User Profile Sync Service to read the Active Directory changelog, read user information and optionally write user information back to Active Directory. Like the sp_search account above this one is pretty safe to do during the day.

How to change it

You may also have to use the Ctrl-Alt-Delete trick above to change the password for this account in AD. After the password is changed go to your User Profile Service App (UPA) and go to the Configure Synchronization Connections page. Choose the domain connection that uses sp_userprofile and click Edit. Type the new password twice and click Populate Containers. If the password works, your OUs will show up along with the ones you’re syncing will be checked. Click OK to save the new password.

How to check it

Go back into the User Profile Sync service application and manually start a profile sync. A full or incremental will work. If you want to watch the sync as it happens, fire up "C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe" on the machine where the User Profile Sync Service Instance (UPS) is running. That’ll give you more information than Central Admin. If they sync runs, the password change is good.

Managed Accounts (sp_farm, sp_webapp, sp_serviceapps, sp_search)

This section should be how every account in SharePoint 2010 is handled. There should be no need for this blog post at all because of the magic of managed accounts. This functionality is new to SharePoint 2010 and the idea is that you enter a username and password in one place, then pick it from a list everywhere in SharePoint where you need it. There is also the option for SharePoint to manage the passwords. Since the username and password only exist in one place, it’s easy to update. They’re halfway there in this version. You’ll notice the sp_content and sp_userprofile accounts are not managed accounts, so we still have to change them manually. We’re getting closer though, there is hope.

How to change it

To change a managed account password go to Central Admin > Security > Configure Managed Accounts (/_admin/MangedAccounts.aspx). Click the Edit icon next to the account whose password you want to change.

This brings up the next screen.

There are three options for changing the password. The first, “Generate New Password,” tells SharePoint to go ahead and make up a password, set it in AD and change SharePoint’s stored copy of the password to match it. I was curious how strong these passwords are. Using a script I had (link removed due to a request from the script’s author) I decrypted the password SharePoint generated. I was pleasantly surprised.

The password SharePoint generated is 35 characters long, with mixed case letters, numbers, symbols and I can’t be sure, but I think a couple of clicking sounds. As this script shows, should you ever need to discover that password, it’s possible. Be careful using this option with the sp_farm account. If you don’t have the script I have (and I can’t give it to you, sorry  ) you won’t be able to discover the sp_farm account’s password and you’ll need to know it for the next section.

Your second option, “Set account to new value,” is like the first option, except you need to come up with the password on your own. SharePoint will change the password in AD and in SharePoint. It should be noted that for option #1 or #2 to work, the service account must have permission to change its own password, which is the Active Directory default.

The third option, “Use existing password” is what you’d use if the password has already been changed in AD and you just need to update SharePoint.

On a side note, at the bottom of this page is a list of all the components in the farm that are using this account as a managed account. This gives you a quick list of things to check after you’ve change the password.

Change these service accounts one at a time. After you’ve changed one account monitor the Timer Job and make sure it succeeds on every member of the farm. Then check its functionality to make sure everything work. Once that’s done, move on to the next managed account.

How to check it

Check the services that use each managed account to see if the password change made its way through. If you want to be super positive, reboot all your boxes. The ensures all the processes are restarted and forced to log back in with the new password.

 

User Profile Sync Service account (sp_farm)

The farm account (sp_farm) is a managed account, and we changed its password in the previous step. However, the Farm account is used by the User Profile Sync Service (UPS), but not as a managed account. Because we had to manually enter the password when we started the UPS we’ll have to enter the new one there too.

How to change it

Go to Central Admin > System Settings > Manage Services on Server (/_admin/Server.aspx). This page lets you start and stop service instances on each machine in your farm. From the “Server” dropdown choose the server that the UPS is running on. Hopefully its state is “started.” Click “Stop” and let the UPS stop. After it has stopped, click start to start it back up. Hopefully you’re at the June 2011 CU (14.0.6106) or later. The UPS could be a bit of a bugger to get started in earlier builds. Use Spence’s guide to brush up on getting it started. The UPS must run as the Farm account, and you must supply that account when you start it back up. If you chose the “Generate a password” option in the previous step for the Farm account you might be in a bit of a pickle, since you don’t know what the password is. If you have access to the script I referenced above (still can’t give it to you, still sorry about that) you will be able to discover it. If not, you’ll need to change it to something you do know. After you’ve put the new Farm account password in let the UPS start. If everything goes well this will take a few minutes. You can use the MSDN ULS Log Viewer to watch the service instance start and watch for errors.

How to check it

The first check is to make sure the User Profile Sync Service does indeed start. If it does, that’s a good sign. If it does not, it might not necessarily be a password issue. Reference Spence’s post above for troubleshooting steps. After the UPS is started, do a profile sync to be absolutely sure the password change is working.

Install Account (sp_install)

This is the account that’s used to install SharePoint. This is an easy one, as SharePoint (2010, at least) doesn’t store its password anywhere.

How to change it

Log in as sp_install, hit Ctrl-Alt-Delete and Change Password. Type in your new password. Twice. Correctly.

How to check it

Log out, log back in as sp_install. 

Farm Passphrase

Not really an account, but I thought I’d include it just the same. This passphrase is created when the farm is created, and is needed when a SharePoint server is added to a farm.

How to change it

Since this isn’t an account, you don’t need to do anything in Active Directory. To change the farm passphrase, use the PowerShell cmdlet Set-SPPassphrase. Since PowerShell hates it when you enter passwords in plain text there a couple of hoops you have to jump through. Type “help set-sppassphrase –examples” to see how to use it.

How to check it

I don’t know of any way to check this other than adding a new machine to the farm.

Secure Store Password

Like the farm passphrase, this isn’t a user account, but it’s a password that’s used to encrypt settings

How to change it

Go to Central Admin > Application Management > Manage Service Applications (/_admin/ServiceApplications.aspx). Click your Secure Store Service App. Click “Generate New Key” in the ribbon.

Type the new password in twice and click ok. SharePoint will reencrypt the contents of the Secure Store database.

How to check it

I haven’t tested this one, but I assume if the password is not correct, the service application won’t display the targets. That’s how it acts when you attach a Secure Store database but haven’t put in the password yet.

Bonus! SQL Server Reporting Services

This isn’t a SharePoint account, but I like you guys, so I thought I’d include it anyway. The customer I was doing this with (no burritos were involved, I made all that up) also had SSRS running. In a weird twist, SSRS was NOT running in SharePoint integrated mode.

How to change it

The directions for changing the SSRS password were pretty simple. Simply rerun the SSRS config tool and put in the new password. I followed the instructions in this MSDN article.

How to check it

Hit the SSRS Reports URL. If it comes up, the password change worked.

Those of you that attempted to change passwords in SharePoint 2007 can appreciate how simple and straightforward this process is in SharePoint 2010. There’s still room for improvement, but it’s pretty solid. The process I used above worked the very first time for every account involved, and resulted in very little end user downtime. While changing all the service account passwords is a big deal, using these steps can make it a low impact, and low stress event.

tk