Hitachi


Previous PDF

swipe to navigate

Introduction

This document is intended as an introduction to the process of periodically and automatically changing the passwords on Windows service accounts. It is meant for a technical audience which has been tasked with replacing static, embedded Windows service account passwords with a system where these passwords are automatically changed to new, random values on a regular basis.

Types of privileged accounts

Privileged accounts, like their name suggests, are accounts designed to provide elevated access to systems and data. They are an integral part of every IT infrastructure and play a key role in a large variety of day-to-day operations, from the management of operating systems and application servers by administrators to providing appropriate security contexts for running services, or securing communication between interdependent business applications.

Because they exist in one form or another in virtually every server, workstation or appliance in the enterprise, the larger the environment, the more challenging it becomes to maintain an accurate repository of information related to these types of accounts. At the same time, due to their privileged nature, they are a prized target for attackers and one of the first items IT auditors focus on when assessing the security posture of an organization. It is therefore crucial for enterprises of any size to implement processes -- be they manual or automated -- for discovering and managing most if not all of their privileged accounts.

From a high level perspective, privileged accounts fall into one of the following three categories:

  1. Administrative accounts:

    These are accounts used to establish interactive login sessions to systems and applications. Often shared by multiple IT people, they provide the administrative access permissions required to install applications, apply patches, change configuration, manage users, retrieve log files, etc.

    Administrative accounts can be further divided based on their access scope:

    • Local administrative accounts:

      These privileged accounts have a more limited scope, since they only provide administrative access to the local host or application on which they reside. Examples of local administrative accounts include members of the local administrators group on a Windows workstation, such as Administrator, the root account on Unix/Linux servers, the sa account on MSSQL Servers or SYSTEM on Oracle databases.

    • Domain administrative accounts: These accounts typically provide administrative access to all systems that are members of a given domain. A common example here would be domain accounts that are members of the Domain Admins security group in an Active Directory domain.

  2. Application accounts:

    These accounts are used by one application to connect, identify and authenticate to another. Common examples include accounts used by a web application to connect to a database server or accounts used by a batch script to connect to a web application's API service. Because of their intended purpose, credentials for this type of accounts are often lacking an adequate protection, making them a prime target for attackers.

  3. Service accounts:

    These are non-personal privileged accounts, configured with either local or domain level access, whose purpose is to provide a security context in which to run unattended processes, such as scheduled tasks, services or "daemons."

Terminology

  1. Clustered application:

    Represents an application that is composed of a number of identical nodes. Examples include server farms, Active Directory domains, Hitachi ID Identity and Access Management Suite replicated nodes, etc.

  2. Application node:

    Individual systems or applications that are members of a clustered application. Examples include individual servers, Active Directory domain controllers, individual Hitachi ID Suite server nodes, etc.

  3. Primary security database:

    A repository of login accounts that contains (at least) an ID and password for each account. In the Windows environment, this may be either a local SAM account database or Active Directory. On other platforms, they may include /etc/passwd and /etc/shadow on Unix/Linux, the security database in RAC/F and various system tables in SQL Server, Oracle and other databases.

  4. Security context:

    Processes executing on any multi-user operating system, including Windows, Unix, Linux, z/OS, etc. have a security context. This context always includes the identity of the user whose permissions determine what the process is and is not allowed to do.

    On Windows systems, processes may either run as Local Service, Local System or Network Service -- all of which are unauthenticated, privileged users that are fundamental parts of the operating system or in the security context of a named user. Example named users, used to run services on Windows, include:

    • IUSR_machinename -- retrieves web content inside IIS on behalf of unauthenticated web browsers.
    • IWAM_machinename -- launches external processes from IIS.
    • BESAdmin -- used to run Blackberry Enterprise Services application components.

    On Unix/Linux systems, typical accounts include nobody or apache to run the Apache web server, mysql to run the MySQL database, bind to run the BIND DNS resolver, etc.

  5. Subscriber:

    An entity that stores a password used to authenticate to a primary security database. For example, Windows Service Control Manager may be a subscriber, where it runs a service in the security context of a named account and in this case the primary security database may be either the local Windows SAM database or Active Directory.

  6. Service account:

    An account in a primary security database, in whose security context at least one service is run. A subscriber is that which authenticates to the primary security database, in order to establish a security context for a process which it wishes to run.

  7. Managed process:

    The service or task started by the subscriber, which runs in the security context of a service account.

  8. Application account:

    Application accounts are used by one application to sign into another application, either locally on the same system or across a network. They are not used to establish an operating-system-level security context. Examples are accounts used to connect a client to a database server, to bind a client to an LDAP(S) directory server, to authenticate to API services, to attach to network file systems, etc.

  9. Service account password change:

    The act of changing a password in the primary security database. On the Windows platform, service account password changes must be accompanied by notification of the new password value to every subscriber that uses that service account (see below).

  10. Notification:

    The act of informing subscribers of a new password value for a service account that it uses. The notification process may involve additional steps, the most common being the stopping and restarting of services.

  11. Orchestration:

    A coordinated process involving exactly one service account password change and one or more related notifications. For example, if a service account is used by multiple subscribers, orchestration is required to notify all of them of a new password value.

  12. Privileged access management system:

    A system that can (among other things) effect service account password changes and orchestrate subscriber notification.

  13. Credential vault:

    A secure database maintained within a privileged access management system that contains (among other things) the passwords to service accounts.

Motivation for changing service account passwords

Service accounts on the Windows platform are often protected with a password. Due to the complexity involved in coordinating a change for these passwords across an enterprise, it is common practice for companies to exclude them from their normal password management policies. This, of course, represents a significant security risk because the longer a password remains unchanged, the higher the chance that it may be compromised by an attacker.

Attack methods may include:

  • Repeated attempts to authenticate to the primary security database (on the network) as the account in question.
  • Extracting a copy of the primary security database's list of password hashes and attacking that local copy.
  • Extracting a copy of the persistent storage used by a subscriber to hold service account passwords and using passwords from that data to connect to the primary security database.
  • Human beings who set a service account password in both the primary security database and any subscribers misusing, sharing or otherwise compromising those passwords. This is especially problematic if the network perimeter has been breached and malicious parties have access to sensitive subscribers and/or primary security databases.
  • Inability to monitor or control use of service accounts by people who do have a legitimate need to know their passwords.

The solution to all of these security concerns is obvious: implement an automated process to periodically change service account passwords to new and random values, without exposing them at any time to human operators. If, for whatever reason, humans do require manual access to some of these accounts (for example, to schedule a new job or install a new service), control access to these accounts and promptly change their password as soon as possible. Having these processes and controls in place will limit the time available to an attacker to compromise a service account password.

Technical challenges

If periodically randomizing service account passwords was simple, everyone would do it. This is not commonly done because of technical challenges:

  • Discovering and managing all service account passwords.
  • Discovering all subscribers for all service accounts.
  • Notifying subscribers of new password values with a process that is both fast (completes almost immediately after each password change) and reliable (100% reliable, even when there are network or infrastructure outages).
  • Troubleshooting service problems that result from unreliable or incomplete notification.
  • Sustaining notification processes through software version upgrades.
  • Detecting and resolving problems due to intruder lockouts being triggered on accounts in a primary security database.

Previous Next PDF