Difference between Service Accounts and Managed Service Accounts in SharePoint 2010

Difference between Service Accounts and Managed Service Accounts in SharePoint 2010

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:

o  All Service Application Pool Accounts

o      Access Service Application

o      BCS Service Application

o      Excel Services Service Application

o      Metadata Service Application

o      PerformancePoint Service Application

o      Enterprise Search Service Application

o      Secure Store Service Application

o      Subscription Settings Service Application

o      User Profile Service Application

o      Visio Services Service Application

o      Web Analytics Service Application

o      Word Automation Service Application

o      Word Viewing Service Application

o      PowerPoint Viewing Service Application

o      Security Token Service Application

o  All Content Web Application Pools

o  Service Instances

o      Claims to Windows Token Service

o      Document Conversion Launcher Service

o      Document Conversion Load Balancer Service

o      Microsoft SharePoint Foundation Sandboxed Code Service

o      SharePoint Foundation Help Search

o      SharePoint Server Search (Enterprise Search)

o      Web Analytics Data Processing Service

Service Accounts (should not be managed):

o  Search Crawl Accounts

o      For Foundation Search and Server (Enterprise) Search

o  Unattended User Accounts

o      Excel Services Service Application

o      Visio Services Service Application

o      PerformancePoint Service Application

o      (in general, any Secure Store application credentials)

o  Object Cache Portal Accounts

o      Super User Account

o      Super Reader Account

o  User Profile

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

o      Synchronization Connection Account

o  Server Search Custom Crawl Rule Accounts

o      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:

 

Happy sharepoint