This week I spent some hours troubleshooting a problem with IIS7 (more on that in another post) and came across a gotcha you can run into when using user profiles. This is something I knew and I just forgot about it – so I thought I share with you – just in case…

In this post I said that IIS7 now loads user profiles for worker accounts. This is a nice feature since it allows using per account data that can be easily isolated from other accounts on the same machine. One example I gave was using the per-user certificate/key store. So far so good.

But you should be extremely careful whenever you want to change the password of a worker account. There are two ways of “changing” a password. The first is, when logged in as that user, to press Ctrl-Alt-Delete and select “Change password”. The other way is to go to “Computer Management” and reset the password of the account. These two methods are fundamentally different and the latter is not recommended at all.

Some background: Windows uses per-used DPAPI to encrypt some data in the profile (e.g. key stores). When you manually use DPAPI with the user scope, the same key is used. This key is partially derived from the user’s password. That means whenever the user changes his password, the DPAPI key gets renewed and rotated. When the user changes his own password (method 1) Windows can rotate the DPAPI key (because it knows the old and new password). Everything is fine.

But when you reset the password, Windows cannot rotate the key and all encrypted data that used the “old” key will get lost.

So when setting up worker/service accounts you have two options:

• Choose a really strong (and random) password upfront, e.g. using Keith’s excellent Password Minder tool.
• Login as the account and use the change password option

Don’t reset the password – or at least be aware of the implications.

You can easily test this yourself: Use the protected configuration sample described in my post here and encrypt the connection string. After that reset the worker account password and reconfigure the app pool in IIS7 with the new password. After that do a reboot and call the protected configuration page again. You will see a runtime exception and the connection string cannot be decrypted again.

Just keep that in mind.