On the Windows operating system, service programs are run either using the SYSTEM login ID, which possesses almost every privilege on the system (and consequently can do the maximum harm) and which requires no password or using a named local or domain account. Services are run in the security context of a named account in order to reduce the privileges available to them at runtime.
When Windows services are run with a named account, the password for that account is needed to start the service process. This means that the Service Control Manager (SCM), IIS web server, Scheduler, etc. all need to know both the ID and password of service accounts, when they are configured to run jobs, services, application pools or similar contexts as a named account, rather than as SYSTEM.
Service account passwords differ from administrator passwords in that they appear in at least two places:
Some Windows components, notably IIS, are able to periodically change the passwords of local service accounts they use. Unfortunately, this capability does not extend to domain service accounts, used to run services on multiple systems and does not apply to all types of service accounts. This means that many Windows service account passwords remain static by default.
Hitachi ID Privileged Access Manager can be configured to secure service account passwords. This means two things, depending on the mode of operation:
In both cases, 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. Privileged Access Manager can be configured to restart services after each automated password change.
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.
Privileged Access Manager includes several mechanisms to accomplish safe and secure changes to service account passwords:
The above are primarily used when managed systems are integrated with Privileged Access Manager in "push mode" -- i.e., there is no locally installed agent on the target system and Privileged Access Manager initiates all connections remotely, over the network, directly or via a 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).
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.