Securing Windows Service Accounts (Part 2)

If you would like to read the first part in this article series please go to Securing Windows Service Accounts (Part 1).


In our first installment of this article, we covered the facts that service accounts are high privileged accounts (usually), which need to be protected above other accounts. In essence, these user accounts are just like the IT/admin accounts, except that they are not managed nearly as well. We also looked at the fact that these accounts should not be the Administrator account. The reasons here were obvious, but it had to be stated regardless. In this installment, we will continue to go through configuration checks and reasons why these service accounts need to be secured.

Ensure Service Accounts are Not Human User Accounts

I often find that service accounts are using the IT staff user accounts. I do understand the reasoning here, yet the outcome is horrifying. The reason is that the IT staff member was under pressure to get an application installed and there seemed to be no time to create a new user for the task, so instead their own user account was used. The username and password was readily available, so it was used. The horrifying part is that this password usually has not changed since that point in time.

The issues continue, since the service account is now associated with a human user account. First, if the user changes job roles, say goes from IT to HR, now that user account should no longer have admin privileges for the domain. What will occur now? Second, if the user leaves the company, what will happen with the user account. The account needs to be disabled and soon deleted, but it can’t due to the fact that the account is also being used as a service account. This leaves a back door into the company for the employee that left the company, since the account can’t be disabled and deleted. Third, even if the user remains in IT, the employee will continue to state that changing the password is not possible, as it will disrupt the service that the service account is being used for.

No matter what in this instance, the service account must be changed. You will need to discover all locations that this account is being used and change the username to a true service account.

Ensure Service Accounts Have Workstation Restrictions for Logon

I often hear that service account passwords can’t be changed due to the fact that IT does not know all of the locations that the service account is being used. I do understand that this is a dilemma, but it is not an excuse. IT “SHOULD” know these types of details, even in a very large environment. Actually, in a very large environment it is even more important, as issues pertaining to pass-the-hash, vulnerabilities, weak passwords, and more can have a greater effect and are much more difficult to troubleshoot.

In these instances, I suggest that the IT staff set up auditing on the domain controllers to track down when these accounts logon. Since the accounts are only being used by the services (not humans as discussed in the last section), the audit trail will be very precise detailing which service and which server the service account initiated the logon request from. I suggest logging for about 30 days, to include any end-of-month processes that use applications that are only used one time a month.

A few key notes on setting up this auditing:

  • Be sure to setup “Audit Account Logon Events” in a GPO that is linked to the Domain Controllers OU, which can be seen in Figure 1.
  • Be sure to either review every security log on every domain controller to track down all logons (as this information is not replicated between domain controllers), or setup Event Log Forwarding to centralize the log from all domain controllers (Event Log Forwarding is free and more information can be found here).

Figure 1:
Audit Account Logon Events set to Success

Once you have a listing of every server that the service account is being used on, you can now make decisions on correctly configuring the service account. First, if the service account is crossing too many services, you can now create unique service accounts per service to reduce overall risk. Second, you can setup a list of servers for which the service account is allowed to logon to. This is configured within the user account in Active Directory. The Logon To tab, then setting up the list of servers for this configuration is seen in Figure 2 and 3.

Figure 2:
Configure the Log On To setting for a service account in Active Directory.

Figure 3: Creating a list of servers that the service account can logon to.

What this setting does is restrict the user from only logging onto the listed server(s). It takes the attack surface from every computer in the entire domain to only those servers that are listed. By far one of the most powerful and impressive settings possible for a service account.

Ensure Service Accounts Have Secure Passwords

I have been discussing the proper configuration, length, setup, and management of passwords for years with regard to human user accounts. When it comes to service accounts, I feel it needs to be even more stringent. We are talking about user accounts that have elevated privileges, rarely if ever tracked, used to access high risk data and servers… yet the password is never changed and usually not known!

Since the service accounts are no longer going to be Administrator, nor will they be human accounts, the password will not need to be used by any human except for at the initial configuration. Since this is the case, the password can be long, complex, and strong. I suggest a password that meets the following criteria:

  • 30+ characters
  • Use of upper case alpha, lower case alpha, numbers, special characters, and spaces
  • A pass phrase is always easier to type in for this situation, something like “People who think they know everything are a great annoyance to those of us who do.”


Service accounts are by far one of the most annoying, yet important aspects of securing your Windows infrastructure. We need service accounts, there is no doubt. We must use them and without good security measures, we leave these accounts vulnerable with significant exploits. We need to get control over these service accounts, ensuring they have the best security possible, as we tend to configure them and then forget about them. Here we have taken some easy approaches in how to secure our service accounts. First, ensure the account is not using the builtin Administrator account. This causes a conflict in roles and simply should not be done. Second, be sure not to double up a service account in conjunction with a human user, especially not an IT user. Third, the workstation restrictions for the service accounts should be configured to only include those servers where the service account is being used. This is an ideal way to reduce the attack surface. Finally, be sure to configure the service accounts to use a long, strong, and complex password. Ideally a password that is longer than 30 characters, uses all possible character types, and is not shared with others.

If you would like to read the first part in this article series please go to Securing Windows Service Accounts (Part 1).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top