Four Terrible Service Account Management Habits

When it comes to bad habits of server administrators, one of the worst is what goes on with service accounts. Here are four bad habits that I’ve noticed server administrators regularly indulge in when it comes to the configuration and management of service accounts:

Bad Habit One: Setting up service accounts with passwords that don’t expire.

Rather than come up with a strategy for managing service account passwords and rotating them on a regular basis, server administrators instead configure the accounts they use with services with passwords that don’t expire. Any password that isn’t changed on a frequent basis is more likely to be compromised than a password that is changed on a regular basis.

Bad Habit Two: Using the same password for all service accounts.

I see this one a lot. Rather than configure unique passwords for service accounts, and having a secure way of storing those unique passwords, many server administrators use the same password for all service accounts. Not only are service accounts configured so that their passwords don’t expire, every service account in the organization uses the same password.

Bad Habit Three: Over-privileging Service Accounts

Good practice is to always implement the principle of least privilege. Only provide the minimum necessary privileges to a user or service account. For the most part the documentation that accompanies products will describe in detail which privileges need to be assigned to the service account for things to function properly. Instead of carefully configuring the service account, some administrators will simply add the service account to the local Administrators group (or, in some cases the Domain Admins group!)

Bad Habit Four: One Service Account To Rule Them All

Rather than spend the time creating separate service accounts for different applications, some server administrators have instead created one single service account to be used whenever a service account is required. I’m not talking about a service account that needs to be the same across different nodes in a failover cluster. This is where the service account used with SQL Server on one computer is the same one used with IIS on another and is the same one used with the products in the System Center suite on yet more. 9 times out of 10, this service account will be over privileged.

What can you do about it?

Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 support managed service accounts. This is a special type of account where Active Directory is responsible for managing the service account password. With Windows Server 2012 and Windows Server 2012 R2, you can use group managed service accounts, allowing a managed service account to be used across multiple cluster nodes. With group managed service accounts, you create the account centrally in Active Directory and then install it locally on each computer that will use the account. Windows Server 2012 and Windows Server 2012 R2 also support Virtual Accounts, which are a local version of a managed service account. Virtual Accounts allow you to have separate accounts for each service without using the same built in service accounts.

If you are checking the security configuration of a server, check the membership of the Local Administrators group. If it contains local accounts, find out if they are being used as service accounts and, if they are, reconfigure the accounts so that they only use necessary privileges rather than being delegated full local administrator rights.