With SharePoint 2010 we now have the ability to allow SharePoint to manage various service accounts thus foregoing the need to have IT administrators manually manage password changes. This new feature is a great benefit to SharePoint administrators and security conscious admins in general as it allows us to easily enforce our corporate security policies by changing these passwords on a schedule, and the administrators don’t even know what the password is so the likelihood of a compromise due to a disgruntled admin, though not eliminated, is somewhat reduced.

But the introduction of this new feature isn’t all good. The complication comes from the fact that SharePoint 2010 doesn’t implement this capability consistently. So an account that is configured as a Managed Service Account and set to have its password changed automatically could also be used in certain places that don’t understand the managed account concept. When the managed account password is changed the feature that uses that account and only knows the username and password (so it does not use the managed account details) will effectively be broken. As an example, if you configure the Enterprise Search Service to use a managed account whose password is scheduled to be changed every 30 days and you use that same account for the content crawl account then when that password is changed the content crawl will cease to function as it will be unable to authenticate the account. It’s important to note, however, that this issue only comes to light when you configure the managed account to have it’s password changed automatically.

So what things can be managed accounts and what cannot? The following lists what I’ve come across so far (if I’ve missed anything please leave a comment so I can update these lists):

Managed Service Accounts:

All Service Application Pool Accounts

Access Service Application

BCS Service Application

Excel Services Service Application

Metadata Service Application

PerformancePoint Service Application

Enterprise Search Service Application

Secure Store Service Application

Subscription Settings Service Application

User Profile Service Application

Visio Services Service Application

Web Analytics Service Application

Word Automation Service Application

Word Viewing Service Application

PowerPoint Viewing Service Application

Security Token Service Application

All Content Web Application Pools

Service Instances

Claims to Windows Token Service

Document Conversion Launcher Service

Document Conversion Load Balancer Service

Microsoft SharePoint Foundation Sandboxed Code Service

SharePoint Foundation Help Search

SharePoint Server Search (Enterprise Search)

Web Analytics Data Processing Service

Service Accounts (should not be managed):

Search Crawl Accounts

For Foundation Search and Server (Enterprise) Search

Unattended User Accounts

Excel Services Service Application

Visio Services Service Application

PerformancePoint Service Application

(in general, any Secure Store application credentials)

Object Cache Portal Accounts

Super User Account

Super Reader Account

User Profile

Synchronization Service Account (listed incorrectly on the FarmCredentialManagement.aspx page)

Synchronization Connection Account

Server Search Custom Crawl Rule Accounts

Any crawl rule that specifies an account other than the default crawl account

Again, these are just the accounts that I’ve personally bumped up against so it may not be a complete listing.

Viewing and Creating Managed Accounts

To see the current list of Managed Service Accounts using Central Admin go to Security –> Configure managed accounts:

You can edit the settings for any managed account by simply clicking the edit icon associated with the account you wish to modify. Once on the Manage Account screen you can configure the automatic password change settings:

To perform the same tasks using Windows PowerShell we can use the Get-SPManagedAccount cmdlet to retrieve the list of managed accounts:

Or we can retrieve a specific account using the -Identity parameter or by passing in a Web Application or Service:

clTo change the settings for a Managed Account we can use the Set-SPManagedAccount cmdlet:

To create a new Managed Account we use the New-SPManagedAccount cmdlet. In the example below I’m manually creating a PSCredential object so that I can specify my password (pa$$w0rd) in script (very useful for building out dev or test environments – otherwise you should use Get-Credential to prompt for the password so that it is not hard coded anywhere):

Applying Managed Accounts

Once you have your Managed Accounts created you can begin to use them for things such as Service Instances and Service and Content Application Pools. To associate a managed account with a specific Service Instance using Central Admin you can go to Security –> Configure service accounts. On the Service Accounts page you can set the account used for the Farm Account, Service Instances, Web Content Application Pools, and Service Application Pools. The Service Instances are highlighted in the following image:

Service Instances

To set the account associated with a particular Service Instance using Windows PowerShell we simply get the ProcessIdentity property of the Service Instance and set its Username property. Once set we call Update() to update the Configuration Database and then Deploy() to push the change out to all Service Instances. To make this easier I put this code in a function that I can call by passing in the Service Instance and credentials to use:

Service Application Pools

To create a new Service Application pool we use the New-SPServiceApplicationPool cmdlet and pass in the name of the Application Pool to create and the Managed Account to assign as the Application Pool identity:

It’s extremely important to note that the application pool that you create using the New-ServiceApplicationPool cmdlet cannot be used for your content Web Applications. Unfortunately there is no out-of-the-box equivalent for creating Application Pools for Web Applications.

Web Application Pools

As previously noted there is no cmdlet for creating Application Pools for Web Applications. Instead what you need to do is first check if the Application Pool you need already exists by using the SPWebService’s ContentService static property. If it exists then pass in just the name of the Application Pool to the New-SPWebApplication cmdlet, otherwise pass in the name and the Managed Account to use as the Application Pool’s identity:

Applying Service Accounts

When it comes to applying non-managed accounts to the various features things get a little more complicated. Let’s start with the Crawl Accounts.

SharePoint Foundation Search Service

For SharePoint Foundation Search we can set the crawl account (or content access account) using Central Admin by navigating to the Services on Server page and clicking the SharePoint Foundation [Help] Search link which takes you to the settings page where we can set the crawl account:

To set the same information using Windows PowerShell we actually have to go old-school and use STSADM as there’s no PowerShell equivalent cmdlet. Here’s a snippet of PowerShell code that I use to accomplish this:

Note that I’m using a helper function to convert the secure password to a static string which I can then pass to the STSADM spsearch command.

SharePoint Server Search Service

To manage the crawl account for the SharePoint Server Search Service (also known as the Enterprise Search Service) using Central Admin we simply need to navigate to the Search Administration page of the Service Application that we wish to modify and click the link for the Default content access account. This will bring up the following screen:

Note that by default this account will be set to be the same account you used for the Search Service Instance which is a Managed Account. If you do not change this account and you have configured SharePoint to manage the account password then your crawls will fail when the password changes. To make this change using Windows PowerShell we use the Set-SPEnterpriseSearchServiceApplication cmdlet:

Remember not to do this step until after you have provisioned the Administration Component.

Object Cache Accounts

Many administrators when they first configure SharePoint 2010 and hit a Web Application for the first time are likely to see a recurring event in the event log stating that the object cache has not been configured correctly. The specific error is as follows:

Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources.

This is essentially telling you that you have missed a manual configuration step in which you need to run some PowerShell to set two accounts for SharePoint to use to access the object cache:

Make sure that you do not use the same account for both the super user and super reader. (And of course make sure you change the URL and account names to match your environment). For more information about these settings see the following TechNet article: http://technet.microsoft.com/en-us/library/ff758656.aspx

Unattended Accounts

There are some services, specifically the Visio Services Service Application, the Excel Services Service Application, and the PerformancePoint Service Application, that allow us to set an account that we can use for access data sources behind the scenes. These are called unattended access accounts. To set these accounts we must create a new target application in the Secure Store Service Application and associate the target application’s ID with the appropriate Service Application. The following PowerShell code demonstrates how to do this for the Visio Services Service Application (the Excel Services Service Application is virtually identical and just uses cmdlets specific to Excel rather than Visio; PerformancePoint is a lot simpler):

When it comes to PerformancePoint we have a lot less work we need to do as the product team was nice enough to make it so that the Set-SPPerformancePointSecureDataValues does all the work of setting up the target application for us (note though that they did screw up how the Service Application is passed into the cmdlet requiring you to pass in the ID of the Service Application rather than the actual Service Application object):

User Profile Synchronization Service Identity

One thing to watch out for is when setting the account for the User Profile Synchronization Service. This service wants you to use the Farm Account as the identity. This means that your Farm Admin account cannot have it’s password managed by SharePoint if you intend to use this service (or at least, it shouldn’t be unless you don’t mind manually fixing this service every time your password changes – good luck with that BTW). Your Farm Admin account will always be a Managed Account (you can’t change that) so be extra careful when changing this accounts password (either manually or automatically). To set this account using Central Admin you can click Start next to the User Profile Synchronization Service entry on the Services on Server page.

To accomplish the same thing using PowerShell we need to get an instance of the Synchronization Service and set a few properties and call the SetSynchronizationMachine method passing in the username and password of the Farm Admin account (note that it requires the password be passed in as a standard string and not a secure string so I use my previously defined ConvertTo-UnsecureString function):

Summary

As you can see setting the accounts that are used throughout SharePoint 2010 is anything but consistent and in some cases a real pain in the a$$. I know I didn’t cover how to set every account (custom crawl rule accounts, user profile sync connection accounts, others?) but hopefully someone out there has already documented these, or if not perhaps they’d be nice enough to post a comment here for others benefit from (maybe one day I’ll add them myself but for now I think this post is quite long enough). As always, please let me know if I’ve missed something or otherwise got something wrong as I certainly don’t claim to have all the answers.

Side Note: To make things potentially even more confusing, Windows Server 2008 R2 Active Directory Services includes a new container with the same name (Managed Service Accounts) and functionality (automatic password change) though the actual implementation is a bit different.

This “Managed Service Accounts” AD container should definately NOT be used for service accounts you intend to use with SharePoint; accounts in this container can only be used on a single machine and SharePoint will not be notified that the password has been changed…

Great Post!, Maybe you can help me with this problem:Today a customer told me that he changed the password of an account that was used to install and configure all the SharePoint 2010. IT is an small farm of a database and one front end server. I try to run script to update the current password but PowerShell told me that the I could not access the farm, and is true beacuse the password to access database change but how I can update it?.

Desarrollo – you need to be logged in with an account that is a local admin on all the sp servers and has dbcreator and securityadmin on the sql box and also has db_owner rights to all databases. Then run the Set-SPManagedAccount cmdlet to reset the password of your farm admin account to the value set by your administrator (or just have your administrator change your password back). Note that you’ll also have issues with the user profile sync service and any other of non-managed services that I mention in this post if that account was used for any of them so you’ll need to address each of those

Three Service Instances are by default set up to run under the Local System or Local Service accounts: Claims to Windows Token Service, Document Conversions Launcher Service, and Document Conversions Load Balancer Service. In order to set the UserName to a Specific Managed Account, the “CurrentIdentityType” property of the ProcessIdentity must be set to “SpecificUser”. I modified Gary’s Set-ServiceIdentity function by adding a line above the username setter:

Hi,
Nicely detailed post.
2 Questions about the superuser and superreader accounts:
are they just standard domain accounts or do we have to use the portal app pool account as super user and another account as super reader since they cannot be the same?
Should we use different accounts for different web applications or can we use the same two accounts (in this case new account, no re-use of the portal app pool account) for all web applications of the farm. I suppose it all depends on the level of security we want to acheive !

You should not use the same account as your app pool as that account will have more rights than appropriate. Both accounts should be unique, but you can use them across web applications (I can’t think of any issues with doing that).

It’s very helpful post.
I need some more info.
What are the predeifned permissions for these managed accounts.
I mean to say what permission we have define for this managed accounts on SQl & AD.
Your reply would be much appriciated.
Thanks,
Hitesh

For most, nothing. Your setup account needs local admin on each sharepoint box and db_creator and security_admin on SQL but otherwise there’s no permissions to grant. That said, if you’re doing something like user profile sync then there will be extra permissions required; similarly if you are connecting to external datasources via Excel, Visio, BCS, etc. then you may need perms there.

I had a post that explained how to do this and was told to remove it by Microsoft. However, I now see that others have posted my *exact* same code as given to them by Microsoft (http://www.sharepointlonghorn.com/Lists/Posts/Post.aspx?ID=11) so perhaps I’ll put up a new post with this information as it appears to no longer be sensitive enough for them to continue threatening my MVP status over.

Well detailed blog. Thank you for that.
I have a client asking me how the password reset works in SharePoint. So basically they want to know what happens in the background? is it password set or reset? they were also wondering if the service which is managed by the managed account gets reset it every time there is a password reset.
Thanks

If sharepoint is managing the password then it is simply setting a new, random password on the given schedule. I believe that services dependent on managed accounts whos passwords just changed will be restarted but I’ve honestly never looked to validate that.

I used this powershell method to change the Sandbox Service account. I have the Sandbox service running on 2 servers in my test farm. I ran the script from server1 for both Server1 and Server2. But looking in the “services” list on server2, the service account on server2 did not change. I confirmed the “$svc.Service.ProcessIdentity” does contain the new service account for that service on server2. I also verified that the domain account I’m logged into on server1 has local admin on both servers.

Any idea what happened? What can I do to change the account for the sandbox service on server2 now that it’s not reflecting what is in the ConfigDB?

Hi,
First this post is awesome! I wonder why I didn’t find it before, it would have save me a lot of work!
But I got 1 problem with the function Set-ServiceIdentity. When I do the $pi.Deploy() I get this error: Exception calling “Deploy” with “0″ argument(s): “Object reference not set to an instance of an object.”
After double checking everything, I still can’t find any reason why it’s not working… The identity in SharePoint is changed when I look in Central Admin / Services Accounts which means the $pi.Update() worked fine. I just can’t get the Deploy() to work… My managed account is working fine, would I need to give it specific permissions?
Thanks

Hi Everyone,
We are having a problem with SharePoint. We cannot publish an access database to SharePoint server 2010 as we get this error “An error occurred while initializing access services database.” whenever we try to publish the default contact database. By the way, we are using the single server environment (standalone). If you need more details just let me know. Any help would be appreciated guys, thanks.

Hi Gary,
Thanks for your response. We are just publishing the default web contacts database template on Access 2010 and I am sure that this one is supported since I saw some videos and tutorials using this as an example for publishing Access db to SharePoint. Do you have an idea what causes this? Are we missing some configurations with the server to make these things work properly? Please advise, thank you.

By the way, we checked our ULS logs as you said and we got a lot of things here that I can vaguely understand. Here are some events under access services category and under the Data Layer EventIDLevel.

Regarding changing the service account for a Service Instance. How do you change the service account using PowerShell for a service that does not have a direct mapping to a SharePoint Service Instance? For example, the 2 services “Microsoft Project Server Events Service 2010″ and “Microsoft Project Server Queue Service 2010″. These services are listed in the “SPCA–>Security–>Configure Service Accounts” and obviously I can change the account on that screen, but I would like to use powershell.

So….what do I do when I accidentally enter a new managed account and then realize that some of my other services are failing because the person before put all the services in the same app pool :/
It seems that the only option I have is to Create a completely new app pool in order to select a managed account. Is this the only option? Why is there not a way to select **use current application pool and then select a managed account that is already set up ?
is there powershell that will allow me to change the application service account for the Managed Metadata Service?

Object reference not set to an instance of an object.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.

Thank you for this article. I suspect I am going to need to read it many times to understand it all.
Right now, I have what I hope is a simple question. When setting up the crawl, I had to create a managed account. I created it and did not configure it to automatically change passwords.
The service was created during the configuration process, and the managed account was added to the service – along with a password. As far as I know, that password was generated at the time the managed account was created. I do not recall providing a password when the account was created – am I mis-remembering this?
The reason this is important is that the actual search service will not start – it says that the password is wrong. I didn’t think that I had set it. However, if I am mistaken, then I need to somehow change the password both at the managed accounts page and in the service.
I just wanted to be clear about where the password came from in the beginning before I tried to change things.

Need to reset service account passwords on SPDEFACT, SPSERVICES, and SPFARM. Had no problem with spservices, and spdefact, when I tried spfarm I get this error message:

Error deploying administration application pool credentials. Another deployment may be active. An object of the type Microsoft.SharePoint.Administration.SPAdminAppPoolCredentialDeploymentJobDefinition named “job-admin-apppool-change” already exists under the parent Microsoft.SharePoint.Administration.SPTimerService named “SPTimerV4″. Rename your object or delete the existing object.

Someone suggested that I try this:
When the managed accounts tab section is used to change the password it creates a timer job “job-admin-apppool-change” and if this is half way or has been corrupted (like it’s been half way through and system reboot occurred) then the job “Sticks” and this can manifest itself as the error above.

The best and quickest way of rectifying this I have found is to delete the job and try again.

Use the following PowerShell to delete the job:

$tj = Get-SPTimerJob -Identity “job-admin-apppool-change”

$TJ.Delete()

However, it did not like the ‘Get’ command never got a chance to enter the rest.