Controlling Service Security Using Windows Server 2008 (Part 2)

If you would like to read the first part of this article series please go to Controlling Service Security Using Windows Server 2008.

Introduction

Based on the great feedback from the first article, in conjunction with feedback from my training classes, I wanted to expand on the original article I wrote on securing services using Windows Server 2008. The first article discussed how to protect the services using both the historical services Group Policy setting and the new and improved services policy found in Group Policy Preferences. Both of these Group Policy settings allow for control of service security in different manners. This article will expand on these security settings, giving you more control over the service accounts that control each service, as well as “real time” updating of the services and their accounts. As both a network administrator and security auditor, I know the importance of making sure that the network applications are available, as well as the network applications need to be secure. Finding the balance between these can be tricky. This article will give every administrator and every auditor the arsenal to meet both of these needs regarding services and service accounts.

Protecting Service Accounts

Service accounts are used by services to perform actions to the computer where the service is installed or to connect to other network resources to perform a task. When service accounts are created and configured, the level of privilege varies. In most cases, service accounts are granted some level of administrator privilege. For the majority of the services that are geared towards servicing a network of users, service accounts are generally granted membership in the Domain Admins group within Active Directory. In some instances service accounts might be granted membership in the Enterprise Admins group, which in most cases is far too much power for a service and its account. However, depending on the programming of the service, this might be a mandatory configuration.

Since service accounts are granted such power during installation and configuration, these accounts should be properly secured. In order to secure these accounts, administrators must take additional actions with each and every service account. The tasks are not that complex, but due diligence must be taken to ensure the accounts are protected, managed, and monitored against any rogue activity. The tasks that should be completed to help protect the service accounts include:

  • Configuring service account user to have limited workstation logon capabilities.
  • Password should be set to expire and reset often.

Workstation Limitations

Each user account which is created and stored in Active Directory can be limited to which computers they can logon to. It is rare that you will limit a standard user account to have only a few workstations they can logon to, but in rare instances it is possible. When it comes to service accounts, it makes all the sense in the world. The reason is that service accounts have a limited number of computers that it needs to logon to. If a service account is being used by a standard user or logging on to computers other than the computer running the service, this is a significant security issue. Thus, configuring the service account to only be able to logon to the computers where the service resides is a good security configuration.

The setting for limiting workstation (which includes both desktops and servers alike) is located under the user properties within Active Directory Users and Computers. By right-clicking on the user account (that is functioning as the service account) you will select Properties. Then within the user properties dialog box, select the Account tab. On this tab, you will see a Log On To button, as shown in Figure 1.


Figure 1: User properties dialog box can limit workstations that user accounts logon to

When you select the Workstations button, you will be shown a dialog box for inputting the list of workstation names. Here, you will just type the name of the servers where the service is configured to support the service running on that server. Figure 2 shows an example of what this might be for a service account that supports an HR application, where the service runs on three different HR servers.


Figure 2: Workstations dialog box allows for you to input the names of the servers

With this configuration, the service account will only be allowed to logon to the three servers listed. This means that the account, even if compromised, will not be allowed to logon from any other computer on the network.

Password Expiration and Password Reset

There has been a debate in the IT industry for years regarding whether or not a service account password should expire or not. There is little debate on standard user accounts, such as IT employees, HR employees, executives, etc. However, most IT admins will claim that if the service account password is set to expire, the service will fail if the password is not changed. Yes, this is true! If you look at the situation, the IT administrator has a point, in that the password would need to be changed within ADUC and on EVERY server where the service account is being used. For a company that has numerous servers and the servers are spread throughout the world, this might be hard to accomplish.

However, with technology available today, service account passwords can be set to expire and the process to reset the password can be accomplished within a minute! There are four steps to this process, all are very easy to configure and maintain.

The first step is to configure the service account to have an expiring password. You can clearly see in Figure 1 that there is an option for Password never expires toward the bottom of the dialog box. You will need to ensure that this box is not checked. This will have the service account adhere to the password policy for the entire domain with regard to how often the password expires. By default in a Windows Server 2003/2008 domain this is set to 42 days. This means that approximately one time a month you will need to reset the service account password.

This brings us to step 2. Step 2 is resetting the password for your service account. Within ADUC you will select the service account object, then right-click on it. The right-click menu has an option to Reset Password. Here, you will type in the new password and verify the password.

Note:
Be sure to not check the check box labeled “User must change password at next logon”. This would cause a significant issue in that the service account has no chance to update the password, since it is just configured via the service. Figure 3 illustrates what this dialog box looks like.


Figure 3: Password reset dialog box for your service account

Step 3 is to use the new Group Policy Preferences setting for Services. This is a new setting which is available when you are editing a GPO from a Windows Server 2008 or Windows Vista SP1 (with RSAT installed) computer. The new setting is available under Computer Configuration\Preferences\Control Panel Settings\Services. Within this interface for your service, shown in Figure 4, you will be able to input the correct service account name and new password. Simply input the password here that you input into the ADUC for the user account and all computers that are targeted to get the GPO will receive the new service account password.


Figure 4: Group Policy Preferences Services settings can reset the password for the service running on the target computer

The 4th and final step is to use a tool that can update GPO processing as soon as possible. You can go to each server and run GPUPDATE, but this might take a while and the server might not be readily available. Another solution is to use a free tool from Special Operations Software called GPUPDATE. Yes, the same name, but a totally different solution! This is a snap-in modification to the ADUC, which allows the administrator to force a background refresh of Group Policy from a domain controller. The GPUPDATE utility can update all computers in the domain, within an OU, or just a single computer. You can download this free tool here.

Summary

Service accounts are special in that they have elevated privileges, are rarely monitored, and rarely have the password reset. This makes for a rogue user in the environment. Taking the extra precautions to help protect these accounts is worth every second. Here I have shown you how to limit the scope of where these accounts can logon, which will reduce the overall attack surface if an attacker successfully breaks into the account. There is no reason for a service account to have the ability to logon to any computer in the domain. Next, the password for service accounts needs to be reset often. I have now showed you a four step, yet FAST, way to reset the password for a service account. Not only within ADUC, but how to get the computers running the account to be updated with the new password, within seconds! By taking these steps you will help protect servers, the network, and the overall computing environment.

If you would like to read the first part of this article series please go to Controlling Service Security Using Windows Server 2008.

Leave a Comment

Your email address will not be published.

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

Scroll to Top