I wrote recently about my philosophy for service accounts, and wanted to add a few more thoughts.
Security is important for our database servers. One of the loopholes that everyone should be aware of is that the service running SQL Server has complete control over the service and potentially if this account were compromised, the security of our installation would be at risk.
In this post I wanted to address two things related to service account passwords. The mechanics of building and working with these passwords and the ongoing maintenance in terms of changing the passwords.
One of the tools I recommend for anyone administering computer systems, including my parents on their personal computers, is a password manager. There should be a way for you to create and store complex passwords that are not easily guessed. I use Password Safe, but 1Password, KeyPass, and others are just as good.
Typically I’ve used these to store the administrative passwords for various systems for all DBAs, sysops, etc. to use. However I haven’t used these for service accounts.
Mostly because I don’t think any of us should be logging in as services. Apart from initial setup and testing, we shouldn’t use service accounts for anything.
I always recommend long, complex, random passwords for services. The password should be created and written down long enough for someone to enter it twice in the areas reserved for credentials, and then the paper should be destroyed.
I write these down because I want extremely long (20+), random strings that aren’t memorable and are really a one-time use string. Used just long enough to enter into the Services applet or as a credential in a PoSh (or other) script.
If you use groups for your account rights, and you should even for service accounts (SQL Server makes this easy), you can always use another account to test access. Grant it the same permissions and groups, and perform your tests.
I don’t worry about changing service account passwords. Yes, I know this isn’t recommended, but services rarely change or are used to log on, we can limit the access of an account to a particular machine, and since the password isn’t stored, it’s not very vulnerable to cracking.
If you are worried, then create a new, long, random string for the particular service(s) that are suspected to be vulnerable.
I don’t allow expiration of service account passwords, though in a few organizations that have required yearly service account password changes, we’ve scheduled the changes for slow periods, not waiting until the expiration occurred. I can almost guarantee that accounts will expire during a critical time when machines should not go down.
One caution. I know that changing passwords to long, complex strings is hard, and that there’s a temptation to set services to the same password or use some pattern to build passwords.
Patterns are poor security, and coupling services together with the same password (or account) is not worth the risk of issues if one system requires a change or the password is disclosed.