Change AD FS 2012 R2 Service Account Password

One of the added features in AD FS 2012 R2 was the ability to leverage group managed service accounts (gMSA) which obviated the requirement to manually change the password associated with the service account.  See Getting Started with Group Managed Service Accounts for some background on gMSA.  You may also see the term sMSA which is a standalone managed service account.

Managed service accounts and virtual accounts were two new types of accounts introduced in Windows Server 2008 R2 and Windows 7 to enhance the service isolation and manageability of network applications.  In Windows Server 2012 and Windows 8 the capabilities of managed service accounts were further enhanced.  In the initial release sMSA could not be shared across multiple systems, and could be used only on a single machine.  This limitation was removed with Windows 2012 and the gMSA.  In Windows 2012 the gMSA password is managed by the Windows 2012 domain controllers and can be retrieved by multiple servers.  This minimises the overhead of a service account since Windows will handle the password change for such service accounts.

Anyway, you are probably reading this as you did not use the gMSA and need to change the password.  There is a script here to assist should you want to convert to a gMSA.

Changing AD FS 2012 R2 Service Account Password

The process to change the AD FS service account password in AD FS 2012 R2 is more streamlined than in previous versions.  As noted in installing AD FS for Office 365 part one, there is no longer a dependency upon IIS in this version of AD FS.  Because of this, there is no longer a need to then update passwords in the IIS application pool.  We need to concentrate our efforts on updating the password stored by the AD FS service on each STS server in the farm.

In short we have to:

  1. Stop AD FS service on all AD FS servers in the farm
  2. Change the AD password for the service account
  3. Ensure AD has replicated
  4. Change the AD FS service password on each AD FS server
  5. Start AD FS service on each server in the AD FS farm
  6. Test

Stop AD FS Service On All AD FS Servers in The Farm

Stop the AD FS service on all AD FS servers.   Use which means you prefer to do this, this could be either the services applet or PowerShell.  In the below example PowerShell is used locally on the server.

Stop-Service adfssrv

Stopping AD FS Service Using PowerShell

Change the AD Password For the Service Account

Follow your documented process to change the assigned password for the AD FS service account.  This should be then stored so that it is in compliance with your internal security policies and practices.

Ensure AD Has Replicated

It is possible that your AD FS farm is deployed in multiple datacentres to provide site resilience.  This may mean that there are additional considerations for AD replication latency to the additional sites.  Ensure that AD has successfully replicated the changed service account password so that the updated password is available to all AD FS servers in the farm.

One potential method is the Active Directory Replication Status Tool.

Active Directory Replication Status Tool

Change the AD FS Service Password on Each AD FS Server

Now that AD has replicated to all of the locations which contain AD FS servers, we can update the password stored on each AD FS server.

In the example below we are using the services.msc applet, though there are many other ways to do this.  Choose your weapon!

AD FS Service Previously Stopped - Next Step Is To Update Saved Password

After opening the properties for the AD FS service, select the Log On tab.  Enter the new password, confirm it and then click apply to save the change.

Updating AD FS Service Account Password

Start AD FS Service on Each Server in the Farm

All AD FS servers have had their service account updated, and we can now start the services on the servers.  In PowerShell we could use:

Start-Service adfssrv

Starting AD FS Service Using PowerShell

Ensure that the service starts, and no issues are reported in the event logs.

Also ensure that Web Application Proxy (WAP) servers are running without issues, and their event logs are also clean.


Ensure that you test AD FS is functioning correctly on all servers in the farm, and also that external access through WAP works without issue.



Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *