Don’t Change the BizTalk SSO Service Account — Or Else

Helpful hint du jour — if you know what’s good for you, don’t change the service account of your master BizTalk 2004/06 Enterprise Single Sign On service. If you insist on doing so, make SURE you have backed up your master secret first! As you may know, BizTalk Server 2004/06 stores much of its own configuration in the encrypted SSO database. If you change the service account, or even, I believe, its password, the service modifies the SSO database and will render your entire BizTalk group useless. Supposedly, after you change the account you can restore the master secret from your backup to fix the destruction, but I think it depends how lucky you feel. Go make sure your service account is set to “password never expires!”

One of my clients made this mistake, but thankfully the BTS group was not yet in production!

I suspect that Enterprise SSO uses DPAPI or the broader CryptoAPI for data encryption, and also probably to encrypt the master key itself in the service account user profile. This explains why changing the service account causes the service to be unable to read the database. The master key remains with the original user profile and does not exist in the new one. I do not think that changing the service account password will have any effect, as long as you remember to update the password in the SSO service configuration.

The solution, as I originally mentioned, is to restore the master key while the service is running under the new service account. This has the effect of copying the master key from the original service account user profile to the new user profile.

If you changed the service account and did not have a backup of the master key, you might have a chance of saving your configuration by switching back to the original account. If that doesn’t work, you will have no choice but to completely reconfigure your BizTalk installation.

Here is a Microsoft KB describing the procedure to change the SSO service account. This process works in 2004 or 2006. The difference in 2006 is that you may choose to backup and restore the master key through the SSO Administration MMC snap-in (requires MMC 3.0).