On This Page
Introduction
Definition
Challenges
Solutions
Summary
Appendix A: Common Services
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.
Top Of Page
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.”
Top Of Page
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.
Top Of Page
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 http://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 http://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 http://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 http://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 http://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:
-
Other enterprise management tools. There are several other management tools that can be used to assist with the auditing of server services, including:
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 http://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 http://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 http://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.
Top Of Page
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.
Top Of Page
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).
Top Of Page
Download
Get the Securing Critical and Service Accounts guide
Source: Securing Critical and Service Accounts
Back to the top
![clip_image001[1]](http://gunnalag.files.wordpress.com/2011/12/clip_image001198.gif "clip_image001[1]"){kind=small}
![clip_image001[6]](http://gunnalag.files.wordpress.com/2011/12/clip_image001611.gif "clip_image001[6]"){kind=small}
![clip_image001[7]](http://gunnalag.files.wordpress.com/2011/12/clip_image001711.gif "clip_image001[7]"){kind=small}
![clip_image001[8]](http://gunnalag.files.wordpress.com/2011/12/clip_image001811.gif "clip_image001[8]"){kind=small}
![clip_image001[9]](http://gunnalag.files.wordpress.com/2011/12/clip_image001910.gif "clip_image001[9]"){kind=small}
![clip_image001[10]](http://gunnalag.files.wordpress.com/2011/12/clip_image0011010.gif "clip_image001[10]"){kind=small}
![clip_image001[11]](http://gunnalag.files.wordpress.com/2011/12/clip_image0011110.gif "clip_image001[11]"){kind=small}
![clip_image001[12]](http://gunnalag.files.wordpress.com/2011/12/clip_image0011211.gif "clip_image001[12]"){kind=small}
![clip_image001[13]](http://gunnalag.files.wordpress.com/2011/12/clip_image0011311.gif "clip_image001[13]"){kind=small}
![clip_image001[14]](http://gunnalag.files.wordpress.com/2011/12/clip_image0011411.gif "clip_image001[14]"){kind=small}
![clip_image001[15]](http://gunnalag.files.wordpress.com/2011/12/clip_image0011511.gif "clip_image001[15]"){kind=small}
