When I talk to people about privileged identity management many of them think first and foremost about local accounts. So I explain that the next level of privileged identity management involves not only managing privileged accounts, but also where they’re being 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 is logged 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 or processes 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 used that is 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 account, Kerberos, LDAP or database access credential.
Service Account Credentials Must be Changed Regularly
Service account-based applications must keep a copy of the powerful credentials needed to perform their actions. These service account credentials are generally encrypted or obfuscated, but 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 the authenticator be updated, but also all references. Updating all of 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 in 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 to IT 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 due to the complexity of the process, don’t lose hope. Our Lieberman RED – Rapid Enterprise Defense Identity Management product can automate this job quickly and at scale, with minimal human interaction.
Watch the Webinar
Want to learn more about service account management? Watch our recorded webinar Dealing with Service and Process Accounts in the Enterprise.
By Chris Stoneff, Vice President Technical Management, Lieberman Software
Chris Stoneff oversees product management, quality assurance and technical support at Lieberman Software, and is instrumental in guiding the development of the Lieberman Software products portfolio.
If you like this topic, please subscribe to our Cyber Defense Newsletter.
You can also follow us on Twitter.