S 4.284 Handling of services under Windows Server 2003 and higher

Initiation responsibility: Head of IT

Implementation responsibility: Administrator

Under Windows, services are executed in the security context of certain accounts (referred to as service accounts). Resources are accessed through the service account in the same manner as a user accesses resources through his user account. Once a service is started, it remains active, which means the corresponding service is logged in to the service account permanently or the central service controller logs the service in again at regular intervals. The services on servers are usually central services that are critical to operation. Service accounts are therefore subject to more risks than normal user accounts. If there are any dependencies between the services, then a compromised, apparently unimportant service can cause a service that is critical to operation to crash. For these reasons, services and service accounts should be administered according to special rules.

• The predefined administrator account should never be used as a service account.
• Every service should run in its own service account.

A compromised service account with high level of authorisation is easier to isolate when it is not used to run several services. In practice, server applications may operate a group of services in the context of a single account. It must be decided on a case-by-case basis if this is compatible with the protection requirements of the system and to what extent it is possible to use different service accounts without affecting the desired functionality.

Exceptions to this rule are the special, predefined NT AUTHORITY\LocalService and NT AUTHORITY\NetworkService accounts. These accounts are administered by the internal service controller and provide each service with an isolated security context. Authentication is performed internally in the system by the service controller. Password entries are ignored.

• Each service account should only be granted the minimum authorisations necessary.

For this reason, you should consider giving priority to using the predefined accounts NT AUTHORITY\LocalService for services operating locally and NT AUTHORITY\NetworkService for services with access to a network. These accounts have the same authorisations as the predefined Authenticated Users group (normal users) by default.

Under Windows Server 2008 R2, two special types of account were introduced - the Managed Service Account and the Virtual Account.

• Managed Service Accounts are domain accounts managed under Windows Server 2008 R2, offering automatic password management. Furthermore, classes of domain accounts can be created; these can be delegated to non-administrators for management tasks. Usually, this type of account is used for management of applications such as SQL Server or IIS.
• Virtual Accounts are local accounts managed under Windows Server 2008 R2. Password management is not required for these accounts. Within a domain, logging in to resources of the network is made with the computer identity.

Contrary to the accounts previously used for management of services such as Local Service, Network Service or Local System, the managed service account can be managed centrally as it is stored in the organisational unit "Managed Service Accounts" within the Active Directory.

It must be noted that the new function of the service accounts requires presence of Windows Server 2008 R2 on the managed system. Only one managed service account can be used per system. Furthermore, for complete use of functions the domain must be in the co-called Windows Server 2008 R2 mode (domain function level). For domains in the Windows Server 2003 or 2008 mode, further configuration steps should be performed, if required.

Up to and including Windows Server 2008, local accounts should be preferred over the domain accounts. If domain accounts are used, then they should be granted as few domain authorisations as possible, and the availability of the corresponding domain controllers must be ensured. Service accounts should deny local login attempts (Start | Control Panel | Administrative Tools | Local Security Policy | Local Policies | User Rights Assignment | Deny Logon Locally or in a domain group policy). Under Windows Server 2008 R2 and higher, the accounts already stated above - Managed Service Account and the Virtual Account should be used for administration of service accounts.

• As a rule of thumb, applications with services executed with administrator authorisation are to be operated on a separate server. The higher the number of such applications there are on a server, the lower the level of security it is possible to attain. Examples of such servers are backup servers or domain controllers that need to run their core services with full administrative authorisation.
• The default settings of accounts for the services contained in Windows should not be changed.
• Unnecessary or potentially threatening services should be disabled.
• Many scripts and other types of executable files can be installed and run as services. This procedure is not recommended for normal cases.
• It must be clarified on a case-by-case basis how the behaviour of processes running as services (scripts or programs) influence the stability and security of the system. For example, Stop Service or Restart Service can lead to damaged data because the process itself cannot react to such events and is simply deleted. The use of such a procedure should be tested first in a test environment. Consideration should be given to specifying more comprehensive monitoring settings (System Access Control List, SACL) for the service account to enable detection of unexpected behaviour.
• The common specifications for user passwords are unsuitable in part for application to the passwords of service accounts. The following table shows examples of the default settings after installation. That is why service accounts must have their own password policy defined, adjusted to the security policies of the organisation.

  Password policy	Standard settings on domain controllers	Suitability for use with service accounts
  Password history	24	Yes
  Maximum password age (in days)	42	unsuited
  Minimum password age (in days)	1	Yes
  Minimum password length	7	inadequate
  Password must meet the specified requirements of complexity?	enabled	Yes
  Store passwords using reversible encryption	disabled	Yes

A service account password should have a password length of at least 10 characters (up to 127 characters are possible). The password must not be allowed to expire automatically (Password never expires option in the Properties of the account), but should be changed during regular maintenance cycles instead. A method for changing passwords should be defined, and the passwords should be stored safely, see S 2.22 Escrow of passwords. When there is a large number of services and servers, storing and changing the passwords (including the function tests of the services) can become very complicated so that gain of security may be lost under some circumstances. Utility programs used to manage the passwords of service accounts can be a valuable aid when changing passwords, but their use also entails certain risks. The maximum age of the passwords and the method used to administer them should be specified depending on the protection requirement and the effort required for administration, and then documented in a policy.

Documentation

The service accounts and authorisations for all services not running in one of the predefined accounts must be documented.

Review questions:

• Do all service accounts only possess the minimum privileges needed?
• Was a procedure defined for changing the passwords of service accounts?
• Is it ensured that the built-in administrator is never used for service accounts?
• Is every service operated with a separate service account, if possible?
• Under Windows Server 2008 R2 and higher, are the new account types Managed Service Account and Virtual Account used for administration of service accounts?
• Did service accounts have their own password policy defined and adjusted to the security policies of the organisation?
• Are the applied settings documented with the service accounts?