Managing Unix service accounts

Showing results for 
Search instead for 
Do you mean 
Reply
Advisor II
Posts: 55
Registered: ‎12-18-2015
#1 of 2 274
Accepted Solution

Managing Unix service accounts

Hi,

i see there are basically two options to build service accounts management process:

- Map local accounts to AD (i.e. migrate accounts to AD)

- Enroll local accounts to the Vault and manage (in broad sense) 'em with cloud.

What is the recomended approach?

Highlighted
Centrify Guru I
Posts: 2,411
Registered: ‎07-26-2012
#2 of 2 272

Re: Managing Unix service accounts

[ Edited ]

Assuming UNIX-like systems here.  For AD, different story.

 

In reality, this depends.

What you need to use is this statement:   Do we really need this service account?

In modern security, you want to get rid of static privileges;  unfortunately, service accounts happen to have static or even (worse) internal entitlements (e.g. oracle account).  Here are some aspects to consider

  • Impact to Ops/SLA/Uptime:  general problem with the password management approach is that you have to assess the impact of operations for swapping/changing passwords.
  • Impact to audit/attestation:   static, commonly-named service accounts are always targeted.  Auditors may want to know secops activity or even know what entitlements if using least access.
  • Environment:  on prem, vs dmz, vs IaaS may have different tooling.  Depending on your toolbox, maybe even Chef/Puppet/Ansible may do a good job here.

 

I would try to always eliminate the account first, Kerberize or make it into a small-scope OAUTH2 account if modern app.

 

Let's see what I've seen (any other readers, feel free to chime-in):

Client-based approaches

  1. Map to AD account - if the service supports the UNIX PAM or NSS framework.
  2. Sync with AD account - this implies using a password sync (generally not a best practice - requires schema extension).
  3. Kerberos Keytab - very common with load balancing, Hadoop, etc.
  4. Zone-based local account - the zone becomes the authoritative data source for the local account.
    This can be combined with the vault approach:  The zone defines the status (enabled, disabled) and the password is managed by the vault.

Vault-based approaches

  1. Manage the password with the vault (cloud and on-premises) - e.g. if the account must be local.
  2. Manage the API Key with back-end rotation.

Other Approaches

  1. Use OAUTH2 client.
  2. Use SAML.

 

Bottom-line, what you use, really depends.

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify: