Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

[Labs] Automating Adds and Removals of Linux/Windows Systems and Accounts in the Vault

11 April,19 at 11:50 AM

This article discusses the different approaches to populate information into the Centrify Privilege Service vault.  The stage in process of implementing a PIM solution dictates many of the strategies to be used.  At the time of this writing, we are looking at version 17.8, but as you know, releases come every month, therefore, the strategies discussed in this post are subject to change as more capabilities, system types or accounts are added.


We will be focusing on the Linux CLI toolset and the PowerShell Samples.


The Lifecycle

A Shared Account strategy is part of what's needed to continuously overcome the challenges around PIM.  These bullets correspond to where many of our prospects or customers are:

  • Brand new to a shared account strategy.
  • No shared account solution, but a very mature process.
  • Migrating from an existing shared account solution.
  • Optimizing the day-today-operations of an existing shared account strategy.
  • Adjusting strategies (e.g. favored shared account, over least privilege).


Two Types of Activities

I think we can easily condense the strategies into two categories: population and onboarding:

  1. Population activities happen when the shared account strategy is brand new, or a migration is in place (maybe switching solutions or going through M&A activities).
  2. Onboarding activities relate to the orchestration and automation of the regular IT operations (adding systems, accounts, domains, databases, etc).

As of this writing, the tools included with privilege service are:

  • Wizard - manual way of onboarding resources and accounts (out of scope for this article).
  • Import - CSV import for systems and local accounts.
  • Discovery - AD-based for Windows or Linux computers, Scheduled Tasks, Services and their corresponding identities
    (will be briefly mentioned, but covered in depth in a different article).
  • CLI Tools for Linux - cenroll & csetaccount, included with Identity Broker.
  • PowerShell Samples for Windows(tm) - available at your request.
  • REST API - Learn all about them here (out of scope for this article).


The Import Tool

This tool is useful if you're populating a new vault, or if you have a CSV of  the sytsems and accounts that you want to onboard. The import tool is tied to the job system.


  • Name - name of the system in privilege service.
  • FQDN - fully qualified domain name (resolvable) or IP address for the system. If using IP, can't use for zone-role workflow.  
  • ComputerClass  - the type of system.  As of this writing:  UNIX, Windows, Generic SSH, CheckPointGAiA, IBM System i, Juniper , Cisco IOS, Cisco NX-OS, & HP NonStop.  This can potentially change every month.
  • Description - the description of the system.
  • ProxyUser -proxy account to be used.
  • ProxyUserPassword -self-descriptive.
  • ProxyUserIsManaged - determines if the proxy account's password is managed or unmanaged by privilege service.
  • User   -  local account.
  • Password - local account password.
  • Managed - If the account is managed or unmanaged by privilege service.
  • UseProxy - if a proxy account will be used to access this system.
  • UserDescription - description of the user.  
  • Domain - if the account is joined to an AD domain, this is the domain name.  .
  • DomainOperationsEnabled - this is to set if the zone-role workflow if needed.



Privilege Service provides an AD-based Discovery tool.  Discovery has the flexibility that it can be used to populate for the first time or in point occasions as well as ongoing.



From system launch to system termination - the process



Enrollment Codes

Enrollment codes allow for a system to automatically be added to privilege service with access control options like owner, # of systems allowed, IP restrictions and sets.
Enrollment codes are a great tool to enable automation or DevOps scenarios.


PowerShell Samples and Onboarding

The idea behind the PowerShell Samples is to be able to align newly-built Windows systems with the registration in the Privilege Service vault to protect shared accounts or to enable the secure access capability.  Alternatively, systems can be organized in sets.  The samples work with enrollment codes or interactively with user/password combinations.  The latter part is reserved for human interaction.


What you need:

  1. PKI Trust pre-requisite:
    The IWA root certificate for the service or tenant should be trusted (manually or via enterprise trust); same for the certificate used for SSL for the platform (not an issue with SaaS, but yes with customer managed if not following proper PKI practices).  This MFA-centric article, discusses the topic.
  2. Centrify Samples:  Available on github or attached to this post (see below).
  3. An administrative local Windows account to perform the system tasks.


PowerShell Samples in Action

Long command lines are split


Enrollment and onboarding a local account

# This is a sample script that runs at POST; once the system is built, 
# patched and joined to Active Directory. 
# The assumptions are that an enrollment code has been issued and that 
# the modules can be loaded (in this case from the X:\CIP drive 
# and that the proper sets have been put in place.

# Loading Modules
Import-Module X:\CIP\cps\Centrify.Cloud.PowerShell.CIP.psm1
Import-Module X:\CIP\cps\Centrify.IdentityPlatform.Powershell.psm1

# E.g. Enroll code, FQDN, Name, and endpoint are required, sets are optional.
# Enrollment Code: B8674D29-890C-4036-AEAB-682DBEF6CA78
# FQDN or IP: member.centrify.vms
# Name: member-vault
# Service Address:  https://vault.centrify.vms
# Sets:  PCI and Engineering  (JSON notation, attribute Name)

$computer =   ($(Get-WmiObject Win32_Computersystem).name 
| Out-String -Stream).ToLower()
$computerfqdn = [System.Net.Dns]::GetHostByName(($env:computerName)).HostName 
| Out-String -Stream
$sets = "Engineering, PCI" 
$sets_json = "[ { 'Name': 'Engineering' }, { 'Name': 'PCI' }]"
$vault = 'https://vault.centrify.vms'

Enroll-CIPSystem -EnrollCode $enrollcode  -FQDN $computerfqdn  
-ResourceName $computer -Endpoint $vault -Sets  $sets_json

# Onboard the Local Administrator account.
# This is a placeholder.  Good script here:  
# Return the temporary random password to $localpasswd, this will be rotated 
# automatically.

$localpwd = 'R@nd0mG%$56bagethatWILLC6ng3soon' 
$accountname = 'Administrator'
Set-CIPAccount -AccountName $accountname -AccountPassword $localpwd 
-isManaged $true 

# Set Centrify Vault Metadata in the Description of the AD Computer Object
$joined = (Get-Date).DateTime | Out-String -Stream
$desc =  "Sets: $sets. Enrolled to CPS on $joined."  

Set-ADComputer $computer -Description $Desc


PowerShell Samples Usage

1. First, import modules
What's needed: path to the PowerShell modules

Import-Module C:\[insert-path-here]\Centrify.IdentityPlatform.Powershell.psm1
Import-Module C:\[insert-path-here]\Centrify.Cloud.PowerShell.psm1

2. Enroll a system
What's needed: An enrollment code, the name, the FQDN or IP and the endpoint 
(tenant URL).

Enroll-CIPSystem -EnrollCode [code] -FQDN [fqdn/ip] -ResourceName [system-name] 
-Endpoint [https://your-url-here]

Enroll-CIPSystem -EnrollCode "B8674D29-890C-4036-AEAB-682DBEF6CA78" 
-FQDN 'member.centrify.vms' -ResourceName 'member-vault' 
-Endpoint 'https://vault.centrify.vms'

What happens when a system is enrolled?
1. The system is added to CPS.
2. A service account is created in CIP with the default suffix.
3. The system is added to a built-in role called "Centrify Agent Computers."
4. The service account is added with the grant, view, edit and delete" 
permissions at the system level.

Note that you can add a system to a set. 
Another example: Adding a system to the Engineering and PCI Sets:

Enroll-CIPSystem -EnrollCode "B8674D29-890C-4036-AEAB-682DBEF6CA78" 
-FQDN 'member.centrify.vms' -ResourceName 'member-vault' 
-Endpoint 'https://vault.centrify.vms' 
-Sets "[ { 'Name': 'Engineering' }, { 'Name': 'PCI' }]"

3. Unenroll a system
What's needed: an administrative account.

Unenroll-CIPSystem -Delete $true 
# proper way to leave CIP this will remove the service account.
Unenroll-CIPSystem -cleanupOnly 
#cleans locally in the system, equivalent to a forced adleave.

4. Vault an account
What's needed: resource/domain/database, account name, password and if it's 
managed or not; if other system, database or domain, the system must 
be authorized to add accounts in the resource.

# Sets the local account opieadmin as managed
Set-CIPAccount -AccountName 'opieadmin' -AccountPassword 'ThisStringwillChangeS00n!' 
-isManaged $true

# Sets the remote account testuser in the system engcen6 as unmanaged
Set-CIPAccount -resourceName 'engcen6' -AccountName 'testuser' 
-AccountPassword 'SecretsAreToBeProtected!' -isManaged $false

What happens when a system is enrolled?
1. The account is added under the resource in question.
2. The system that performed the addition, is added with all account 
permissions except portal login.

5. Check-out a password
What's needed: credential type, name and checkout lifetime. If other system, 
database or domain, the system must be authorized to view the top level resource 
and view+checkout at the account level.

Get-CIPAccount -AccountName 'opieadmin' -lifetime 2
Get-CIPAccount -domainName "" -AccountName "your-user" -lifetime 2
Get-CIPAccount -databaseName "db-name" -AccountName "your-db-account" -lifetime 2

Other Commandlets:
- Remove-CIPAccount - removes a system/domain/database account.
- Centrify-GetAccountID - gets the unique identifier for an account.


Linux Client CLI Tools

The help topic contains all the commands included with the client. Let's focus on the same sequence above, but for Linux.

What you need:

  1. PKI Trust pre-requisite
    The IWA root certificate for the service or tenant should be trusted (manually or via enterprise trust); same for the certificate used for SSL for the platform (not an issue with SaaS, but yes with customer managed if not following proper PKI practices).  This MFA-centric article, discusses the topic.
  2. CentrifyCC bits
    These can be obtained from the Infrastructure > Linux Agent section of the Admin Portal, from the Centrify Repo, or distributed via RPM.
  3. Sudo or superuser-like privileges.


CLI in Action

Enrollment with cenroll

# E.g. Enroll code, FQDN, Name, and endpoint are required, sets are optional.
# Enrollment Code: B8674D29-890C-4036-AEAB-682DBEF6CA78
# FQDN or IP: centos7.centrify.vms
# Name: centos7-v
# Service Address:  https://vault.centrify.vms
# Sets:  PCI and Engineering 

$ sudo cenroll --tenant vault.centrify.vms 
--code B8674D29-890C-4036-AEAB-682DBEF6CA78 --verbose --features all 
--agentauth identity-broker-users --name centos7 
--address centos7.centrify.vms --resource-set PCI, Engineering

Enrolling in Centrify identity platform https://vault.centrify.vms/ 
using enrollment code...

Feature enabled: Application-to-Application Password Management
Feature enabled: Centrify Agent Authentication

Starting Centrify agent...
Centrify agent started.
[output truncated]


Adding account passwords to the vault with csetaccount

# Set the account password to something random 
# Send it as a parameter for csetaccount using the --stdin option
# Always clean-up.

# Creating random string
sudo cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 32 | head -n 1 
> /tmp/temp.file

# Changing account password
sudo yes `cat /tmp/temp.file` | passwd root

# Vaulting the credential
sudo csetaccount --verbose --managed=true --stdin root < /tmp/temp.file
verbose: setting account through cclient

# Housekeeping
sudo rm -f /tmp/temp.file


The account and password are onboarded under the system in question.



The system rotates the password immediately.


The system can read and delete the password (ready for the EoL use case).


Deleting an account and unenrolling a system

# Deleting an account from the vault
$ sudo cdelaccount --silent root

# Unenrolling a system (e.g. prior to decommision or termination) using the 
# system account
$ sudo cunenroll --delete --machine

The Linux agent allows for the onboarding of database (Oracle, SQL Server) or Active Directory domain retrieval for CLI or machine to machine scenarios (see cgetaccount).


AWS and GCP Automation

In AWS and GCP, the lifecycle (launch instance/terminate instance) can be automated using the methods above and Centrify has provided some assets also available via GitHub.


Below are the variables that require information (to vault systems automatically):

# Specify the customer tenant URL to enroll in cenroll CLI

# Specify the enrollment code to use in cenroll CLI

# Specify the roles to grant "AgentAuth" right in cenroll CLI

# Specify the features to enable in cenroll CLI

# Specify the type of network address. Possible values:
# "PublicIP" (default), "PrivateIP" or "HostName"

# Specify the prefix of the login name to use for this computer in the Centrify
# identity platform. The format is -.


Expect the methods to continue to evolve, just like the system types and capabilities are added monthly.


We want to hear from you

What can we improve?  Always use the comments or leverage the idea exchange and community.