On Windows systems, services may be run either as SYSTEM or in the security context of a named account. When a named account is used, both an ID and password are required to start each service. The service account may be server-local or a domain account.
The fact that service accounts are run with a password makes password changes more difficult, as they new password must be injected into the infrastructure that runs the service -- SCM, Scheduler, IIS, etc. Failure to correctly inject a new password means scheduling a service interruption at some future, undetermined date.
Service account passwords represent a security risk, in part because some Windows OS components store these passwords in plaintext. A long-lived, static, plaintext password to a high privileged account is a serious threat.
- Hitachi ID Privileged Access Manager automatically discovers the relationship between various types of service programs and service accounts.
- A vetting process invites human experts to add business context to
- Who owns the service (and should be notified of password changes)?
- When and how often should the password be changed?
- Should the new password be injected before or after it is changed on the service or AD domain?
- Should the service be restarted after each password change?
- Once context is provided, Privileged Access Manager can regularly randomize service account passwords, inject new passwords into the appropriate infrastructure and notify business owners.
- Privileged Access Manager service account password changes are fault tolerant -- all systems are checked for availability before each password change and injection of new passwords back into the infrastructure is retried if it does not succeed at first.
Eliminating static service account passwords closes a major security vulnerability.