Securing Critical and Service Accounts

Article
11/05/2014

Introduction

The first step towards securing a midsize business network is to understand what vulnerabilities an attacker is likely to exploit. The primary task of an attacker who has infiltrated a network is to initiate escalation of privileges, which is how an attacker attempts to gain more access from the established foothold that they have created. After an escalation of privileges has occurred, there is little left to stop an intruder from whatever intent that attacker has. Attackers can use many different mechanisms to achieve an escalation of privileges, but primarily they involve compromising existing accounts, especially those with administrator equivalent privileges.

Midsize business networks often employ some measure of security control over standard user accounts, but often do not exert much control over service accounts, thereby making such accounts vulnerable and popular targets for attackers. After an attacker has compromised a network to the point where a critical account with high privileges is compromised, the entire network can never be considered as completely trustworthy again unless it is flattened and completely recreated. Therefore the level of security for all manner of accounts is a very important aspect of any network security initiative.

Aside from the risks that external threats pose to a midsize business network, internal threats also have the potential to cause a great deal of harm. Internal threats embody not only malicious users but also those who might cause unintentional harm. The seemingly innocuous attempts to circumvent security measures by users that seek access to resources are but one example. All too often, users and services are granted access to greater privileges than necessary for reasons of convenience. Although this approach guarantees users have access to the resources they need to do their jobs, it also increases the risk of a successful attack upon the network.

Executive Summary

As the introduction has established, the matter of managing the security for all account types in a network is very important to managing risk for a midsize business network. Internal and external threats must be taken into account, and the solution to these threats must balance the need for security with the functionality a midsize business demands from their network resources.

This document will help midsize businesses understand the risks associated with administrative, service, application-related, and default accounts. This information will then provide a background from which steps that midsize businesses can take to mitigate those risks can be developed and deployed. To do this, it is necessary to discuss the nature of these accounts, how to identify them, how to determine the appropriate permissions that they require to function, and how to mitigate the risks inherent in elevated service accounts and administrator level accounts.

As part of the Microsoft Trustworthy Computing initiative, the default settings in Microsoft® Windows Server™ 2003 have been designed to secure the Active Directory® directory service against many different threats, but some settings for administrative accounts can still be further strengthened to increase the level of security in a midsize business network environment. Also, the services that are not provided with the Windows Server 2003 operating system that are installed by other applications need to be secured as well. This document will discuss methods to secure those accounts and services in addition to best practices for controlling how administrative privileges are deployed and managed.

Overview

This document consists of four main sections that provide information about securing administrator and service accounts in a midsize business environment. The first section is the "Introduction," which you are currently reading. The rest of the document is structured as follows:

Definition. This section provides some background details and some descriptions of the terminology contained in this document.
Challenges. This section describes some of the common issues that midsize businesses contend with when determining why there is a need to secure accounts and some of the problems associated with securing administrator and service accounts.
Solutions. This section is divided into three subsections to provide the reader with information about the phases of approaches that can secure the critical and service accounts in a midsize business. These subsections include:
- Assessment. This subsection describes the basic considerations for securing critical and service accounts and lays the groundwork for solution planning.
- Development. This subsection uses information discussed in the "Assessment" subsection to provide solutions that will help the reader develop plans that will enhance the security of critical and service accounts.
- Deployment and Management. This subsection describes recommended methods to implement secured administrator and service accounts in a midsize business environment.

Who Should Read This Document

This technical document is intended to provide assistance to technology professionals and technical managers that have concerns about the security of service, application, and administrator level accounts in a Microsoft network. Although a non-technical audience may gain some insight about secure account management principles from this document, an understanding of Microsoft Windows® and Active Directory account management concepts and procedures is required to gain the most benefit from the information contained in this document.

Definition

This section defines a number of terms that are used in this document and that may need some clarification.

Services. Services are executables that run at startup or can be triggered by other events or scheduled instances. Services often run in the background without much user prompting or interaction.
Service accounts. Simply put, a service account is often described as any account that does not correspond to an actual person. These are often built-in accounts that services use to access resources they need to perform their activities. However, some services require actual user accounts to perform certain functions, and many businesses still employ the practice of using domain accounts to run services as well.
Administrative account. Although there is a default Administrator account created on any new installation of Microsoft Windows or Active Directory domain, the term administrator account is often used in a general sense to describe any account that has been granted administrator level privileges. This document will make distinctions between the two for the sake of clarity.
Administrative groups. These groups can vary depending on the services that have been installed, yet can include those created automatically in the Builtin and Users containers. Such groups also include any that are created and granted administrative privileges.
Critical accounts. This document uses the term “critical account” to describe default accounts that are considered high risk because they have high-level privileges or present elevated risks due to their ubiquitous use.
Limited account. A limited account is any account that is not a member of any administrative group and that does not have any elevated privileges that are equal to that of a local or domain administrator account. Typically, a limited account would be a member of the Domain Users group or the local Users group.
Principle of least privilege. The Department of Defense Trusted Computer System Evaluation Criteria, (DOD-5200.28-STD), or Orange Book, is an accepted standard for computer security. This publication defines least privilege as a principle that “requires that each subject in a system be granted the most restrictive set of privileges (or lowest clearance) needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.”

Challenges

As explained in the previous section, unsecured administrator level accounts and service accounts present significant risks to the security of a midsize business network. Given the complexity of network environments and rapid rates of growth most business networks experience, it is fairly common to find account management practices that have significant vulnerabilities. These factors are why securing the critical accounts and the services that run on a network ends up being such a daunting task.

Some of the more common problems that midsize businesses have when considering how to approach such security concerns include the following:

How to protect against internal and external threats related to account management and employee work-around attempts.
How to identify all service and application accounts in use on the network and local computers.
How to secure sensitive service, administrator, and application-related accounts.
How to determine what accounts are associated with services and applications.
How to isolate service accounts from user account password policies.

Solutions

The solutions provided in this document follow the principle of least privilege and the least-privileged user account (LUA) approach of managing services, administrative, and critical accounts.

Most security-related training and documentation will mention the principle of least privilege. Although this principle is relatively easy to understand, it is also one that will greatly improve the security profile of any business that implements it. Simply put, this principle states that all accounts should have the absolute minimum set of privileges that are necessary to complete the current tasks and nothing more. This principle applies not only to users, but also for computers and the services that run on them.

Following such a principle not only helps protect against malicious attackers and malware, but also improves the security profile of a company by forcing technology professionals to do extensive research to determine what access privileges are needed by users, computers, and applications. Understanding this information provides insight as to what processes or settings may be insecure and require more protection, and therefore is an essential step to any successful security initiative.

For example, according to the principle of least privilege a person who has the role of domain administrator should only use an account that has the domain admin level privilege when performing tasks that require that level of access. Otherwise, when not performing tasks that require a higher level privilege, an administrator should use an account with standard access rights. Such a practice would reduce security threats that originate from human error and reduce the amount of damage done should an administrative workstation be infected by malware.

Assessment

To secure critical and service accounts, it is necessary to identify what those accounts are along with the threats associated with those accounts. However, it is also important to ensure that the consequences associated with changing these accounts are understood to ensure that the impact on business is reduced to acceptable levels.

Administrator and Critical Account Management

To secure administrative and critical accounts and associated groups, it is necessary to know what accounts and groups meet that criterion. It is also important to understand the scope of administrative level privileges and what systems they affect, especially when they govern domain controllers.

Therefore, it is important that the reader of this document have a detailed understanding of the administrative level accounts in their environment along with knowledge of all domain controllers and the accounts that manage them.

Administrative Accounts and Groups

The administrative level accounts in an Active Directory network include:

The default Administrator account, which is created when Active Directory is installed on the first domain controller in a domain. This account is the most powerful account in a domain, and a password must be established for it when it is created.
Any accounts created later that are either granted administrative privileges directly or by placement in an administrative group.

Administrative groups in an Active Directory domain will vary, depending on the services that have been installed in that domain. A basic Active Directory domain will include the following:

Administrative groups that are automatically created in the Builtin container.
Administrative groups that are automatically created in the Users container.
Any groups created later that are either placed within groups that have administrative privilege or that have administrative privileges assigned to them.

Service Administrators and Data Administrators

There are two different types of administrative privileges in a Windows Server 2003 Active Directory environment: service administrators and data administrators.

Service administrator accounts govern the maintenance and delivery of directory services, which includes the management of domain controllers and Active Directory.
Data administrator accounts govern the data that is stored in the directory service, on domain member servers, and workstations in the domain.

Although individuals may perform both roles in any given environment, it is still important to understand the default accounts and groups that are service administrators in scope. Service administrator accounts have a great deal of power in a network environment and therefore require the most protection. These accounts are responsible for directory-wide settings, the installation and maintenance of software, and the application of operating system service packs and updates on domain controllers.

Table 1. Default Service Administrator Groups and Accounts

Name	Container	Description
Administrators	Builtin	This group has full access to all domain controllers and all directory content stored in a domain. This group is the most powerful service administrator group and can change the membership of all other administrative groups.
Enterprise Admins	Users	This group is automatically added to the Administrators group in every domain and has complete access to the configuration for all domain controllers.
Domain Admins	Users	This group is automatically added to the Administrators group in every domain in a forest. Therefore, the Domain Admins have rights to all domain controllers and data stored in the directory of a domain and can modify the membership of any administrative group.
Schema Admins	Users	This group has full administrative privileges to the Active Directory schema.
Account Operators	Builtin	This group can create and manage accounts and groups in the domain but cannot manage service administrator accounts. This group has no members by default and, as a best practice, should not be used for any administrative delegation.
Backup Operators	Builtin	This group grants privileges to perform backup and restore tasks on domain controllers and has no members by default.
Server Operators	Builtin	This group can perform maintenance tasks on domain controllers and has no members by default.
DS Restore Mode Administrator	Not stored in Active Directory	This account is created during the Active Directory installation process. This account is used to start the domain controller in Directory Services Restore Mode, and although it is not the same as the Administrator account it does have full access to the domain controller whenever it is in Directory Services Restore Mode.

The service administrator groups and accounts listed in the preceding table are protected by a background process that periodically checks and applies a specific security descriptor that contains security information associated with that protected object. This process extends to any member of a service administrator group, and ensures that any successful unauthorized attempt to modify that descriptor on an administrative group member will be overwritten with the protected settings contained in the security descriptor data structure.

This security descriptor data structure exists in the AdminSDHolder object. Therefore, to modify the permissions on any of the service administrator groups or any of their member accounts the security descriptor on the AdminSDHolder object must be modified so that the changes will be applied in a consistent manner. Changes made to the security descriptor are changes applied to the default settings applied to all protected administrative accounts, so care must be taken when modifying permissions in this manner.

For more information about modifying permissions on service administrator accounts, see the Best Practice Guide for Securing Active Directory Installations, which is available for download at https://go.microsoft.com/fwlink/?LinkId=22342.

Service and Application Account Management

Services are executables that are often run without user interaction and launched automatically when an operating systems starts up, which is why services and service accounts are often overlooked as a unique security risk in a business network. Even when the security risks are understood, service account management can be a rather complex ordeal, considering that a simple password change may require several other changes to prevent outages.

Although Windows Server 2003 has default services and service accounts that are secure against threats, many third-party services and even other additional Microsoft services need to be secured because they require service accounts to run successfully. This requirement is especially true for enterprise management tools, such as Microsoft Systems Management Server or IBM Tivoli, because they often require the use of an account that has rights to the entire domain and even other domains with trust relationships.

In addition, the use of domain accounts to run services is still a common practice because it has been easier to manage services across the domain instead of at individual servers, despite the security risks associated with this practice. Services store the user account and password information that they use in the registry, whether they use local or domain accounts. Therefore, when a single computer is compromised this information can be used to escalate privileges for the attacker if those services use domain accounts. If a service uses an administrative level domain account, such a scenario could pose a threat to the entire network.

Service Account Vulnerability Scenarios

The practice of configuring services to use domain accounts for authentication leads to potential security exposure. The degree of risk exposure is dependent on various factors, including:

The number of servers that have services that are configured to use service accounts. The vulnerability profile of a network increases for every server that has domain account authenticated services that run on that server. The existence of each such server increases the odds that an attacker might compromise that server, which can be used to escalate privileges to other resources on a network.
The scope of privileges for any given domain account that services use. The larger the scope of privileges that a service account has, the greater the number of resources that can be compromised by that account. Domain administrator level privileges are a particularly high risk, because the scope of vulnerability for such accounts includes any computer on the network, including the domain controllers. Because such accounts have administrative privileges to all member servers, the compromise of such an account would be severe and all computers and data in the domain would be suspect.
The number of services configured to use domain accounts on any given server. Some services have unique vulnerabilities, which make them somewhat more susceptible to attacks. Attackers will usually attempt to exploit known vulnerabilities first. Use of a domain account by a vulnerable service presents an escalated risk to other systems, which could have otherwise been isolated to a single server.
The number of domain accounts that are used to run services in a domain. Monitoring and managing the security of service accounts requires more diligence than ordinary user accounts, and each additional domain account in use by services only complicates administration of those accounts. Given that administrators and security administrators need to know where each service account is used to detect suspicious activity highlights the need to minimize the number of those accounts.

The preceding factors lead to several possible vulnerability scenarios that can exist, each with a different level of potential security risk. The following diagram and table describe these scenarios.

For these examples it is assumed that the service accounts are domain accounts and each account has at least one service on each server using it for authentication. The following information describes the domain accounts shown in the following figure.

Account A has Administrator-equivalent privileges to more than one domain controller.
Account B has administrator-equivalent privileges on all member servers.
Account C has Administrator-equivalent privileges on servers 2 and 3.
Account D has Administrator-equivalent privileges on servers 4 and 5.
Account E has Administrator-equivalent privileges on a single member server only.

Figure 1. Domain service account vulnerability scenarios

The following table describes the scenarios detailed in the preceding figure and text and ranks them by the degree of vulnerability they present.

Table 2. Ranking Security Vulnerability Scenarios

Scenario	Description	Risk level
1	Account A is used by a service on Server 1. After Server 1 is compromised, the authentication information for Account A is discovered. When this occurs the attacker has access to the DC1 domain controller, from which all resources on the domain and information contained therein becomes vulnerable. This situation presents a critical risk scenario. Domain accounts with administrator-equivalent privileges to the domain or a domain controller should never be used to run services on a member server.	Critical
2	Account B is used by a service on Server 2. Account B also has privileges on Server 1 where Account A is running a service. When Account B has been compromised on Server 2 the attacker as achieved the same access provided by Scenario 1, thus exposing the domain controller and the entire domain to an attack. Account C also exposes the network to the same level of risk, because it could be used to compromise Server 2 from an attack launched on Server 3, which then can expose Account A to discovery, which then exposes the entire domain. These represent high risk scenarios but they can be resolved when the potential threats presented by Scenario 1 have been addressed.	High
3	Account D is used by a service running on Server 4 and Server 5. If Account D is compromised, an attacker will have access to all servers where Account D has privileges. If those servers do not include services that use accounts with a higher set or scope of privileges, this scenario will present a medium priority risk because the transitive vulnerability of Scenario 2 does not exist.	Medium
4	Account E is used by a service on a single server, Server 5, and does not have any other privileges or service associations. This scenario would be a low threat because it does not allow for an escalation of privileges beyond the single server.	Low

The risk levels in the preceding scenarios can be best explained as follows:

Critical Risk Level. This risk would immediately jeopardize the security of the entire network and business.
High Risk Level. This risk has the potential to compromise the security of the entire network but is not as immediate as a critical risk.
Medium Risk Level. This risk is important to address and could affect multiple servers, but does not expose a critical server to the vulnerability.
Low Risk Level. This risk could result in the compromise of a single server but does not jeopardize critical servers.

System Accounts

Services require accounts to access resources and objects that are managed by the operating system on which they run. If the account that a service uses does not have sufficient privileges to log on, the Microsoft Management Console (MMC) Services snap-in will automatically grant that account the required “Log on as a Service” user right on the computer that is being managed.

Windows Server 2003 includes the following three built-in local accounts that are used as logon accounts for various system services:

Local System. The Local System account, which appears as DOMAIN*\<computer name>*$ on the network and NT AUTHORITY\System locally, is a predefined local account that can start services and provide the security context for that service. This powerful account has full access to the local computer, including directory services when used on domain controllers. Although some services are configured to use this account by default on Windows Server 2003, it should not be used otherwise because it presents an obvious security risk, especially on domain controllers.
Local Service. The Local Service account (NT AUTHORITY\LocalService) is a built-in account that has reduced privileges that are similar to an authenticated local user account. This reduced access acts as a safeguard in case the service or process using it is compromised. Services that run as the Local Service account access network resources as a null session; in other words, they use anonymous credentials.
Network Service. The Network Service account (NT AUTHORITY\NetworkService) is a built-in account that also has reduced privileges similar to the Local Services account. However, instead of using anonymous credentials, the services and processes that use this account access network resources using the credentials of the computer account.

Note Changing the default service settings may prevent key services from running correctly. Caution should be used when changing the Startup type and Log on as settings for services that are set to start automatically by default.

Default Security Settings for Windows Server 2003 Services

Prior to Windows XP and Windows Server 2003, almost all services created by the operating system used the Local System account by default. This functionality caused some obvious security risks because such services were granted unlimited rights to the local computer. The default settings were changed with the development of Windows Server 2003 to improve the inherent security of the operating system. As a result, many of the same services now use the Local Service or Network Service accounts by default, which presents a lower vulnerability profile.

There are still some services that require use of the Local System account, including Automatic Updates, Computer Browser, Messenger, and the Windows Installer service. The services that still use Local System for authentication should not be changed to use other accounts. Doing so may cause serious problems and can potentially prevent such services from running correctly.

The following table lists service accounts that no longer use the Local System account in Windows Server 2003 along with the account type that they now use:

Table 3. Windows Server 2003 New Service Account Settings

Service	Log on as
Alerter	Local Service
Application Layer Gateway Service	Local Service
Remote Registry	Local Service
Smart Card	Local Service
TCP/IP NetBIOS Helper	Local Service
Telnet	Local Service
Uninterruptible Power Supply	Local Service
WebClient	Local Service
Windows Image Acquisition	Local Service
Windows Time	Local Service
WinHTTP Web Proxy Auto-Discovery Service	Local Service
DHCP Client	Network Service
Distributed Transaction Coordinator	Network Service
DNS Client	Network Service
License Logging	Network Service
Performance Logging	Network Service
Remote Procedure Call (RPC) Locator	Network Service

Development

To develop a plan to secure administrative and sensitive accounts, it is important to understand the fundamental elements that all best practices are based upon. Any step taken to secure accounts and services involves the same basic principles, and those principles are also a part of all best practice processes and procedures. This section will review these principles and key considerations.

Administrator and Critical Account Management

Best practice guidelines for securing administrative accounts in Windows Server 2003 are based on applying the principles of least privilege and the use of a limited user account approach. The first step in this process is to develop a thorough understanding of the current environment. The following three fundamental issues are key to developing an effective plan for improving the security of administrator and critical accounts:

Understanding and documenting the environment
Using the principle of least privilege
Using the least-privileged user account approach

Understanding and Documenting the Environment

Although seemingly self-evident, this first and most important step towards improving security with regard to administrator equivalent accounts can sometimes be the most difficult step in this process. If a company has not restricted and documented use of administrator level privileges, then it can be quite difficult to determine where administrator level privileges are in effect, especially where local accounts are concerned.

In terms of administrator level and other sensitive accounts, the understanding and documentation of a network environment involves information about who, why, what, and where. That is, who has authorization to use administrator accounts, why do those people have access to administrative accounts, what tasks are appropriate for the use of administrative credentials, and where are those credentials safe to be used.

The most significant aspect of documenting this information is the establishment of processes and procedures that audit where administrative accounts are used, why they are used, who used them, and what was done when they were in use. This information is best recorded proactively by provisioning, change control, and incident management processes that require any activity to be authorized and recorded before a task is completed. Such processes enable the careful auditing of administrative privilege usage, which also makes it much easier to spot suspicious activity.

As will be seen later in this document, understanding and documenting a network environment is the most significant step towards improving the security of critical accounts. Establishing best practice processes and procedures for the use and issuance of sensitive accounts is a fundamental part of this process and should occur prior to the implementation of any other guidance contained in this document.

Using the Principle of Least Privilege

Following the principle of least privilege is likely one of the most significant steps a company can take towards improving the security of their network environment. Although granting administrative level privileges is often the easiest and fastest way to resolve complex privilege or rights related issues, it is also the most risky. Also, while it is much easier for systems administrators to use an account with administrator level privileges all the time, such practices also elevate the risk profile of the network for which they are responsible.

The most basic application of this principle is as follows; administrator level privileges should be restricted for use by authorized personnel only when the task at hand demands the power inherent in those elevated privileges. Although it may seem onerous to implement practices that incorporate this concept, the level of exposure a company accepts by not adhering to this principle is too great to ignore.

The level of exposure to the most common vulnerabilities that networks can face is reduced by the application of this principle. Examples of these vulnerabilities include the following:

Kernel-mode rootkits
System-level key logging programs
Password interception attempts
Spyware and adware incidents
Unauthorized access to data
Trojan horse installations
Event log manipulation

When the use of administrative level accounts is reduced, the ability to use the elevated privileges inherent in those accounts for malicious activity is also reduced, thereby enhancing the security profile of the network. Also, by removing the ability to make major changes to the operating system, the ability of malware and spyware to install and run is also reduced. For these reasons, application of the principle of least privilege can have such a profound effect on network security.

Using the Least-Privileged User Account Approach

Users are regularly granted administrative privileges to their own computers in many business environments, especially portable computers. Although there may be some valid reasons for granting such expansive privileges, such arrangements expose the company to greater risk levels.

Using a least-privileged user account (LUA) approach combines best practice recommendations that enable companies to use non-administrative accounts to operate Windows XP–based computers. The result of these practices is a practical application of the principle of least privilege as applied to Windows XP client devices.

Because this document examines the issue of administrative accounts from a high level and pays particular attention to network level privileges, it is also important to consider the ramifications of the local user accounts on workstations. Although this type of focused approach is beyond the scope of this document, more detailed discussions of LUA are available on the Microsoft Web site. For more information, see the "Applying the Principle of Least Privilege to User Accounts on Windows XP" white paper at https://go.microsoft.com/fwlink/?LinkId=58445 or the article "Using a Least-Privileged User Account" at www.microsoft.com/technet/security/secnews/articles/lpuseacc.mspx.

Service Account Management

As with the management of administrator and critical accounts, there are three fundamental issues that are key to establishing a successful plan that can increase the security of services in a midsize business environment. It is important that the following three issues be addressed during development phases and incorporated into security policy procedures:

Understanding and documenting the environment
Using the principle of least privilege
Using the principle of least service

Understanding and Documenting the Environment

This recommended step may seem self-evident, yet many companies are not fully aware of all the roles and services that exist in their network environment. This lack of awareness and documentation can have any number of causes, but usually stems from rapid growth of network environments and a lack of time and resources to devote adequate attention to the need for documentation.

To understand whether computers are secure, it is necessary to understand what services run on those computers and what their properties might entail. This information is critical for securing servers and their services, along with the accounts that those services might require. For this task it is usually helpful to create a table of services, service properties, and the computers on which those services are used. The creation of such a table may be daunting, but the results are worth the effort. Also, keeping the table current is relatively easy after it is created and made a part of the server build and application deployment process.

There are several tools that can assist with the documentation of services and their properties on the network. Some of these tools include:

Service Controller Tool (sc.exe). This command-line utility is included with Windows Server 2003 and Windows XP. This tool provides an easy way to communicate with the Service Control Manager component from a command line to query and set service properties.
Service Controller List Tool (sclist.exe). The Windows 2000 Server Resource Kit comes with a tool that can list the running and stopped services on local or remote computers. Sclist.exe can be used to identify services that are run on remote servers that don’t have monitors or are geographically separated from the administrator.
Windows Management Instrumentation (WMI). This component is included with Windows Server 2003 and Windows XP and provides management information and control in enterprise environments. Administrators can use WMI to query and set information on computers, networks, applications, and services. In addition to providing the ability to use scripts for administrative task management, WMI allows administrators to identify the dependencies of services and any services upon which those services may depend.
Windows Management Instrumentation Command Line (WMIC). WMI also includes a command-line tool, WMIC, which provides a simple command-line interface to the WMI for queries and remote computer management. WMIC query outputs can be formatted to easily read HTML tables viewable with a browser, such as Internet Explorer.

Following the Principle of Least Privilege

Microsoft understands the importance of security and how the principle of least privilege plays a significant role in securing networked environments. Microsoft applied the principle of least privilege to the development of Windows Server 2003 to ensure that core operating system services are already using the least privileged account, and therefore these services should not require any further configuration. The focus of this approach should be on securing services that are not a part of the operating system, such as those that are supplied as components of other products like Microsoft SQL Server, Microsoft Operations Manager, or other third-party software products.

Accordingly, the principle of least privilege should be used when running any other services as well, even though it is often easier to just grant a higher level of privileges when implementing new products. For example, services should use the Local Service account whenever possible to restrict any successful attack to the local computer and not the entire domain. Services that require authenticated network access should use the Network Service whenever possible. Services that require broad privileges should use the Local System account. Finally, if a service requires the use of a domain-level administrator account, then the server or servers on which that service runs should be regarded as high security systems that are protected in the same manner as other sensitive or critical network resources and domain controllers.

Group Policy can also be used to control specific services that are allowed to run on computers. Several properties can be controlled by browsing to Computer Configuration\Windows Settings\Security Settings\System Services and opening the Properties page for that service. Settings such as the startup mode and the permissions for which accounts may be used to carry out particular operations on that service (starting or stopping, for example) can be modified.

Implementing the principle of least privilege depends on understanding the systems in the environment. By combining these two core concepts, it is possible to assess which services are running on computers, their status, and the credentials that are used for each service and server. Only then can it be possible to effectively and methodically reduce each service to use the least privileges necessary for continued functionality via proper change control processes, which also add ease to the continued documentation of the environment.

Following the Principle of Least Service

Finally, the principle of least service states that the operating system and network protocols available on any network resource should run only the exact services and protocols that are required to support the business. For example, if a server is not required to host any Web applications, then the World Wide Web service should be disabled or removed.

Most operating systems and programs install many more services and protocols in a default configuration than are actually required for common usage scenarios. Therefore, a custom install process should be used whenever possible to control what services and protocols are enabled or installed during an application process. This approach makes it possible to document what processes are created during an installation in case it is later determined that a service created during installation is no longer needed.

When deploying new servers or developing server images, it is a best practice to include steps in which the systems administrator shuts down all but the essential services required by that operating system. The disabled services can later be enabled as needed for whatever application that server may be required to run. For example, it was common practice to disable the Alerter and Messenger services on Windows operating systems prior to Windows Server 2003, because such services were not generally required. Disabling them increased the security profile of the server being deployed without harming functionality.

Ensuring the proper placement of services is also an important part of this principle. For example, the Routing and Remote Access Service or the Internet Information Service should never be placed on domain controllers, because these background services increase the vulnerability profile on domain controllers. If compromised, a domain controller could grant unlimited access to the rest of the domain. Therefore, Microsoft best practices recommend that no additional services, other than those absolutely required to operate a domain controller successfully, should be deployed on a domain controller.

Deployment and Management

After key considerations and basic principles have been discussed, a number of specific recommendations based on these concepts can be considered. Undertaking any of these individual actions can improve the security of a business network, but when combined they become part of a comprehensive security framework that can greatly reduce the vulnerability of a midsize business network.

Administrator and Critical Account Management

A number of best practice approaches can be implemented to secure administrative accounts in a Microsoft Windows network. The following methods have been proven to help reduce the vulnerability associated with such accounts and are commonly used in midsize business networks.

Separating Domain Administrator and Enterprise Administrator Roles

The Enterprise Administrator role is the most powerful role in an Active Directory forest. Steps must be taken to ensure that this type of account is secured and its use carefully regulated. There are two approaches to managing this type of account:

Controlled Single Account. The first approach is to limit this role to a single account that is closely monitored and controlled to ensure that its use only coincides with authorized change control requests for tasks that would require its use. Any monitored event that occur in this account’s name would require immediate investigation and must be accompanied by some form of authorized change request event.
Temporary Account. Another approach would be to never set up such an account until it was needed to accomplish an authorized task. When an authorized need did occur, a temporary account could be created, used to complete the task, and then deleted. Because the need for such a powerful account is rare, such steps would not be a significant addition to administrative overhead.

Separating User and Administrator Accounts

Accounts are generally associated with users. When using the principle of least privilege, accounts can be associated with tasks instead of just roles, especially when administrative functions are considered. For each person who performs an administrator role there should be two accounts, one for day-to-day usage that is a typical user account and another with administrative privileges that should only be used while completing administrative tasks at an administrative workstation.

Administrative accounts should be limited to administrative tasks and to administrative workstations that are part of a trusted network similar to domain controllers. Administrative accounts and their associated workstations should not have access to e-mail or the Internet, and should not be logged on when not in use. Administrators should have different passwords for their standard use accounts and administrator accounts, and administrator password strength should be the highest possible on the network.

These simple precautions significantly reduce the vulnerability exposure that such accounts present by reducing their exposure to the outside world and limiting the amount of time they are in use.

Using the Secondary Logon Service

It is possible to execute programs under an account other than the one currently logged on when using the Microsoft Windows 2000 Run as service. With Windows Server 2003 and Windows XP Professional this same functionality was renamed as the Secondary Logon service.

Secondary Logon allows administrators to log on to a computer with a non-administrative account and perform administrative tasks by running trusted administrative tasks with administrator credentials without having to log off. This functionality reduces the risks associated with use of administrator credentials by employing a form of the separation of user and administrator accounts concept mentioned earlier.

Running Separate Terminal Services Sessions for Administration

Terminal Services and Remote Desktop connections are commonly used to manage servers without the need to physically access the server console. This approach is not only efficient but also more secure than using an administrator account to interactively log on to the server, especially when not using an administrator level account on the computer from where the connection was established. When an administrative task is completed, the administrator account should log off and the session will disconnect.

Renaming the Default Administrator Accounts

Renaming the default administrator account remains a common practice in many midsize businesses, and it does help somewhat to reduce the vulnerability profile of that account. However, this approach only hinders a handful of attack types because many tools and techniques exist that can help attackers determine which account is the built-in Administrator account. Although renaming the default account can be somewhat helpful, it is actually more effective to create secondary administrator accounts and then to disable the original built-in accounts, as discussed later in this document.

Creating Decoy Administrator Accounts

When used in tandem with an intrusion defense mechanism that can detect and send alerts about specific account activity, the use of a decoy Administrator account can function as an effective additional layer of defense against attempted attacks on a network. Even by itself, this technique can slow some attackers down when granted more account lockout tries than typical accounts and given strong passwords. Decoy administrator accounts should not be members of any privileged security groups and should be monitored for any activity. Any attempt to use such an account should trigger an immediate investigation.

Creating Secondary Administrator Accounts and Disabling Built-in Accounts

If each person in an administrative role is not given a unique administrator equivalent account to use for administrative tasks—and even if Terminal Services is not used for server administration—it is still best practice to create a secondary administrator account. A secondary administrator account acts as a failsafe against the compromise of a primary administrator account and should be created before disabling the built-in administrator account.

Note It is important to make certain that another account with appropriate administrator privileges has been created before disabling the built-in Administrator account. Disabling the built-in administrator account without ensuring that another equivalent account exists could cause a loss of administrative control over the domain and may require a system restore or reinstall to correct.

Enabling Account Lockout for Remote Administrator Logons

Although the built-in administrator account cannot be locked out, it is possible to lock out remote logons that use the administrator account. To accomplish this task, the Microsoft Windows 2000 Server Resource Kit contains a command-line program called Passprop.exe that can enable account lockout for remote logins. When this command-line tool is used with the /ADMINLOCKOUT switch, it makes both interactive and remote login use of the administrator account subject to existing lockout policies on Windows 2000 Server.

Note Using Passprop.exe /ADMINLOCKOUT on Windows Server 2003 will affect remote login and interactive login use of the administrator account. Care should be taken when using this functionality because use of the administrator account for server administration will be impossible while it is in a locked-out state.

Creating Strong Administrator Passwords

Using a strong password for any administrator equivalent account as well as the built-in administrator account is another best practice. Strong passwords reduce the likelihood of an attacker using a brute force attack to escalate privileges. Strong passwords typically consist of the following:

15 or more characters
Never contain account names, real names, or the company name in any form
Never contain a complete word, slang term, or other readily searchable term
Is significantly different in content from previous passwords and not incremented
Makes use of at least three of the following character types:
- Uppercase Letters (A, B, C...)
- Lowercase Letters (a, b, c...)
- Numerals (0, 1, 2...)
- Non-alphanumeric Symbols (@, &, $...)
- Unicode Characters (€, ƒ, ?...)

Detecting Weak Passwords Automatically

There are two basic approaches that password scanning tools use when checking for weak or blank password usage. These approaches are:

Online password scanning. Online scanning involves multiple attempts to log on using common password flaws, such as use of the word “password” as a password, or even the use of blank passwords. The Microsoft Baseline Security Analyzer (MBSA) is an example of a tool that uses this method.
Offline password scanning. Offline scanning involves various mechanisms that use cached credentials to test, and even rank, the password strength of different accounts. Tools that use this approach have some advantages over the previous method but involve the use of third-party software.

Although third-party tools are available to scan for weak passwords, Microsoft provides the Microsoft Baseline Security Analyzer (MBSA) as a free download. The MBSA can provide notification of any disabled or locked accounts that are discovered while enumerating all user accounts to check for the following password flaws:

Blank passwords
Use of user names for passwords
Use of computer names for passwords
Use of the words “password,” “admin,” or “administrator” for passwords

For more information, please refer to the Microsoft Baseline Security Analyzer Web page at www.microsoft.com/technet/security/tools/mbsahome.mspx.

Restricting Administrative Tasks to Trusted Computers

Administrator credentials are a very tempting target for would-be intruders, and the methods used to gain access to those credentials can be very difficult to detect. Keystroke loggers and screen scrapers are some of the typical tools that are used to obtain this sensitive information by capturing every keystroke made and character entered on a compromised computer. These forms of malware can be very stealthy and difficult to detect, let alone remove, after they are installed on a computer.

Therefore it is a best practice to ensure that administrator equivalent accounts are limited to using as few computers as possible to reduce the vulnerability to such threats. Also, when limiting the resources on which administrative accounts should be used, it is important to ensure that such systems are trusted and well protected. There are many techniques available to protect sensitive assets, such as network isolation using IPsec, that impose greater security for certain devices while not impacting the usability of the network itself.

For more information about using IPsec to isolate domains and servers, see the Server and Domain Isolation technology center at www.microsoft.com/technet/itsolutions/network/sdiso/default.mspx.

Auditing Accounts and Passwords

Auditing accounts on a regular basis helps to ensure the integrity of domain security against attacks that involve the escalation of privileges. If attackers gain access to an administrative level account, they can introduce vulnerabilities and bypass security measures. For example, attackers that gain access to an administrator equivalent account can create proxy user accounts, change account memberships, and even modify event logs to cover their tracks.

All domain-level administrative users and groups as well as all local administrator accounts and groups on sensitive servers should be audited on a regular basis. Use of such administrative credentials needs to be audited to ensure that they are only used within the guidelines set by internal policies and in concordance with any established and well-documented internal processes, such as change control procedures. Use of regular account audits ensures that proper procedures have been carried out in the course of administrative tasks and even check that policies regarding password strength are being followed.

Event Viewer can be a useful tool in the auditing process if steps have been taken to secure event logs from tampering. For information about using event logs to monitor network security and on how to secure event log data, see The Security Monitoring and Attack Detection Planning Guide at https://go.microsoft.com/fwlink/?LinkId=41309.

Prohibiting Account Delegation

Delegated authentication occurs when a network service accepts a request from a user and assumes the identity of that user to initiate a new connection to other network services. Delegated authentication has several useful applications for multi-tier applications that use single sign-on capabilities on the network. Microsoft Outlook Web Access (OWA) uses this mechanism to provide an interface with databases on other computers.

Administrator accounts should be designated as "Account is sensitive and cannot be delegated." This approach helps protect administrator equivalent credentials from impersonation via servers marked as trusted for delegation. Computer accounts in Active Directory that correspond to computers that are not physically secured should be denied the right to participate in delegated authentication. Also, domain administrator accounts should be denied the right to participate in delegated authentication because they have access to sensitive information and resources on a network.

For more information about account delegation, see Enabling Delegated Authentication at https://technet2.microsoft.com/WindowsServer/en/Library/72612d01-622c-46b7-ab4a-69955d0687c81033.mspx?mfr=true.

Enforce Multi-Factor Authentication for Administrator Accounts

The Administrators, Enterprise Admins, and Domain Admins groups contain the most powerful accounts on a business network. Accordingly, these accounts should also be the most protected as well.

Multi-factor authentication methods improve the security of the logon process by requiring additional identifying information from authorized users, which increases the amount of information an attacker would need to acquire in order to compromise the account. As the name implies, a multi-factor authentication method requires multiple pieces of identifying information. This method might typically require the following:

Something the user has, such as a smart card.
Something that the user knows, such as a personal identification number (PIN).
Something that the user is (typically referred to as biometrics). Can be as simple as the use of a fingerprint scanner for authentication.

The use of multi-factor authentication removes the vulnerabilities associated with clear-text user name and password–based authentication methods by using a smart card that contains a randomly generated code that identifies the account holder. Each card contains a unique private key that guarantees the singularity of authentication information.

Furthermore, use of a smart card requires use of a smart card PIN, which is another encrypted code that the card owner sets and then stores on the card. This PIN makes the private key held in the card available for use during authentication; otherwise the key remains encrypted and unusable.

For more information about multi-factor authentication methods and smart cards, please refer to The Secure Access Using Smart Cards Planning Guide at https://go.microsoft.com/fwlink/?LinkID=41313.

Service and Application Account Management

There are also a number of best practice–based methods that can increase the security of services and service accounts. This section will describe the methods that have been proven to improve the security of services in real world network environments. Although the use of all these methods combined can greatly improve the security of midsize business networks, it is best to evaluate each to determine the best combination of approaches for each unique business environment.

Auditing Services for Essential Properties

As mentioned earlier, the first step in developing a plan to secure services in a given environment is to gain a thorough understanding of those services, where they occur, and why they are used. Although this sounds like a relatively straight-forward task, it can be surprisingly difficult to identify what services run on each computer and what degree of management those services require.

Each server in an environment should be documented and audited to determine all services that are running on it and which logon credentials each service uses for authentication. There are a number of tools available to assist administrators with this task, including:

System information in Microsoft Windows Server 2003. System information can provide a comprehensive list of properties for all services running on a local computer. However, this tool does not provide a very efficient way to audit a large number of servers.
Services Management Console. In the Services administration console, the Log On tab of a service’s Properties page can be used to determine what account a service uses for authentication. The Dependencies tab can also be used to determine what services that service depends on and what services depend on the service being viewed. Unfortunately this method is also inefficient for auditing a large number of servers.
Windows Management Instrumentation (WMI). WMI can be used to obtain information about the services that run on all servers in a network. When used with scripts or other programming tools, it is possible to use WMI to obtain configuration details regarding most aspects of a network’s computers as well as make changes to those computers.
Windows Management Instrumentation Command Line (WMIC). WMIC provides the same functionality as WMI in the form of a command-line tool that is capable of interoperating with existing shells and other utility commands that can be extended with scripts or other applications.

With the WMIC service, it is possible to obtain a variety of information about the services running in a network, including:
- Description
- DisplayName
- ErrorControl
- InstallDate
- PathName
- ProcessId
- StartMode
- StartName
- Status
- Scripts
  
  As mentioned earlier, WMIC can be leveraged to automate the management of remote and local computers by using scripts.
Other enterprise management tools. There are several other management tools that can be used to assist with the auditing of server services, including:
- Microsoft Systems Management Server (SMS)
- IBM Tivoli
- HP OpenView
- Lieberman Software Service Account Manager

Determining Which Services are Necessary

Windows Server 2003 creates several default services when it is first installed and configures those services to run on computer startup. These default services provide application compatibility, client compatibility, or facilitate systems management. However, not all environments require the use of all these services. All services should be examined to determine whether or not any of them may be disabled, thus reducing the vulnerability profile of the server on which they run.

Defining which services are required and which may be disabled can be a complicated process. Some services present obvious answers, but others may not present such clear-cut options. When determining which services can be disabled there are two main criteria that can be used:

If there is no reason to use a specific service it may be disabled.
If there might be a need to use the service in the future, but not currently, then that service may be disabled until needed.

The services that are needed on any particular server depend primarily on that specific server’s role. For example, the Internet Information Services (IIS) service should only be used on a Web server or an application server that uses a Web-based distribution mechanism. If that server does not utilize Telnet services or remote access services, they should be disabled on that server.

When software is installed on a server it may also its own set of services. For example, Microsoft Systems Management Services will install the Wuser32 Remote Control Agent service to supply the remote client functionality for software updates or remote management. It is important to understand what services a software package might install or rely upon for functionality when determining what services should be disabled.

Using the Security Configuration Wizard

The Security Configuration Wizard (SCW) that is provided with Windows Server 2003 Service Pack 1 (SP1) can be used to quickly configure servers based on functional requirements, such as Web server or domain controller, while allowing administrators to author security policies to minimize vulnerabilities. The SCW can be used to help discover what services are running on servers in the network and the dependencies those services have.

To install the SCW on a Windows Server 2003 server

Open Control Panel.
Double-click Add or Remove Programs.
Click Add/Remove Windows Components.
Select the Security Configuration Wizard check box under Components on the Windows Components screen.
Click Next.
Click Finish when the installation process is complete.

The SCW can be used to help reduce the attack surface of computers that run Windows Server 2003 with SP1. The wizard guides administrators through the process of creating security policies based on the roles performed by any given server. The term server role defines the main function that a computer performs within a network and the required services, inbound ports, and settings will vary depending on what role a server performs. After policies are created, they can be applied to servers based on configuration.

Eliminating the Use of Domain Administrator Accounts for Services

When a server audit is completed, there should be sufficient information about the environment to identify and eliminate all possible instances of domain administrator accounts that are used for service authentication. Whenever possible, services should be redeployed using the Local Service, Network Service, or Local System accounts.

Efforts to correct usage of administrator equivalent accounts by services should be particularly focused on the following situations:

User accounts with administrator equivalent privileges that log on as a service.
Built-in administrator accounts that log on as a service.
Domain administrator accounts that log on as a service on low-security computers.

Using Least-Privilege Hierarchies for Service Deployment

As stated earlier in this document, services should always use the account with the least possible privileges required to run that service. Any services that have a greater level of privileges than required should be redeployed using accounts with lesser privileges.

A least-privilege hierarchy would consider accounts for service usage in the following order, from most preferred to least preferred:

Local Service
Network Service
Unique local user account
Unique domain user account
Local System
Local administrator account
Domain administrator account

Creating High-Security Server Groups for Exceptions

High-security servers are basically servers that hold resources or supply services that the business depends upon or pose an elevated security risk. Generally, servers that meet such criteria include:

Domain controllers.
Servers using services that must authenticate with a domain administrator account to run.
Servers trusted for delegation in a forest.
Servers used by sensitive business groups or that hold critical business data, such as a human resources server with salary information.
Servers that run services which have been trusted for delegation within a forest using constrained delegation in Windows Server 2003.

The creation of a high-security server group generally involves the following activities:

Identify servers that should be designated as high-security servers.
Create a High Security Servers universal security group in each forest.
Place the designated servers’ computer accounts into the new universal groups.
Create a Domain Admin Accounts local group in each domain.
Place all domain administrator equivalent user accounts into the new local group.
Create a Group Policy object in each domain that restricts the use of domain-level administrator accounts for services on all computers by assigning the Deny Log on as a service and Deny log on as a batch job user rights and applying the Allow-Read and Allow-Apply permissions on the GPO to the Domain Admin Accounts domain local group that was created.
Use Group Policy filtering for the High Security Servers group on each GPO so that members of that group are still allowed to use domain administrator accounts for services. This functionality can be accomplished by applying Allow-Read and Deny-Apply permissions on the GPO for the High Security Servers group.

The management of the High Security Servers group membership should use an internal workflow process that evaluates requests for additions to the group. This process should include steps that validate the requests and assess the associated security risks if a server is added to the group. The basis of this process can range from the simple, such as e-mail requests to a specified account, to a detailed automated process using any number of provisioning tools, such as Zero Touch Provisioning (ZTP).

ZTP is beyond the scope of this document because it is a tool geared towards larger enterprise environments. However, more information about ZTP and other similar tools is available on the Microsoft Desktop Deployment Center Web site at www.microsoft.com/technet/desktopdeployment/default.mspx.

Managing Service Account Password Changes

When accounts are assigned to a service, the Service Control Manager (SCM) requires the correct password for that account before it can make that assignment. If an incorrect password is supplied the assignment will be rejected by the SCM. Configuring services to use the Local System, Local Service, or Network Service accounts negates the need to manage account passwords because the operating system manages them instead.

For other service accounts, the SCM stores account passwords in the services database. After passwords are assigned, the SCM does not verify the passwords stored in that database and the password assigned to a user account in Active Directory will continue to match. This can cause problems when situations such as the following occur:

A service is configured to use a specific user account.
The service starts by using that account with the current password.
The password for that user account is changed while the service continues to run.
The service continues to run until it is stopped. After it is stopped, the service cannot restart because the SCM is still trying to use the old password. Password changes in Active Directory do not synchronize with passwords stored in the services database.

Any service that uses a standard domain or local user account must be updated with new authentication information every time that user account password is changed. This can take a significant amount of time and effort if services and the accounts they use are not properly documented.

Of course, the existence of a document that stored account information for all services used on all servers presents its own unique security risk—so steps should be taken to secure such a document. Larger organizations can record this information in an encrypted file, which is taken offline and stored in a secure location. Smaller organizations may simply record such information on paper in a binder that is locked in a safe or other secured location.

Some applications may also use service account passwords, such as Exchange Server or SQL Server™, so care should be taken to change relevant passwords at the application interface in such situations.

For information about how to write tools to automate the process of changing service account passwords, see the article "Changing the Password on a Service’s User Account" at https://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/changing\_the\_password\_on\_a\_serviceampaposs\_user\_account.asp.

Enforcing the Use of Strong Passwords

As mentioned in the corresponding section for administrator accounts, the use of strong password policies should be strictly enforced on all administrator equivalent accounts as well as all service accounts. To enforce such rules, Group Policy can be used to enforce password expiration dates, minimum length restrictions, and other strong password rules.

For more information about strong password policies, see the "Account Passwords and Policies" white paper at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/bpactlck.mspx

For more information about how to enforce the use of strong passwords, see the Windows Server 2003 Security Guide at https://go.microsoft.com/fwlink/?linkid=14845.

Weak passwords represent one of the most common vulnerabilities on a network, and when used with administrator equivalent accounts they are one of the easiest ways an attacker can gain access to network resources. The use of automated testing tools to detect administrator equivalent accounts that use weak passwords should be a regularly scheduled task for those responsible for the security or administration of a network.

To accomplish this task, the Microsoft Baseline Security Analyzer (MBSA) tool can scan every computer on the network in search of weak passwords. The MBSA can enumerate all user accounts and check for the following password-related vulnerabilities:

Blank passwords.
Passwords that match user account names.
Passwords that match computer names.
Passwords that use the word “password,” “admin,” or “administrator.”

When used, the MBSA will attempt to use each of the listed vulnerabilities to change an account’s password. When a weak password is discovered the password will not be changed, but the MBSA will report that password as being a security risk. The MBSA will also report any disabled accounts or accounts that are locked out.

Although the MBSA does detect the most common poor password practices, it does not provide full-featured password auditing capabilities. For these needs there are some third-party offline scanning tools and applications available on the market.

For more information about the MBSA or to download this tool, see the Microsoft Baseline Security Analyzer Web page at www.microsoft.com/technet/security/tools/mbsahome.mspx.

Note The MBSA will reset any account lockout policies detected on a computer to prevent locking any accounts during the scanning process. Also, the MBSA will not perform password scans on computers designated as domain controllers.

Summary

Obviously, a great number of steps can be taken to enhance the security of critical and service accounts in a midsize business network. Fundamentally, all of these approaches are based on a few key concepts, such as the establishment of well-documented processes and employing practices that follow the principle of least privilege. Simply understanding and using these few key concepts as a basis for account management will help greatly enhance the security of any network.

Any number of these best practice techniques described in this document can be used in a midsize business environment if they are deemed a suitable fit with business requirements. Although all of these practices combined would undoubtedly improve the security of any network, it is best to analyze the potential impact that each could have on a business network to determine the most compatible combination of approaches.

Appendix A: Common Services

The following table lists and describes the common Windows Server 2003 and Windows XP services in alphabetical order. Although this list includes both default services and services that can be added to a computer, it is not a complete list of all the possible services that could be installed on a computer because it does not include services that could be installed by third-party software packages.

Table A.1 Windows XP and Windows Server 2003 Service Descriptions

Service	Service name	Log on as	Description
6to4	IP Version 6 Helper Service	Local System	Enables IPv6 connectivity over IPv4 networks.
AELookupSvc	Application Experience Lookup Service		Processes application compatibility lookup requests for applications as they are started. Must be active for application compatibility software updates to occur.
Alerter	Alerter	Local Service	This service notifies selected users and computers of administrative alerts and relies on the Messenger service on client computers for delivery.
ALG	Application Layer Gateway Service	Local Service	Provides support for plug-ins that allow network protocols to pass through the firewall and work behind ICS.
AppMgmt	Application Management	Local System	Provides software installation services such as Assign, Publish, and Remove. If disabled, applications cannot be installed through Active Directory services, such as IntelliMirror®.
AppMgr	Remote Server Manager	Local System	Acts as a WMI instance provider for Remote Administration Alert Objects and a WMI method provider for Remote Administration Tasks.
aspnet_state	ASP.NET State Service	Network Service	Provides support for ASP.NET out-of-process session states.
AudioSrv	Windows Audio	Local System	Manages audio devices for Windows-based programs.
BINLSVC	Remote Installation	Local System	This is the primary component of the Remote Installation Server (RIS), which answers PXE requests for remote boot-enabled computers.
BITS	Background Intelligent Transfer Service	Network Service	Supplies a background file transfer mechanism for queue manager. When this service stops, the computer will not be able to use Automatic Update features.
Browser	Computer Browser	Local System	Maintains an up-to-date list of computers on the network.
CertSvc	Certificate Services	Local System	Part of the core operating system that issues and manages digital certificates.
cisvc	Indexing Service	Local System	Provides rapid access to files through a querying language by indexing the contents and properties of files.
ClipSrv	ClipBook	Local System	Enables the ClipBook viewer to create and share pages for data for review by remote users.
ClusSvc	Cluster Services	Domain Account	Controls server cluster operations and manages the cluster database.
COMSysApp	COM+ System Application	Local System	Manages the configuration and tracking of COM+ based components. COM+ components will not function correctly if this service is disabled.
CORRTSvc	.NET Framework Support Service		Notifies subscriber clients when specified processes initialize the Client Runtime Service.
CryptSvc	Cryptographic Services	Local System	Provides cryptographic key management services for Windows-based computers.
DcomLaunch	DCOM Server Process Launcher	Local System	Provides part of the RPC services that require Local System privileges in combination with the RPCSS service.
Dfs	Distributed File System	Local System	Integrates disparate file shares located across the network into a single logical namespace. Required to advertise the SYSVOL share.
DFSR	Distributed File System Replication		Automatically copies updates to files and folders between computers that are participating in a common replication group (added in Windows Server 2003 R2).
Dhcp	DHCP Client	Network Service	Manages DHCP network configuration information by registering and updating IP addresses.
DHCPServer	DHCP Server	Local System	This service manages DHCP and allocates IP addresses to client computers.
dmadmin	Logical Disk Manager Administrative Service	Local System	Performs administrative services for disk management requests and configures disks and volumes. This service only runs during such configuration processes.
dmserver	Logical Disk Manager	Local System	Detects and monitors new disk drives and sends volume information to the dmadmin service. Do not disable if dynamic disks are in use.
DNS	DNS Server	Local System	Enables DNS name resolution by answering queries and updating requests for DNS names.
Dnscache	DNS Client	Network Service	Resolves and caches DNS names and must run on any computer that performs DNS name resolution.
ERSvc	Error Reporting Service	Local System	Collects, stores, and reports on unexpected application errors or closures.
Eventlog	Event Log	Local System	Writes events sent by programs, services, and the operating system to event logs.
EventSystem	COM+ Event System	Local System	Provides automatic distribution of events to subscribing COM components.
FastUser Switching Compatibility	Fast User Switching Compatibility	Local System	Provides management for applications that require assistance in multiple user environments.
Fax	Fax Service	Local System	TAPI-compliant provider of fax capabilities.
Groveler	Single Instance Storage Groveler	Local System	An integral part of the Remote Installation Service (RIS) that finds duplicate files and copies the original into the Single Instance Storage.
helpsvc	Help and Support	Local System	Provides access to stores and services that contain metadata and information about help topics for the Help and Support Center application.
HidServ	Human Interface Device Access	Local System	Enables generic input access to USB devices such as keyboards and mice.
HTTPFilter	HTTP SSL	Local System	Enables IIS to perform SSL functions.
IAS	Internet Authentication Service	Local System	Performs centralized authentication, authorization, auditing, and accounting of users connecting to a network.
IASJet	IAS Jet Database Access	Local System	Provides authentication, authorization, and accounting services via the RADIUS protocol.
IISADMIN	IIS Admin Service		Allows administration of IIS components such as FTP and Web service extensions.
ImapiService	IMAPI CD-Burning COM Service	Local System	Manages the creation of CDs through the IMAPI COM interface and performs CD-R writes when requested.
Irmon	Infrared Monitor	Local System	Enables file sharing via infrared connections.
IsmServ	Intersite Messaging	Local System	Enables message exchanges between computers that run Windows Server.
kdc	Kerberos Key Distribution Center	Local System	Allows users to log on by using Kerberos authentication protocol. If this service is stopped, clients cannot log on to a domain.
lanmanserver	Server	Local System	Provides RPC support and file, print, and name pipe sharing over the network.
Lanman workstation	Workstation	Local System	Provides network connections and communications for client services.
LicenseService	License Logging	Network Service	Originally designed to manage CALs introduced with Windows NT® Server 3.51. Should only be enabled by users of Microsoft Small Business Server.
LMHosts	TCP/IP NetBIOS Helper Service	Local Service	Provides support for NetBIOS over TCP/IP and NetBIOS name resolution for clients.
LPDSVC	TCP/IP Print Server	Local System	Enables TCP/IP-based printing by using the LPD protocol for document reception from LPD utilities running on UNIX–based platforms.
LSASS	Local Security Authority	Local System	Provides an interface for managing local security, domain authentication, and Active Directory processes.
MacFile	File Server for Macintosh	Local System	Allows Macintosh users to store and access files on Windows Server 2003.
MacPrint	Print Server for Macintosh	Local System	Allows Macintosh users to use Windows Server 2003 print services.
MDM	Machine Debug Manager		Manages local and remote debugging for applications.
Messenger	Messenger	Local System	Sends messages to or receives messages from the Alerter service. This is not related to Windows Messenger and if disabled will prevent use of the net send and net name commands.
mnmsrvc	NetMeeting Remote Desktop Sharing	Local System	Allows authorized users remote access to the Windows Desktop from other computers via Windows NetMeeting® services.
mqds	Message Queuing Down Level Clients	Local System	Provides Active Directory access for older versions of Windows that use Message Queuing service.
Mqtgsvc	Message Queuing Triggers	Local System	Provides a rule-based system to monitor messages that arrive in a Message Queuing service queue and invokes message processing services.
MSDTC	Distributed Transaction Coordinator	Network Service	Coordinates transactions distributed across multiple computers, databases, file systems, message queues, and other transaction-protected resource managers.
MSExchange MTA	Microsoft Exchange MTA Stacks		Provides backward-compatible message transfer service in a mixed-mode environment.
MSFTPSVC	FTP Publishing Service	Network Service	Provides FTP connectivity and administration through the IIS snap-in.
MSIServer	Windows Installer	Local System	Manages the installation and removal of applications by applying sets of centrally defined setup rules during installation processes.
msmq	Message Queuing	Local System	Acts as a messaging infrastructure and development tool that enables distributed messaging for Windows programs.
MSSQL$UDDI	MSSQL$UDDI	Network Service	Provides Universal Description, Discovery, and Integration (UDDI) services to the SQL Server database engine.
MSSQL SERVER	MS SQL Server		Provides configurable MS SQL Server services.
MSSQLServer ADHelper	MS SQL Server AD Helper	Local System	Enables SQL Server and SQL Server Analysis Services to publish information in Active Directory.
NetDDE	Network DDE	Local System	Provides network transport and security for DDE for programs that run on the same computer or different computers.
NetDDEdsdm	Network DDE DSDM	Local System	Manages DDE network shares.
Netlogon	Netlogon	Local System	Maintains a security channel between client computers and domain controllers for service and user authentication.
Netman	Network Connections	Local System	Manages objects in the Network Connections folder.
Network Connections	Network Connections	Local System	Manages objects in the Network and Dial-up Connections folder, from which viewing network and remote connections is possible.
NLA	Network Location Awareness	Local System	Collects and stores network configuration information and processes location change information.
NntpSvc	Network News Transfer Protocol	Local System	Allows computers to act as NNTP news servers.
NtFrs	File Replication	Local System	Automatically copies updates to files and folders between computers participating in a common FRS replica set.
NtLmSsp	NTLM Security Support Provider	Local System	Responsible for authentication and management of local security policy objects.
NWC Workstation	Client Service for NetWare	Local Service	Provides access to NetWare file and print resources.
nwsapagent	SAP Agent	Local System	Advertises network services on IPX networks using the IPX SAP protocol.
one point	Microsoft Operations Manager 2000 Agent		Microsoft Operations Manager (MOM) 2000 agent.
PlugPlay	Plug and Play	Local System	Enables recognition of hardware changes without user input.
PolicyAgent	IPsec Service	Local System	Manages IPsec policy, starts IKE, and coordinates IPsec policy settings in the IP security driver.
POP3SVC	Microsoft POP3 Service	Local Service	Provides e-mail transfer and retrieval services.
Protected Storage	Protected Storage	Local System	Provides protected storage for sensitive data.
RasAuto	Remote Access Auto Connection Manager	Local System	Creates connections to remote computers whenever programs reference remote DNS or NetBIOS names or addresses.
RasMan	Remote Access Connection Manager	Local System	Manages dial-up and VPN connections to remote networks.
RDSessMgr	Remote Desktop Help Session Manager	Local System	Manages and controls the Remote Assistance feature within the Help and Support Center application.
Remote_ Storage_Server	Remote Storage Server	Local System	Moves and retrieves files from secondary storage media.
Remote_ Storage_User_ Link	Remote Storage Notification		Remote_Storage_User_Link service notifies users when they attempt to read or write files that are only available from secondary storage media sources.
RemoteAccess	Routing and Remote Access	Local System	Provides multiprotocol routing services and provides dial-up and VPN remote access services.
RemoteRegistry	Remote Registry Service	Local Service	Enables remote users to modify registry settings with proper permissions.
RpcLocator	Remote Procedure Call Locator	Network Service	Manages the RPC name service database so RPC clients can locate RPC servers. Disabled by default.
RpcSs	Remote Procedure Call	Local System	Serves as the RPC endpoint mapper and Component Object Model (COM) Service
RSoPProv	Resultant Set of Policy Provider	Local System	Enables connections to Windows domain controllers, access to the WMI database, and simulates RSoP for Group Policy settings.
RSVP	QoS RSVP	Local System	Manages the use of Generic Quality of Service API requests from applications.
Sacsvr	Special Administration Console Helper	Local System	Performs remote management tasks when a Windows Server family operating system stops functioning due to Stop error messages.
SamSs	Security Accounts Manager	Local System	Manages user and group account information.
SCardSvr	Smart Card	Local Service	Manages and controls access to smart cards when inserted into a smart card reader attached to the computer.
Schedule	Task Scheduler	Local System	Allows the performance of automated tasks.
seclogon	Secondary Logon	Local System	Allows the creation of processes in the context of different security principals.
SENS	System Event Notification	Local System	Tracks system and power events and notifies COM+ Event System subscribers of these events.
SharedAccess	Windows Connection Firewall/Internet Connection Sharing	Local System	Provides NAT, addressing, and name resolution services for all computers in a network when Internet Connection Sharing is enabled.
ShellHW Detection	Shell Hardware Detection	Local System	Provides notifications for AutoPlay hardware events.
SimpTcp	Simple TCP/IP Services	Network Service	Provides simple TCP/IP services such as Echo, Discard, Daytime, Character Generator, and Quote of the Day.
SMTPSVC	Simple Mail Transport Protocol	Local System	Acts as an SMTP submission and relay agent by accepting and queuing e-mail to and from remote destinations.
SNMP	SNMP Service	Local System	Allows incoming SNMP requests to be serviced by the local computer.
SNMPTRAP	SNMP Trap Service	Local Service	Receives SNMP Trap messages generated by local or remote SNMP agents and then forwards those messages to SNMP management servers.
Spooler	Print Spooler	Local System	Manages all local and network print queues and controls all print jobs.
SQLAgent$ WEBDB	SQL Agent$ UDDI or WebDB
SrvcSurg	Remote Administration Service	Local System	Responsible for running Remote Administration tasks on server boot up, including incrementing the server boot count and raising alerts if server date and time have not be set.
StiSvc	Windows Image Acquisition	Local Service	Provides image acquisition services for scanners and cameras.
srservice	System Restore Service	Local System	Monitors changes to the system and application files then creates easily identifiable restore points.
SSDPSRV	SSDP Discovery Service	Local Service	Manages device presence announcements, cache updates, and SSDP notifications.
StiSvc	Windows Image Acquisition (WIA)	Local Service	Provides robust communication between applications and image-capture devices for the efficient transfer of images to the computer.
SwPrv	Microsoft Software Shadow Copy Provider	Local System	Manages software-based shadow copies that are taken by the VSS service.
SysmonLog	Performance Logs and Alerts	Network Service	Collects performance log and alert information, only runs when at least one performance data collection event is scheduled.
TapiSrv	Telephony	Local System	Provides TAPI support for programs that control telephony devices and IP-based voice connections.
TermService	Terminal Services	Local System	Allows multiple client access to virtual Windows desktop sessions running on the server.
TermServ Licensing	Terminal Services Licensing		Provides licenses to registered clients when they connect to a terminal server and tracks those licenses.
tftpd	Trivial FTP Daemon		Listens and responds to TFTP requests.
Themes	Themes	Local System	Provides rendering support for the Windows XP graphic user interface (GUI).
TlntSvr	Telnet	Local System	Provides Telnet services to Windows users and supports ANSI, VT-100, VT52, and VTNT terminal session types.
TrkSvr	Distributed Link Tracking Server	Local System	Stores information so that files moved between volumes can be tracked to each volume in the domain. Runs on each domain controller.
TrkWks	Distributed Link Tracking Client	Local System	Maintains links between the NTFS file system files on the computer or across the network and ensures that shortcuts and OLE links work after target files are moved or renamed.
Tssdis	Terminal Services Session Directory	Local System	Keeps track of disconnected terminal services sessions on a cluster to ensure that users are reconnected to those sessions.
Uploadmgr	Upload Manager	Local System	Manages the synchronous and asynchronous file transfers between clients and servers on the network.
upnphost	Universal Plug and Play Device Host	Local System	Implements all components required for device registration, control, and the response to events for hosted devices.
UPS	Uninterruptible Power Supply	Local Service	Manages communications with an Uninterruptible Power Supply (UPS) connected to the computer via serial port.
VDS	Virtual Disk Service	Local System	Provides a single interface for managing block storage virtualization whether done in OS software, RAID storage, or other virtualization engines.
VSS	Volume Shadow Copy	Local System	Manages volume snapshots used by backup applications.
W32Time	Windows Time	Local System	Maintains date and time synchronization with NTP.
W3SVC	World Wide Web Publishing Service	Local System	Contains a process and configuration manager to provide Web publishing services.
WebClient	WebClient	Local Service	Allows Win32 applications to access documents on the Internet.
WindowsSystem Resource Manager	Windows System Resource Manager	Local System	Provides policy based management of CPU and memory consumption for processes running on a single operating system instance.
WinHttpAutoSvc	WinHTTP Web Proxy Auto-Discovery Service	Local Service	Implements proxy configuration discovery for WinHttp clients.
winmgmt	Windows Management Instrumentation	Local System	Provides system management information through multiple interfaces.
WINS	Windows Internet Name Service	Local System	Enables NetBIOS name resolution and WINS replication.
WmdmPmSN	Portable Media Serial Number	Local System	Allows the WMDM to retrieve serial numbers from portable music devices attached to the computer.
Wmi	Windows Management Instrumentation Driver Extensions	Local System	Monitors all drivers and event trace providers that are configured to publish WMI or event trace information.
WmiApSrv	WMI Performance Adapter	Local System	Transforms performance counters supplied by WMI providers into counters that can be consumed by PDH through the Reverse Adapter Performance Library.
WMServer	Windows Media Services	Network Service	Enables Windows Media Services.
wscsvc	Security Center	Local System	Monitors system security settings and configurations.
wuauserv	Automatic Updates	Local System	Enables the download of updates from the Microsoft Windows Update Web Site.
Wuser32	SMS Remote Control Agent	Local System	Provides remote computer management services, such as remote control and remote file transfer services, for SMS 2003.
WZCSVC	Wireless Zero Configuration	Local System	Enables automatic configuration for IEEE 802.11 wireless adapters for wireless communications.
xmlprov	Network Provisioning Service	Local System	Provides the ability to download and manage XML configuration files from network provisioning services such as the Microsoft Wireless Provisioning Service (WPS).

Download

Get the Securing Critical and Service Accounts guide

Securing Critical and Service Accounts

On This Page

Introduction

Executive Summary

Overview

Who Should Read This Document

Definition

Challenges

Solutions

Assessment

Administrator and Critical Account Management

Administrative Accounts and Groups

Service Administrators and Data Administrators

Service and Application Account Management

Service Account Vulnerability Scenarios

System Accounts

Default Security Settings for Windows Server 2003 Services

Development

Administrator and Critical Account Management

Understanding and Documenting the Environment

Using the Principle of Least Privilege

Using the Least-Privileged User Account Approach

Service Account Management

Understanding and Documenting the Environment

Following the Principle of Least Privilege

Following the Principle of Least Service

Deployment and Management

Administrator and Critical Account Management

Separating Domain Administrator and Enterprise Administrator Roles

Separating User and Administrator Accounts

Using the Secondary Logon Service

Running Separate Terminal Services Sessions for Administration

Renaming the Default Administrator Accounts

Creating Decoy Administrator Accounts

Creating Secondary Administrator Accounts and Disabling Built-in Accounts

Enabling Account Lockout for Remote Administrator Logons

Creating Strong Administrator Passwords

Detecting Weak Passwords Automatically

Restricting Administrative Tasks to Trusted Computers

Auditing Accounts and Passwords

Prohibiting Account Delegation

Enforce Multi-Factor Authentication for Administrator Accounts

Service and Application Account Management

Auditing Services for Essential Properties

Determining Which Services are Necessary

Using the Security Configuration Wizard

Eliminating the Use of Domain Administrator Accounts for Services

Using Least-Privilege Hierarchies for Service Deployment

Creating High-Security Server Groups for Exceptions

Managing Service Account Password Changes

Enforcing the Use of Strong Passwords

Summary

Appendix A: Common Services

Additional resources