Background

There are several kinds of non-user accounts like local admin accounts (e.g. root, Administrator), application service accounts (e.g. oracle, Apache), network services (e.g. hdfs, yarn) or batch job/multi-tier apps (e.g. sftp, ssh, etc.)  The goal of Local Account management is to leverage the existing management infrastructure and framework (Active Directory, Centrify Zones, DirectMange/PowerShell/UNIX adedit) and the Centrify client (DirectControl) to provide an additional set of security controls. Centrify Suite 2016 provides the ability to:

• Control local UNIX user accounts (provision, disable, visibility or removal from /etc/passwd)
• Control local UNIX primary or secondary groups (provision, control membership, or removal from /etc/group)
• Perform actions upon user creation/deletion, e.g. home directories, environment variables, password management/lifecycle.

We will provide the basic building blocks for you to evaluate this feature in your lab to explore the feasibility of it.

Like other posts, we'll use the Plan-Do-Check-Adjust model.

Planning

Use these planning steps for your test environment. We'veve added enough information that can be recycled towards production deployments.

Potential Stakeholders

• Centrify SME or Security Lead:  These users are entitled to perform management of zone operations inside Active Directory.
• Account Owners:  These are the subject matter experts that understand how the user or group accounts are used in the environment.  They can answer questions like these
  a) What local user (or group) accounts are required in a system or collection of systems?
  b) Should the account have a password?  should the password be managed?
  c) What are the group account members?
  d) Should the user or group account be visible to apps using name service (NSS)?
• Security Lead for Password Management:   This is the SME for a shared account password management solution.  They may know how to invoke any tools to manage the lifecycle for a shared account.

Technical Requirements

Active Directory and Centrify

• A licensed or evaluation copy of Centrify Suite 2016
• An Active Directory test or production environment with Centrify a Centrify Hierarchical zone
• A UNIX/Linux system with Centrify DirectControl 5.3+

Password Management (optional)

• If using Centrify Privilege Service (CPS), you need the CLI toolkit for your platform and a Cloud Connector that can reach your test systems.
• If using a 3rd party password manager, you need the tools and knowledge of the methods provided by the vendor
  In this example, we'll be using CPS.

Resources

• Centrify Administrator's Guide for Linux and UNIX
• Centrify Privilege Service - CLI Toolkit
• CLI tools and scripts:  admanagelocal, adflush, cjoin (CPS) cgetaccount (CPS)

How Local Account Management Works

The design and management is very similar to what you're used today with Centrify and UNIX-enabled AD users or Groups.

Information about the local user or group is stored in Active Directory.  The local users or groups are defined in the zone.  The scope of the local account is determined by where the identity is defined and the role that is assigned.  For example, if an account should exist and be enabled in all servers, then it's defined in the topmost zone and assigned a role with visibility at that level.  If it should only be visible to a group of systems (e.g. Database Servers) this can be done at the child zone or computer role level.  The management is exactly identical to UNIX-enabled AD users.

Once the changes are made in AD and the flush interval passes (or the adflush command is issued) the local account actions will be triggered.

There are additional CLI tools:

• admanagelocal:  to view existing managed local accounts or refresh the changes (or use adflush).
• handle_local_accts.sh:  this is a sample script provided to perform post-provisioning actions (e.g. home directory creation).  There are two versions of this script, one included with DirectControl, another one included with the CPS CLI Tools.

A Basic Lab Design

In my test environment I have:

1. An AD domain (centrify.vms) with a single domain controller (dc.centrify.vms)

2. A domain-joined server called "member" that has Access Manager installed (Suite 2016)

3. A Centrify zone called global with 2 computer roles:  App Servers and Web Servers

4. Two Linux servers (engubu1404 in the App Servers collection and engcen6 a Web Server)

5. Optional:  because I'll be testing the password lifecycle management, I have a CPS tenant and a cloud connector running on member.  CPS will provide the shared account password management functionality and workflow.

Use Cases

We are going to focus in several use cases:

Local UNIX Group Tests

• Provision a local group:
  - to all domain-joined systems
  - to a subset or individual system
• Manage group memberships
• Remove from /etc/group

Local UNIX UserTests

• Provision a local user
  - to all domain-joined systems
  - to a subset or individual system
  - have the password randomized and the home directory created
• Disable the user
• Remove from /etc/passwd

Local User and Password Management (optional*)

• Provision a local user and manually manage the account's password
• Provision a local user and automatically manage the account's password
• Retrieve the password for usage in break glass or scripting scenarios (admin or request via workflow)
  * These tests are optional given that they require a password manager that provides certain toolsets

Implementation

Download and Install the Centrify Suite 2016 bits

1. Download the Standard Edition 2016 Consoles
2. Download the Centrify client bits for your platform
3. Install Access Manager
4. Install or upgrade your agents  (e.g. install.sh, rpm or yum, apt or dpkg, etc)
5. Join a zone (use adjoin)

Although these steps should be straightforward to you, they are documented here:

General Test Cadence

There's a simple methodology to these tests:

1. Perform the change or update (e.g. create the local user/group, make visible, remove, change membership, etc)
2. Open a session to a system in scope of the previous change
3. Run getent (passwd or group) [target user or group]  > these result should not yield the results
4. Run adflush or 'admanagelocal --reload' (with sudo or dzdo) > this step causes the flush interval to expire and the changes in the zone to be committed by DirectControl
5. Run getent (passwd or group) [target user or group]  > these result should yield the results expected.

For example, if you create a new UNIX group called my-group (GID 3232) in all systems, after an adflush all systems should produce the same result.  If you do this in an individual system (or group of systems.

Differences between Group and User tests

a) Local Users follow the same rules as UNIX-enabled AD users 
Local users must have an identity and a role assigned to be visible in a system.  This allows for you to scope the visibility to the zone (all), child-zone (subset), computer role (subset) or individual system.  This differs from Groups that can be enabled at the zone, child-zone or individual system.

You can even time-bound the visibility of the role assigned to a local user.

b)Users must belong to at least a singe existing primary group

 
Otherwise, the provisioning won't work.

c) Post-provisoning actions must be defined via parameter or GPO

Provisioning users does not mean that home directories, environment variables or the password lifecycle will be handled by the Centrify agent; those actions are customizable.  Centrify provides a parameter called adclient.local.account.notification.cli; it can be used with a provided script /usr/share/centrifydc/samples/localaccmgmt/handle_local_accts.sh to perform these actions. 

d) Don't fall in the poor habits

Always prefer computer roles (users) and child zones (users, groups) instead of computer overrides.

Local Group Testing Video

Local User Testing Video (without actions)

Testing local user provisioning plus actions

Using the provided handle_local_accts.sh to enable provisioning actions

In order to allow for actions to be performed upon user provisioning (or de-provisioning), Centrify provides a sample script called handle_local_accts.sh that will perform actions like assign a random password, create home directories, etc.  To enable this script:

1. Enable the adclient.local.account.notification.cli parameter (set for none)
   

   $ dzdo vi /etc/centrifydc/centrifydc.conf
   # search for adclient.local.account.notification.cli
   # enable the parameter by removing the pound and
   # set it to the path of the sample file
   adclient.local.account.notification.cli /usr/share/centrifydc/samples/localacctmgmt/handle_local_accts.sh
   

2. Run adreload (as root or with sudo/dzdo) and restart your testing.
   For example, to verify that a home directory was created after enabling a local account, you can use the following sequence:
   

   # use access manager to enable the account (e.g. james-foo)
   $ dzdo /usr/share/centrifydc/bin/admanagelocal --reload
   $ getent passwd managed-all
   # this should confirm that the user is enabled
   $ ls -l /home
   # there should be an entry for the recently-created account

Testing local user provisioning plus password management

Using CPS to manage the password lifecycle of a Centrify-provisioned local user account

This test can be performed with any password manager that provides UNIX/Linux-based CLI utilities.  The idea is that upon local account creation, the password manager is notified of the account creation, the password is randomized, changed and managed by the solution.   This example uses Centrify Privilege Service to illustrate the use case.

To set up this test, you need to have a CPS tenant with a Cloud Connector that can reach your systems and a Linux system with the CLI Toolkit.

1. Create a CPS role for the systems that will be used for testing and assign the Privileged Management right
   
   You can also use an AD group and add your computer objects and use it to nest it into the CPS role.
2. Now you can download and copy the CLI toolkit to your test system.
   
   You can add the bits to your repository or copy the installation files manually.
3. Install the CLI toolkit and add the system as a CPS resource (e.g. in my engcen7 RHEL system)
   

   # install the CPS CLI toolkit bits
   $ dzdo yum install centrifycc-rhel6-x86_64.rpm
   # add the system as a CPS resource
   $ dzdo cjoin -k -n engcen7 -a engcen7.centrify.vms
   # The command joins a system using Kerberos, names it engcen7 and gives it the 
   # hostname/ip of engcen7.centrify.vms (FQDN instead of address).  
   # You can verify the status using the cinfo command.

4. Switch the provisioning handler.  The CPS CLI toolkit includes another version of the handler.
   

   $ dzdo vi /etc/centrifydc/centrifydc.conf  # modify the parameter below
   adclient.local.account.notification.cli /usr/share/centrifycc/samples/localacctmgmt/handle_local_accts.sh
   

5. Run adreload (e.g. dzdo/sudo adreload)
6. Now you can add a new local account using access manager (e.g. managed-all)
7. First, verify that the home directory has been created, and then verify in the CPS accounts page that the account exists under the server.
   
8. You can also use the cgetaccount command to check-out the password for temporary use directly from the CLI.
   
   This is not really a practical example, most likely you'd assign the value of the password to a variable and use it on a script.
   

Provisioning local account with actions (random password/home directory) video

Provisioning local account with password lifecycle management (requires CPS or Password Manager)

 This last video provides an example of Server Suite and Privilege Service working together:

1. We review the set up in the Centrify Privilege Service (connector, managed system role)
2. We verify the CLI toolkit in the target systems
3. We join the system as a resource in CPS (using cjoin)
4. We enable the adclient.local.account.notification.cli parameter to use the handle_local_accts.sh provided with CPS and reload the configuration
5. We enable our test account in Access Manager
6. We verify that the account exists in /etc/passwd and that home directory has been created
7. We verify that the acccount exists under the CPS server resource
8. We check-out the password via CPS Web GUI and UNIX CLI (with cgetaccount)
9. We perform an assisted SSH session with the account via CPS console.

Adjustments

There are several improvements to be made, for example:

• Customize the handler script to be suited to your environment
• Use your existing password manager to manage the lifecycle
• Upon deprovisioning, the home folder can be gzipped+tar and removed