Two simple rules for good service account credentials management

I decided to write this article after I received an email containing the account names and passwords for several SharePoint service accounts from one of my customers.  I could see that the email thread had circulated to several other people, including at least one other person who (like me) was not an employee of the customer.  The systems administrator was just following current (bad) practices at his company, which included re-using the same service accounts in for each SharePoint environment.


Service accounts can cause lot security headaches.  But following one simple rule can avoid most of the security problems associated with service account management.  That rule is:
Single-use:  use the credentials for  a service account in only one place

Now I’ll explain why this is a good practice, and expand on the implications of this rule.  At the end I add a second good practice that the single-use rule makes possible.

Poor management of service accounts creates many risks.  Common scenarios include:
Systems administrators are using service account interactively, which undermines accountability and auditing.

A systems administrator leaves the company and you want to change all passwords that they knew…but those include service accounts and you don’t know which ones.  And you don’t know what is going to break when you change the service account passwords.
You notice a service account in the Domain Admins group.  You are convinced this is not necessary, so you remove the account from the group.  And break something you didn’t realized depends on that service account.
Auditors want you to change service account passwords one a regular schedule.  But you don’t know what is going to break when you change the passwords.
You have a list of service accounts and passwords.  This represents a huge security risk, even if you have it well encrypted.  Because it is so easy to make a copy, and you will never know about the other copies

There are techniques you can use to try and find where a service account is used.  The most common involve scanning computer configurations for the accounts used by Windows services and Scheduled tasks.  But there are many other types of configurations items that may record service account credentials:  so many applications have their own application-specific configuration requirement for a service account.  All these problems go away if you follow the practice of only using each service account in one place.  That means in only one Windows service setting, for only one scheduled  task, or in only one application configuration item.  

Additional implications of the single-use rule  for service account credentials are:
Never use service account credentials interactively
Make the service account name as descriptive as you can, and use the description  field to make it clear where the credentials for this service account are set
Using the password for only one purpose means you can minimize the permissions or privileges granted to that account.

Now for the second rule.  This first rule is a necessary condition for the second rule.

Set-and-forget passwords:

When creating a service account, make the password a long, semi-random, impossible to remember string.
Copy-and-paste that string into that one place you need to use the credentials
Now forget the password.  Don’t write it down or save it anywhere.

If you follow these two rules, you eliminate most of the security risks that poorly-managed service accounts create.  Accountability and audit-ability are preserved, you can change passwords if you need to because you can easily determine where the credentials are used, and least-privileges principles can be applied.

Some potential objections:

Yes, you may end up creating a lot of service accounts.  But really, is it that hard to create an account?
What if different people need to create the account and set the credentials in the application configuration?  In this case, you have to get those two people to cooperate.  They probably have share a terminal session (physically or by something like WebEx) to get the initial setup of the application done.  The goal is to never put the password in an email, or a chat session, or any other medium that outlives your logon session.  If you can’t arrange that cooperation, then you should reconsider your work practices, because they are compromising security instead of improving it.

More serious objections may arise from application limitations.  Some applications require you to set credentials for the same account in more than one place.  So sometimes you may have to compromise.  But do it only when you have no other choice.  Keep in mind that:
It’s not a big deal if you sometimes have to set credentials in in two places (instead of one), so long as the account description (or the nature of the application) indicates this to people who may have to change the password in the future.
You  do this only very rarely

If an application absolutely requires you to reuse the same password many times, ask yourself if you really want to use such a badly-designed application.    I have seen a backup application which required the same service account to be used for all agent installations, and that account needed administrator privileges on every computer where it was agent installs.  Which meant anybody who needed to install a backup agent need to know the password to an account with admin rights on almost all or servers, including the domain controllers.  And changing that password required updating the backup agent configuration on every computer using the agent.  Talk about a major security risk!  You simply should not use an application that compromises your security so badly.

This article is obviously written from the point of view of a Windows systems administrator, but I am confident that the same guidelines are useful in other environments.  And those guidelines can be summarized in two lines:
Use the credentials for each service account in only one place
Do not record service account passwords anywhere

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.