We make users change their passwords because we’re mean. Well, that and it’s more secure: Passwords spend less time “exposed,” so they’re less likely to be compromised. It’s important to understand exactly how passwords can be compromised, so that we can set some sensible ground rules for password expiration. After all, the 30, 45, 60, and 90-day marks are all pretty arbitrary. Is one better than another? We also need to consider service passwords, which many companies don’t expire—at least not as often as user passwords. Are services’ logon passwords subject to the same kind of compromise, and should we be changing them more or less frequently—or at all? And what about the passwords used by Windows’ background services? Shouldn’t those be changed, too?
The problem is that changing service passwords is a massive pain in the neck. Each user can be guided to a Web site or dialog box that handles the password change routine; services’ passwords have to be manually changed, and we have to manually update every instance of the service, on however many computers, so that it knows to log in with the new password. Heaven help you if you miss an instance, because the next time that computer restarts for whatever reason, the service won’t be able to log in—and you’re likely to not even notice until users start complaining about inoperative services. In my video, I'll show you how to change service passwords using PowerShell.
So given that we ought to treat services just like users, and given that services can’t use those dialog boxes and Web sites to handle the change, what should we do? I’ll explore some of the options and answers to service password expiration in this article.