Application and Service Accounts: Half Protected is Half Not

February 16, 2016

Cyberattackers tend to focus on end users to get into an environment, traversing the network and systems these attackers hunt for accounts with access to sensitive data -- their target. While the ultimate “keys to the kingdom” are administrative accounts such as Local Administrator and highly-privileged IT user accounts, non-user accounts such as those used by applications and services also need to be protected. If you’re only securing end user and privileged user accounts, your leaving half of the accounts in your environment -- application and service accounts -- at risk of being compromised.

Mandiant M-Trends 2015 Report indicated:

“Attackers target privileged accounts such as local administrator, domain administrator, and service accounts. Reduce the number of privileged accounts. Also, ensure that all local administrator accounts have unique passwords.”

There are a few current trends affecting a growing number of applications authenticating to other applications or services for successful completion of a task:

  • Modern multi-tiered web applications. The web layer must authenticate to the computer layer, which authenticates to the database where data is stored.
  • Clustered solutions such as Big Data environments. NoSQL and Hadoop require services running on nodes that must authenticate with other nodes in the Big Data cluster. This includes service accounts such as hdfs, hbase, hive, impala, mapred, yarn, zookeeper, etc.

Additionally, the configuration of a new server with all the requisite agents can be cumbersome and in many cases applications or agents will require a service account to be provisioned on each system. For example, you may require several accounts such as Splunk or ArcSight Logger and Nagios to exist so that you can monitor the system logs and performance, you may also need another account to enable a central management tool to login and perform management functions. Then there are applications such as Oracle database that require a local service account for the process to run.

The rights or privileges that these types of accounts require, whether access to remote systems (Hadoop service accounts and file transfer batch job scripts) or to control access to sensitive local data (Oracle or HDFS account), present as much if not more risk if a cyberattack were successful in taking over these accounts. Attackers know IT likes to automate the management of servers or file transfers, so they look for these accounts because typically they will allow the attacker to move laterally to other servers within the data center. Organizations need to make sure to enforce strong password management as well as access controls for these accounts to reduce their identity-related risk. Centrify has introduced several new features that integrates with existing capabilities to provide a complete solution for managing these non-human service accounts.

  • Local Account Provisioning – Centralizes the management of local accounts and groups within Centrify Server Suite Zones.
  • Shared Account Password Management – Provisioned local accounts are automatically added to Centrify Privilege Service for password management.
  • Application to Application Password Management – Centrify provides a secure model for enabling scripts to checkout a password for a service account.
  • Local Account Discovery – Centrify Deployment Manager discovers computers and their existing local accounts on Linux and UNIX systems.

Local Account Provisioning

Centrify Server Suite 2016 introduces new capability for Local Account Provisioning:
  • local accounts can be created, updated, disabled, and removed from /etc/passwd
  • local groups can be created, updated, removed and membership can be managed

Shared Account Password Management

Now that local accounts can be centrally managed and created locally, we need to provide full lifecycle management and to integrate with password management systems. To address this, Server Suite 2016 provides a call out to enable an external script to take action upon a local account creation or deletion. As an example, as a new local account is added, the sample script provided is designed to integrate with Centrify Privilege Service in order to add this new account so that its password can be managed, periodically rotated and available for authorized checkout.
In this diagram, the Administrator defined the local accounts in the Centrify Access Manager console, then the Centrify Server Suite Agent created the local account in /etc/password and called a script which used the Centrify Privilege Service CLI toolkit to add the account so that its password can be managed. Now all the local accounts are centrally managed and their passwords are managed as well.

Application to Application Password Management

Once the local account has been registered with Centrify Privilege Service and it is managing the password, we can now grant permissions on these accounts so that other apps or scripts can call the Centrify CLI to request the current password for an account in order to use the password to login.  In order to control access, we grant the client computer's Active Directory account with checkout permission for the specific account, then the client application account must also be given privileges via sudo or dzdo in order to run the CLI to request checkout for the application account password.
Now that the environment is setup to manage the password for the service account, you can replace the password within your scripts with a CLI call from the script to request to checkout the password. Once the checkout timeout expires the system will rotate the password to ensure that it is protected.
PASSWORD=$(dzdo /usr/sbin/cgetaccount --silent "$REMOTE_CPS_RESOURCE_NAME/$CPS_USER" 2>> $LOG_FILE)


sshpass -d 300 scp -o StrictHostKeyChecking=no $SCP_USER@$SCP_HOST:"$SCP_FILE_SRC" "$SCP_FILE_DST" 300<<


In this example script (I didn't show all of it, but the sample is provided with the Centrify CLI Toolkit in the samples directory) you can see that you only need to call the cgetaccount command via dzdo or sudo in order to checkout the password, then just feed it in where it was previously hard coded such as here we use sshpass to feed the password into scp for the file transfer operation.

Local Account Discovery

Additionally, if you already have several computers with local accounts where you need to have Centrify take over management of the password, you can easily use Centrify Deployment Manager along with some simple custom scripting that uses the Centrify CLI toolkit as a way to enable admins to select specific local accounts, then run the script which will add the account to Privilege Service where it can take over management of the password.
Centrify provides a complete application account identity lifecycle that combines Local Account Provisioning, Shared Account Password Management and Application to Application Password Management capabilities in a single integrated solution.

You can get started today with a free trial of Centrify Server Suite or Centrify Privilege Service. And if you are already a Centrify Identity Service customer and want to try Privilege Service, simply contact your Centrify account team.

This is written by the individual author in his/her personal capacity, and the opinions, views and/or thoughts expressed herein are solely the author’s own. They are not intended to and may not necessarily reflect the official policy or position, or the opinions or views of ThycoticCentrify or its affiliates, employees, or any other group or individual.