When I talk to many people about privileged identity management they think first about local accounts. So I explain the next level of privileged identity management. It involves not only managing privileged accounts, but also where they’re used. This means locating every account, figuring out where and how they’re used, and then changing their credentials everywhere. All without causing an outage.

Many servers use local accounts - like root on Linux and administrator on Windows - to run persistent applications, whether or not someone logs into the machine. For example, a web site would be an example of a persistent application. So would a database or other line-of-business application.

Here’s where service accounts come in. Service accounts are needed for these persistent applications so that they can perform actions on behalf of the users of the application. In effect, these accounts are proxies for performing limited actions for users that have no access to sensitive data and systems.

In many cases, the mechanics of service accounts means that an account must be known and verifiable to not only the application, but to everything that the application interacts with. Consequently the service account is generally a powerful Windows domain, Kerberos, LDAP or database access credential.

Privileged identity management involves not only managing privileged accounts, but also where they’re used.

Service Account Credentials Must Change Regularly

Service account-based applications must keep a copy of the credentials needed to perform their actions. These credentials are generally encrypted or obfuscated. But they must be available on demand by the application or service.

The consequence of the service account structure means that any password change of a Superuser credential must be done not only in the authentication system (i.e. Active Directory), but also in every service/application that stores the password for that same credential. So not only must you update the authenticator, but also all references. Updating all the places where a service account is stored is known as propagation.

How Service Accounts Cause Trouble for IT

To successfully change the password of an account, you must not only change it where it is being stored. You must also change it every place that references that account. If you miss any of the places that have a stored password, the wrong password will be used and that service will not work properly. In some cases, the use of an incorrect password by a service can cause the operating system to think that account is under attack and lock out the account. This last scenario means that every service that uses that locked out account will now fail too.

So the first challenge of service account management is discovery and correlation. That means understanding which credentials are in their systems, as well as where they are being used. The second challenge is propagation - understanding how to change the references to those credentials and not miss any.

The Solution for Proper Service Account Management

If you’re tasked with changing credentials on a regular basis, but consistently run into problems because these changes cause outages, don’t lose hope. The Privileged Identity component of Bomgar’s Privileged Access Management solution can automate this job quickly and at scale, with minimal to no human interaction.

Have a look and then contact us to learn more about service account management.