Controlling your Server Service Security using Group Policy

Have you taken a close look at your server services? Have you taken the appropriate measures to secure the key aspects of your services? You need to!

Why Services need to be Secured

Whether you are aware of it or not, all of your Windows servers are running services as soon as they are installed. A service is a special application that works seamlessly with your operating system to perform a specific task, or suite of tasks. Your servers are running services as soon as they are installed because the operating system needs many of these services to function properly.

There are many of these default services that control security. Some of the more common services that help control security on your servers (including domain controllers), include:

  • LSASS – This is the Local Security Authority Sub System, which is responsible for authenticating users, both local and remote. The LSASS is also responsible for controlling and enforcing the local security policy.
  • Security Account Manager – This service controls the local SAM, which holds local users and groups. The SAM is key to the security of a system, as it also holds the passwords for the user accounts and if compromised, can allow an intruder to access the computer.
  • Kerberos Key Distribution Center – This service controls the generation and distribution of Kerberos authentication keys for computers and users authentication to Active Directory.

It is clear that if someone were to break into one of these services, they would have the keys to the server or domain. In most cases, it is not the service that is being broken into, rather, it is a denial of service attack that is unleashed.

A denial of service attack is typically accomplished because the service is running on a given port or communication channel that is well known and documented. An attacker or malicious coder can exploit these ports and communication channels to try and “bottle up” the lines of communication to stop the services from working. For example, if the Kerberos Key Distribution Center service, which runs on a Windows Domain Controller, were to stop functioning, users would not be able to log on or gain new Kerberos tickets for authenticating to network resources.

These are just the default services, what about the additional services that are installed after the server is up and running? Just like the default services, additional services can also pose a security risk. There are services that can be installed that run Web hosting services, FTP services, file backup, and even key applications on a server. When these services are designed to communicate and control sensitive data and operating system files, they pose a potential gateway for an attacker to gain access to this information.

In the case of the World Wide Publishing service and the FTP service, they run on specific ports. These ports have been exploited for years, allowing malicious code to run and gain access to the computer over these ports. It has been a common practice for years to not allow these services to run on important servers, especially domain controllers.

Not only do the services themselves pose a threat and risk, but there are other aspects of the service that need to be considered.

Why Service Accounts need to be Secured

Most custom services that are installed after the operating system will need to have a service account configured to run along with it. The service account is designed to perform the tasks that the service needs to do, both on the local system and on remote computers. This is typically required since the actions that are performed by the service require authentication. The service can’t authenticate, since there is not an object in Active Directory that can represent the service. Instead of this, the service account acts on behalf of the service.

The security glitch, if you want to look at it that way, is that when the service account is installed it is granted administrative privileges. The service account is typically required to have administrative privileges, due to the nature of the way the service was written. In most cases, the service account could function properly if it was designed with less privilege. However, most services are not designed in this manner.

Since the service account has such elevated privilege, it must be protected. In my experience, most network administrators don’t protect these accounts properly. There are many ways to protect the account, the obvious being to change the password often. I will illustrate how you can do this using Group Policy later in this article.

Another aspect of this account that you need to consider, beyond the changing of the password, is how this account is audited. If you have an account on the network that has administrative privilege, never has the password changed, and is not tracked for logons… you have an account that could end up being rogue.

Using Group Policy to Secure Services

There are two different sets of configurations that you can use to help protect services and service accounts. First, let’s look at the built-in Microsoft settings that control services, as shown in Figure 1.

Figure 1: Service control in a default Group Policy Object

Within the standard Group Policy Object, you can control the startup type of the service, and the Access Control List (ACL) for the service. The startup type is key, as it controls how the service functions when the computer starts. Of course, if you are dealing with a domain controller and you want to ensure that the FTP service does not start when the computer boots, you can set the startup type to disabled.

For the ACL, you can control who can control the behavior of the service once the server and service are running. When you configure the ACL for the service, you can specify which user or group can Start, Stop, or Pause the service. This ACL is not shown from the normal service management console, so it is a perfect way to centralize the security of the service.

Beyond the standard Microsoft Group Policy settings are additional settings that come in PolicyMaker. PolicyMaker was just acquired by Microsoft from a company named DesktopStandard. You will see these benefits in the operating system within the next year. For now, you can still get PolicyMaker for your environment to leverage control over more than just the startup type and ACL. You can also control the service account and the service account password, as shown in Figure 2.

Figure 2: PolicyMaker allows for control over the service account and the password

With this GPO setting, you can easily configure which user account you want to use for the service, as well as what the password is for the service account. This is typically a very labor intensive process, as you need to dive into each service on each server where the service account is configured. If you have a sea of servers using the same service account, this can be very time consuming. Since this setting is a Group Policy setting, the standard background refresh will automate the new password configuration for you.


If you have not considered the security aspects of your server services, you have missed a key security area of your network. These services run on ports that can be compromised, as well as access essential data on your servers that must be protected. The service accounts pose a very high risk of compromise, especially if you are not properly changing the password for these accounts regularly. With Group Policy you are now able to control all aspects of the service, as well as the very laborious service account password. Using Group Policy to manage these configurations will not only improve the security of your servers and services, but will improve overall security of your network.

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