Service account password management refers to a process for orchestrating changes to service account passwords in a security database or directory with matching notification to subscribers (i.e., those OS components which start unattended processes such as services and scheduled jobs) of new password values.
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 creates 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 and control gaps may include:
- Repeated attempts to authenticate to the primary security database (on the network) as the account in question, which may lead either to a compromise or a lockout (denial of service).
- 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 configure new services, specifying that they run in the security context of an existing service account whose password they do not know. A malicious actor can take advantage of a running privileged access management (PAM) system to detect the newly installed service and wait for the PAM system to randomize the service account's password and inject the new password into their service, thereby giving them control over a running program running with elevated privileges.
- Inability to monitor or control the use of service accounts when people who do have a legitimate need to interactively sign into these accounts are granted access to 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. Do this only for authorized services (not randomly discovered and potentially malicious ones). 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 a malicious actor to compromise a service account.
Hitachi ID Privileged Access Manager can be configured to secure service account passwords. This means two things, depending on the mode of operation:
- In push mode (i.e., no local agent on the Windows server), Hitachi ID Privileged Access Manager servers periodically connect to Windows servers or Active Directory in order to change the passwords of service accounts.
- If the local workstation service is installed on a Windows system (i.e., the "pull mode" agent), the Hitachi ID Privileged Access Manager service periodically changes service account passwords locally, in coordination with the central Hitachi ID Privileged Access Manager server cluster.
In both cases, Hitachi ID Privileged Access Manager must notify the program that launches services -- the subscriber -- of the new password value, so that it can successfully launch the service at the time of the next system restart or when an administrator manually stops and restarts the service in question. In some cases, for example when domain accounts are used to run services, an immediate restart may be required or advisable, due to Kerberos token expiry. Hitachi ID Privileged Access Manager can be configured to restart services after each automated password change.
Hitachi ID Privileged Access Manager includes extensive automation to discover subscribers and subscriber-to-service-account dependency. This allows Hitachi ID Systems customers to review what services are run in the security context of what named users, on what systems. This is particularly helpful where services run in the security context of domain accounts, since multiple services on multiple servers may run as the same service account and may therefore require notification after each password change.
Hitachi ID Privileged Access Manager includes several mechanisms to accomplish safe and secure changes to service account passwords:
- Auto-discovery of subscriber/account dependencies for a variety of subscriber types: IIS (multiple sub-components may have service accounts/passwords), Scheduler, SCM, DCOM, at various OS and subscriber versions.
- White-list policy tables:
- Initialized with discovered data about service accounts and services.
- Allow organizations to specify a password randomization schedule.
- Allow organizations to name application owners, who will be notified of password changes and any issues.
- Allow organizations to specify a style of notification. For example, notify the subscriber of new password values before a password change, after or both? Restart the subscriber or not?
- A mechanism that tests for the availability of all subscribers before each password change. In particular, if some systems where services run in the security context of a domain service account are unreachable, then changes to that account's password will be deferred.
- Built-in tools to notify subscribers of new password values and restart services if this was specified in the policy.
- A transaction manager that will retry notifications to subscribers that went off-line after a password was changed and before they could be notified of the new password value.
The above are primarily used when managed systems are integrated with Hitachi ID Privileged Access Manager in "push mode" -- i.e., there is no locally installed agent on the target system and Hitachi ID Privileged Access Manager initiates all connections remotely, over the network, directly or via a Hitachi ID Privileged Access Manager proxy server deployed near the target system.
Where push mode is inappropriate -- for example because the relevant services (remote registry, WMI, etc.) are disabled or firewalled or because the end system is offline or inaccessible due to name resolution or IP routing issues (NAT, etc.), a local workstation service can be installed on the managed system, which performs essentially the same functions but with much simpler connectivity (call home over HTTPS) and no need for network accessible services on the local system.
The local workstation service is most often used on laptops and in firewalled network segments (DMZs).
Hitachi ID Privileged Access Manager is normally configured to contact application owners after each password change and in the event of a problem. This makes troubleshooting easier in the event that notification failed and a service subsequently could not be started.
The entire infrastructure mentioned here is extensible. Customers can expand it to support other process-launching systems, such as third job party schedulers for example.