TechNet Home > TechNet Security > Guidance > Server Security

Services and Service Accounts Security Planning Guide

Chapter 3 - How To Run Services More Securely

Updated: June 30, 2005

Using the approaches and principles discussed in the previous chapters of this guide,this chapter describes the tasks you must perform when planning to run services more securely.

To secure services, you should carry out the following tasks:

•

Audit all servers to determine essential service properties.

•

Determine which services actually need to run.

•

Identify and eliminate all domain administrator accounts for services.

•

Use a least-privilege hierarchy for service deployment.

•

Create a high security servers group for domain administrator exceptions.

•

Manage service account password changes.

•

Enforce strong passwords.

•

Automate testing for weak administrator passwords.

On This Page
Audit All Servers to Determine Essential Service PropertiesAudit All Servers to Determine Essential Service Properties
Determine Which Services Actually Need to RunDetermine Which Services Actually Need to Run
Identify and Eliminate All Domain Administrator Accounts for ServicesIdentify and Eliminate All Domain Administrator Accounts for Services
Use a Least-Privilege Hierarchy for Service DeploymentUse a Least-Privilege Hierarchy for Service Deployment
Create a High Security Servers Group for Domain Administrator ExceptionsCreate a High Security Servers Group for Domain Administrator Exceptions
Manage Service Account Password ChangesManage Service Account Password Changes
Enforce Strong PasswordsEnforce Strong Passwords
Automate Testing for Weak Administrator PasswordsAutomate Testing for Weak Administrator Passwords

Audit All Servers to Determine Essential Service Properties

You must determine exactly how many servers exist within your organization. Although this task sounds simple, a large organization can find it surprisingly complex to identify every server it possesses and to determine to what degree the services on each computer require management. For example, computers that run in the perimeter network require significantly higher levels of service management to reduce the attack surface of these computers.

You should audit each server to list all the running services and record which logon credentials each service uses for authentication. You can use the following tools to help with this task:

•

System Information in Microsoft® Windows Server™ 2003. You can use System Information to view a comprehensive list of the properties of all the services of the local computer or other remote computers. However, this method is not scalable to situations in which you need to audit large numbers of servers. To access this tool, click Start, point to All Programs, point to Accessories, point to System Tools, and then click System Information.

•

Services management console. In the Services administration console, you can use the Log On tab of a service's properties page to find which account the service uses to log on for authentication purposes. You can also use the Dependencies tab to view the services upon which the current service depends and which services depend upon it. Dependency data is essential information to gather when you audit servers. This method, however, is not scalable to situations in which you need to audit large numbers of servers.

•

Windows Management Instrumentation (WMI).Use WMI to obtain information about the services that run on all your servers. You can use WMI with programming tools or script utilities, such as Windows Scripting Host, to retrieve configuration details about most aspects of your computers or to make changes to your computers. Several management tools are WMI-enabled, such as System Properties, System Information, and the Dependencies component of Services. Service dependencies identify the services upon which the current service depends and the services that depend upon it.

•

Windows Management Instrumentation command line (WMIC).WMI provides a simple command-line tool interface to WMI to manage remote computers that run Windows operating systems. WMIC interoperates with existing shells and utility commands, and you can easily extend it with scripts or other administration-oriented applications.

For example, you can use the wmic service get command to obtain information about all properties for a specified service including its:

•

Description

•

DisplayName

•

ErrorControl

•

InstallDate

•

PathName

•

ProcessId

•

StartMode

•

StartName

•

Status

Example syntax:

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line. 

SERVICE GET Name,DisplayName,ProcessId,Started,
StartMode,StartName

You can use the wmic service list brief command to retrieve a list of basic properties of all services installed as follows:

•

ExitCode

•

Name

•

ProcessId

•

StartMode

•

State

•

Status

You can use WMIC from any computer that has WMIC installed to manage any remote computer that runs WMI. The target computer does not need to have WMIC installed or running for WMIC to manage it remotely. To manage a computer remotely, you need to use the /node:<computername> command, which requests the computer to add to the list of nodes from which you want to retrieve information.

Example syntax:

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line. 

WMIC /NODE:Server1,Server2,Server3 SERVICE GET
Name,DisplayName,ProcessId,Started,StartMode,
SystemName

You can also provide the location of a text file that lists remote computers on which you want use WMIC to perform actions.

Example syntax: 

WMIC /NODE:@"C:\MyServerList.txt" SERVICE LIST BRIEF

You can use WMIC to ease tasks in the following typical scenarios:

•

Local management of a computer. You are at the computer and use the WMIC command to manage it.

•

Remote management of a computer. You are at one computer and use WMIC to manage another computer.

•

Remote management of multiple computers. You are at one computer and use WMIC to manage multiple computers with a single command.

•

Remote management of a computer using a remote session. You use remote session technologies such as Telnet or Terminal Services to connect to a remote computer and manage it with WMIC.

•

Automated management using administrative scripting.You can use WMIC to write a simple management script to automate the management of a computer (local, remote, or multiple computers—serially or simultaneously).

For more information about WMI, see the WMI: Introduction to Windows Management Instrumentation topic at http://www.microsoft.com/whdc/system/pnppwr/wmi/WMI-intro.mspx.

•

Other enterprise management tools. Several other management tools are available to help audit, including:

•

Microsoft Systems Management Server

•

Tivoli

•

OpenView

•

Lieberman Software Service Account Manager

Creating a master list of servers and their services helps to identify and remedy service-related security risks.

You can use your audit to create inventories of all services that use:

•

A domain user account with domain administrator privileges.

•

A single domain user account used on more than one server.

Determine Which Services Actually Need to Run

When you first install Windows Server 2003, the operating system creates several default services and configures them to run when the computer starts. The Microsoft Excel workbook "Windows Default Security and Services Configuration," included as part of the Threats and Countermeasures Guide, documents the default startup-type settings for all system services.

These default services provide application or client compatibility, or facilitate systems management. However, you probably do not need all of these services in your organization's environment, and you should carefully evaluate which ones you require.

Defining which services are required and which you should disable can be a complicated process. There are some services that you should obviously turn off, but the decisions to turn off other services are not so clear. The basic strategy that you should use is:

•

If you do not have a specific reason to use a given service, disable it.

•

If you think you might need to use the service in the future, disable it until you need it.

The services that you need to run on a computer depend largely on that computer's role. For example, you should only install Internet Information Services (IIS) on a Web server or a computer that requires IIS, such as an application server. If the server does not host remote access services or Telnet sessions, you should disable or remove these services. There are several situations in which software, such as systems management tools, add their own services to those that run on your computers. It is important you are aware of these services, the accounts they use to log on, and the level of access they require.

Microsoft has published several guides on how to lock down computers based on their roles. These guides explain which services you need for specific roles such as domain controllers, Web servers, Windows XP clients, and so on, and they are available at the following locations:

•

Windows Server 2003 Security Guide at http://go.microsoft.com/fwlink/?linkid=14845

•

Windows XP Security Guide at http://go.microsoft.com/fwlink/?LinkId=14839

•

Windows 2000 Security Hardening Guide at http://go.microsoft.com/fwlink/?LinkID=22380

•

Service overview and network port requirements for the Windows Server system at http://support.microsoft.com/?kbid=832017

In a test or pre-production environment, if you want to determine if you need a service, you can turn it off and then monitor the computer over time to see if anything fails to work. You should be aware, however, that there are a few core services that the Services console will not allow you to stop or even modify the startup type of, such as the Remote Procedure Call (RPC) service, and the Plug and Play service. There are also some services that the Services console will not allow you to stop, but will allow you to change the startup type of, such as the Event Log service and the Security Accounts Manager service.

If you are not sure what a particular service does, use one or more of the following methods to get more information:

•

See the more detailed service descriptions in Chapter 7, "System Services," of The Threats and Countermeasures Guide, which you can download at http://go.microsoft.com/fwlink/?LinkId=15160.

•

Read the service description. To access the description, open the Services console, locate the service of interest, right-click the name of the service, and then click Properties.

•

Use the Security Configuration Wizard to get a service description.

The Security Configuration Wizard provided with Windows Server 2003 with Service Pack 1 (SP1) can be a great help when you analyze which services you need to run.

Reduce the Attack Surface with the Security Configuration Wizard

The Security Configuration Wizard (SCW) allows you to quickly and easily configure servers running Microsoft Windows based on your functional requirements — Web server, domain controller, or other—while you author security policies to minimize attack vulnerability. To install SCW, open Control Panel, double-click Add or Remove Programs, click Add/Remove Windows Components, on the Windows Components page, under Components, select the Security Configuration Wizard check box and then click Next, and when the wizard completes, click Finish. This process adds a Security Configuration Wizard shortcut to your Administrative Tools folder.

The Security Configuration Wizard can help you discover what services your organization's servers are currently running and their dependency on other services. It can also be a useful job aid when you try to determine what services are required when you deploy new servers. You can deploy SCW-generated policies using Group Policy, which allows you to deploy specific server roles to several similar computers at once within an organizational unit (OU) or OU hierarchy.

The term server role defines the main functions that a computer performs in your organization. Examples of server roles include: file server, domain controller, and Web server roles. Because the required services, inbound ports, and settings vary for each role, the SCW policies you create should match the role that you want each computer to perform.

You can use the SCW to help reduce the attack surface of computers that run Windows Server 2003 with SP1. The wizard guides you through the process of how to create a security policy based on the roles performed by a given server. After you create a policy, you can apply it to one or more similarly configured servers.

The SCW consists of the following sections:

•

Role-Based Service Configuration

•

Network Security

•

Registry Settings

•

Audit Policy

•

Internet Information Services (only visible when Web Server role is selected)

For the purposes of this guide, the Role-Based Service Configuration section of the wizard is the only relevant section. You use this part of the wizard to configure services based on the selected server's roles and other features.

You base the security policy that you create on the roles installed on the selected server. The selected server can be the one to which you want to apply the policy, or you can use the selected server as a means of creating the policy, and then apply the policy to a group of servers that have similar roles.

How the Security Configuration Wizard Works

The SCW reduces the attack surface of servers that run Windows by asking the user a series of questions designed to determine the functional requirements of a server. It then disables the functionality that is not required by the roles performed by the server. In addition to being a fundamental security best practice, attack surface reduction increases the diversity of your Windows environment and reduces the number of computers that you must update immediately when vulnerabilities are exposed.

The SCW answers the most commonly asked question about Windows Server 2003: Which services can you turn off?

To date, this question has been difficult to answer because of the thousands of possible combinations of installed technologies, each with a hierarchy of dependencies that can exist on any Windows-based computer. When you add other servers, such as Microsoft Exchange Server or SQL Server™, the dependencies change yet again. The SCW addresses this problem and gives administrators a way to configure servers to run only those services required by the roles assigned to a server. The SCW achieves this by accessing an Extensible Markup Language (XML) database that contains the necessary data about Windows Server 2003 and the Microsoft products that run on Windows Server 2003.

Benefits of the Security Configuration Wizard

When you use the SCW to choose functional roles, you automatically:

•

Disable unnecessary services.

•

Disable unnecessary IIS Web extensions.

•

Block unused ports.

Limitations of the Security Configuration Wizard

Although the SCW does not lock down security settings such as LM authentication level and Server Message Block (SMB) signing, the Windows Server 2003 and Windows XP security guides listed earlier in this section discuss and provide recommendations for these settings.

Identify and Eliminate All Domain Administrator Accounts for Services

With information from the server audit, you can identify and eliminate all possible domain administrator accounts used for services. To eliminate as many instances as possible of services that use domain administrator accounts provides a significant first step toward service security. Whenever possible, you should redeploy the services using the Local Service, Network Service, or Local System accounts, as described in the following section of this chapter.

Organizations should try to eliminate service deployments that include:

•

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 servers.

Use a Least-Privilege Hierarchy for Service Deployment

You should use the account that has the least privilege required to run a service. Services deployed using accounts that have higher privileges should be redeployed using accounts that have lesser privileges.

A least-privilege hierarchy should use accounts in the following order:

1.

Local Service. This account is similar to Local System, although it has minimum privileges on the local computer. Services that log on as Local Service access network resources using a null session with anonymous credentials. The account's privileges must be limited to only those that are required for the successful operation of the service.

2.

Network Service. This account is similar to Local System, although it has minimum privileges on the local computer. Services that log on as Network Service access network resources using the credentials of the computer account (where the computer is referenced as <domain_name\computer_name>$). The account's privileges must be limited to only those that are required for the successful operation of the service.

3.

Unique user account. A service should run as a unique user account only if it is impractical to run it as Local Service or Network Service. You should use a unique local user account to run services that only require privileges on the local computer, such as IIS and SQL Server. However, applications that must run on distributed computers, as is the case with distributed applications such as Systems Management Server and Microsoft Operations Manager, will need to use a unique domain user account. A unique domain user account will also be required for any applications that require access to network resources. You should use a separate unique domain user account for each application that requires it. For example, if you run multiple ASP.NET applications, you should make sure each application uses its own unique user account. Unique user account privileges must be limited to only those required for the successful operation of the service. You can assign additional administrative privileges to the unique account for which the service is configured, but only if necessary. You should also limit the unique account's group membership to those groups that are required. Unique user accounts should conform to an organizational policy for secure password use. If multiple computers use the same service or related services, the passwords across each unique user account should also be required to be unique.

4.

Local System. Keep in mind that services that log on as Local System have extensive privileges on the local computer and present computer credentials on the network (referenced as <domain_name\computer_name>$). The account's privileges must be limited to those that are required for the successful operation of the service only.

5.

Local administrator account. You should run a service as a local administrator account only if it is impractical to run it as Local Service, Network Service, a unique domain user account or the Local System account. To demote a service that runs as a local administrator, you can sometimes use a local user account and add specific required privileges or change system access control list (SACL) entries. It is far better to use one of these approaches than to use a third-party service that has unknown vulnerabilities running as administrator on the computer. You should also let your software vendors know the importance of least privileged services in your environment by making them a core part of your evaluation and purchasing processes. Furthermore, you should not let software vendors get indolent about running their service as the administrator account. You should provide guidance to the vendor on what resources the service actually requires access to and what permission levels it requires. You should assign the account local administrator privileges only on the computer on which the service is configured, and only if necessary. The local administrator account should conform to an organizational policy for secure password use. If multiple computers use the same service or related services, the passwords across each local administrator account should also be required to be unique.

6.

Domain administrator account. Running a service with a domain administrator account is a worst-case security scenario. Organizations should work to eliminate all such situations. If you use this approach, you must manage all computers in this scenario as high security servers and protect them in the same way as your domain controllers or other high-value network assets. Subsequent sections discuss high security servers in more detail.

The flowchart in the following figure shows the points to consider when you decide which account type to use to run your services securely.

Figure 3.1 Least-privilege hierarchy for service deployment

Figure 3.1 Least-privilege hierarchy for service deployment
See full-sized image

Create a High Security Servers Group for Domain Administrator Exceptions

If you determine that a service must run with domain administrator-level authentication, you should only host that service on a high security server. High security servers typically include:

•

Domain controllers.

•

Servers that run services configured to log on as an account that has domain administrator – equivalent privileges.

•

Servers that have been trusted for delegation within a forest.

•

Servers that run services that have been trusted for delegation within a forest, using Constrained Delegation in Windows Server 2003. For more information about this feature, see Kerberos Protocol Transition and Constrained Delegation at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/constdel.mspx.

The major steps involved in creating a high security servers group are:

1.

Decide which servers to designate as high security servers.

2.

Create a universal security group in each forest in your enterprise called, for example, High Security Servers.

3.

Add the designated secure servers' computer accounts to the new universal groups.

4.

In each domain in each forest, create a domain local group called, for example, All Domain Admin Accounts, and then add the domain administrator – equivalent user accounts to this new group.

5.

In each domain in each forest, create a domain-level Group Policy object (GPO), and set the policy to restrict the use of domain-level administrator accounts for services on all computers. Set the policy to Deny log on as a service and Deny log on as a batch job user rights, and then apply Allow-Read and Allow-Applypermissions on the GPO to the All Domain Admin Accounts domain local group that you just created.

6.

In each domain in each forest, use Group Policy filtering for the High Security Servers group on each GPO so that members of this group are still allowed to use domain-level administrator accounts for services. This is done by applying Allow-Read and Deny-Apply permissions on the GPO for the High Security Servers universal group only.

To manage the membership of the High Security Servers universal group successfully, establish an internal workflow process to request additions to the group. This process should include steps to validate the request and assess the associated security risks if you add the requested server to the group. The workflow process could be as simple as sending e-mail to a request alias, but ideally it should be an automated procedure. The Solution Accelerator for Business Desktop Deployment Enterprise Edition includes a Zero Touch Provisioning (ZTP) component, which provides an automated procedure for this process.

For more information, see the following guides:

•

Zero Touch Provisioning Deployment Feature Team Guide at http://www.microsoft.com/technet/itsolutions/cits/dsd/enterprise/ZTPDFTGuide_1.mspx

•

Zero Touch Provisioning Developer Guide at http://www.microsoft.com/technet/itsolutions/cits/dsd/enterprise/zertpd_1.mspx

•

Zero Touch Provisioning End-User Guide at http://www.microsoft.com/technet/itsolutions/cits/dsd/enterprise/ZTPEUGiude_1.mspx

Manage Service Account Password Changes

When you assign an account to a service, the Service Control Manager (SCM) requires the correct password for that account before it makes the assignment. If you supply an incorrect password, the SCM rejects the account.

If you configure a service account to use the Local System, Local Service, or Network Service account, you do not need to manage the service account's password because the operating system will manage it instead. Consequently, there is no password management required for these service accounts.

For other service accounts, the SCM stores the account password in the services database. After it assigns the password, the SCM does not verify that the password stored in the services database and the password assigned to the user account in the Active Directory® directory service continue to match. Consequently, a situation similar to the following could occur:

1.

You configure a service to run under a particular user account.

2.

The service starts up under that account using the current account password.

3.

You change the password for the user account.

4.

The service continues to run. However, if the service stops, you cannot restart it because the SCM continues to use the old, invalid password. This is because the change to the password in Active Directory does not change the password stored in the services database.

If you run services under standard domain or local user accounts, you must update those service passwords each time the user account password changes. This can take a significant amount of time if you are not sure which services run under that account, or which computers have services that run under that account. You should securely document the use of these types of service accounts and their passwords. For a large organization, this might mean they need to take an encrypted data file offline and then store it in a secure vault, but for a smaller organization perhaps a document stored in a locked drawer or safe might be more appropriate.

Important: If you use the Active Directory Users and Computers or the Local Users and Groups consoles to change a service account password for an application such as Exchange Server or SQL Server, you must also change the password within the application interface.

Note: For more information about how to write a tool that automates the task of updating service account passwords, see Changing the Password on a Service's User Account at http://msdn2.microsoft.com/en-us/library/ms675577.

Enforce Strong Passwords

You should require that your organization's network administrators enforce the use of strong passwords. They should use password policies in Group Policy to alert users to change their passwords after a defined period. A strong password should be a minimum of 10 characters (ideally 15 or more) and should include a combination of upper and lower case letters, numbers, and symbols. In Windows 2000 Server and Windows Server 2003, you can use Group Policy to enforce the use of strong passwords. For more information, see Accounts Passwords and Policies at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/bpactlck.mspx, and the Windows Server 2003 Security Guide at http://go.microsoft.com/fwlink/?linkid=14845.

Automate Testing for Weak Administrator Passwords

You should require that your organization's network administrators regularly use automated testing tools to detect servers deployed with weak passwords for their local administrator accounts. The test should try to guess the password for the built-in local administrator account that exists on every Windows-based computer.

Weak passwords represent one of the most common vulnerabilities on a network, and are one of the easiest ways for an intruder to gain administrator access to the computer and compromise any stored service account credentials.

Using the Microsoft Baseline Security Analyzer

You can use the Microsoft Baseline Security Analyzer (MBSA) tool to scan every computer on the network and look for weak passwords. For more information about MBSA, and to download the tool, see the Microsoft Baseline Security Analyzer V1.2.1 site at http://www.microsoft.com/technet/security/tools/mbsahome.mspx.

The MBSA tool enumerates all user accounts and checks for the following password vulnerabilities:

•

Password is blank.

•

Password is the same as the user account name.

•

Password is the same as the computer name.

•

Password uses the word "password."

•

Password uses the word "admin" or "administrator."

The MBSA check also notifies you of any disabled accounts or accounts that are currently locked out.

MBSA will use each of the listed passwords to try to change the password on the target computer. If this operation succeeds, MBSA indicates the account that uses that password. Although MBSA does not reset or change the password permanently, it does report if the password is simple and represents a security risk.

You should note that although MBSA can help find some instances of common poor passwords in use, it does not provide full-featured password auditing and recovery capabilities, such as are available with some third-party offline scanning tools and applications available on the market.

Note: MBSA resets any account lockout policies detected on the computer so that no individual user accounts are locked out during this password check routine. MBSA does not perform these password checks on computers configured as domain controllers.


**
**

Download

Get the Services and Service Accounts Security Planning Guide

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions