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  >

[HOWTO] Use Centrify Tools for Public/Private Cloud Automation Activities

11 April,19 at 11:49 AM

Security Requirements

  1. The least privilege model must be followed
  2. Separation of duties must be followed
  3. No passwords shall be known or used
  4. Security shall be able to attest access and privileges using different tools and reports


  • Active Directory Users and Computers
  • Centrify DirectManage Access Manager
  • Centrify CLI tools: adjoin, adleave, adkeytab
  • Kerberos tools:  kinit, kdestroy.

As always, we'll use the Plan-Do-Check-Adjust method



For a simple example, we'll consider the following planning steps:


  • Incorporate the Centrify agent bits into the infrastructure image, the agent can be installed and not joined.
  • An AD Service account with the ability to create, remove (or modify) computer objects to the target domain OU should be created, additionally, to be able to modify group memberships to the AD groups that contain Computer Roles.
  • That same AD service account should have the rights to join, remove and modify objects in the target Centrify zone.
  • A Kerberos keytab file needs to be created for the AD account and securely put in a place where the script can use it.  Let's assume that the file will be securely copied to a local drive and deleted upon use.
    Note:  this is important, a Kerberos key table file needs to be to be treated with the same sensitivity as a private key.  They are not to be left behind on systems even if the account has been properly secured.
  • In addition to the keytab file, a krb5.conf file with the correct settings needs to be deployed to the unjoined system so the Kerberos tools can find a KDC (AD DC).
  • Naming conventions for the OUs, Roles, AD Groups, service accounts and hostnames need to be pre-established.  Keep in mind that computer account names have length limitations.  We'll touch a bit on the example.
  • An AD OU for Unix/Linux or Mac computers is required to limit the scope of where the join account can perform joins operations.


Implementation (Do)


The implementation two kinds of steps:

  • Non-frequent or singular steps:  These steps may be performed only once or be revised occasionally, for example, when a new template has to be created for a different type of system.  I will describe these at a high-level.
  • Operational steps:  In this particular example, these are the automation steps.  These steps will be described in detail.

Example Reference Design

  private-public cloud reference.jpg

This is an excerpt of my Amazon AWS infrastructure.  We have an AD forest ( with a Global Centrify zone and a computer role named Web Servers.  Computer objects live under the OU. The access/privilege model has been created with two roles (SysAdmin and Web Admin).  In this example, our service account (ad-joiner) must be able to add/move/change computer objects into the Servers OU; plus needs to be able to add computer accounts into the AD groups contained in the Computer Roles OU.


Preparing the Service Account  (one-time)

  1. Create an AD account, set with the "Password never expires" and "User cannot change password" flags.  Although the password will be known to you at first, once the keytab is generated, the password will be randomized an unknown.
  2. Delegations in Active Directory
    Servers OU:  Delegate the ability to Create and Delete computer objects.
    Computer Roles OU:  Delegate the "Modify group memberships" predefined right.

    ADUC - delegation computer object.jpgADUC - delegation membership group.jpg
    This will provide the assurance that the service account doesn't have any additional privileges in AD.
  3. Delegations in the Centrify Zone
    At the zone level:  delegate the "Join computers to the zone", "Remove computers from the zone" and "Modify computer profiles"
    Access Manager - delegation of computer ops.jpg
    This step provides the assurance that the account can't perform any other operations.
    To find the delegation wizard, right-click the zone and select "Delegate Zone Control"
  4. Generate the Key Table file (keytab)
    In a Centrified system, issue the adkeytab command with the adopt option.  For the example above:
    $ dzdo /usr/sbin/adkeytab --adopt --user bootcamp.admin --samname ad-joiner --keytab ad-joiner.keytab  -V "AD Joiner Service Account"
    - I used dzdo (as root) so the key table is owned by root
    - The adopt option tells adkeytab to adopt an existing AD account (this will randomize the password of the account)
    - The user has to be an AD account that has privileges over the ad-joiner account (in my case a Domain Admin)
    - The samname option is required because the account name and the Container Name (cn) are different.
    - The keytab option specifies the name of the key table file  (ad-joiner.keytab),
    - V (or --verbose) requests verbose output.
    - The final string "AD Joiner Service Account" is the container name (CN) for the account in this example.

Tools for your Image (one-time for each template)


Kerberos configuration file and Keytab

Obtain a krb5.conf file from a working system in the same environment.  This step is non-trivial in an elastic environment.  The krb5.conf file to be used has to have entries for a single or a set of domain controllers that you expect to stick around otherwise, if you decommision the DCs, the automation scripts will break because you won't be able to get a Ticket-Granting-Ticket.


Centrify Bits

In this example, only the Centrify standard agent is installed.  Installation does not mean "joined"


Utility Scripts (examples for this use case)

a) Renaming your system  (not centrify-related, but relevant)
This depends on the platform and utilities that you have, should be part of your orchestration.  In my case, in AWS the naming convention provides a hostname tied with the internal IP address (ip-12-34-56-78).  I am using the user data field of the image customization to rename the system to a combination of the prefix "aws" and the instance ID.  This will keep the names within the 15 character legacy limitation.



# Initialize data and obtain information from AWS metadada
INSTANCEID=`/usr/bin/curl && echo`
IPV4=`/usr/bin/curl && echo`

# Modify hostname 
hostname $HOSTNAME
echo $HOSTNAME > /etc/hostname

# Change Settings in CentOS platform
printf "NETWORKING=yes\nHOSTNAME=$INSTANCEID\nNOZEROCONF=yes\n" > /etc/sysconfig/network

# Add fqdn to hosts file
cat /etc/hosts
# This file was modified by the user-data postscript localhost

service network restart


b) Joining AD

The steps here are straightforward, the only unique steps is that we are obtaining a TGT for the ad-joiner account so the kerberized adjoin command can pick-up the credentials (hence the need of no passwords).  In this particular case, we also add it to the Web Servers computer role, therefore this script is image-specific.  This can be improved be improved.



echo "Obtaining TGT ..."
sleep 1
env KRB5_CONFIG=/centrify/scripts/krb5.conf  /usr/share/centrifydc/kerberos/bin/kinit -kt /centrify/scripts/ad-joiner.keytab ad-joiner
sleep 1

echo "Joining the domain"
adjoin -z Global -c "ou=servers,ou=centrify,ou=bootcamp"
sleep 10

echo "Joining the Web Servers Computer Role"
sh  adedit /centrify/scripts/add-member.tcl -d `adinfo -d` -n `adinfo -n` -r webservers
sleep 2

echo "Flushing the Cache"
/usr/sbin/adflush --force
# Older versions of CDC required restart
#/etc/init.d/centrifydc restart

echo "Destroying Kerberos Tickets"

echo "Complete."


c) adedit script

Important:  As of release 2015.1 (5.2.3) of the UNIX agent, adjoin now supports the --computerrole parameter, this completely eliminates the step below.
Note that the script above makes a call-out to a TCL script and passes the domain name (-d output of adinfo -d), name of the system (-n output of adinfo -n), and the type of server (webservers).  This script is obviously not optimized, but contains the basic functionality which is to bind to the domain, and use the add_user_to_group function to add the computer object to the target group.  Note that the name is also static, so it's image-specific for Web Servers.

package require ade_lib
proc usage {msg} {
puts {usage: -d  [-n ] [-r ]}
puts $msg
exit 1
if {[getopt argv -d domain] == 0} {
usage "You MUST kinit before this utility!  Also, missing arguments (domain); eg.  -d -n system-01 -r webserver"

if {[getopt argv -n name] != 0} {
if {[getopt argv -r role]} {
bind $domain
set shortname [string trimright $name $domain ]$
set rolegroup "centrify-global-unix-cr-$role"

add_user_to_group $shortname\@$domain $rolegroup\@$domain

puts Complete.

As a matter of fact, this is a modified version of one of the sample scripts included in the adedit guide.


c) Cleanup script

Just like the joining script, this one cleans up the AD objects (computer object, zone profile, etc); the expectation is that this script will be used when instances are being decommisioned.


echo "Obtaining TGT ..."
sleep 1
env KRB5_CONFIG=/centrify/scripts/krb5.conf  /usr/share/centrifydc/kerberos/bin/kinit -kt /centrify/scripts/ad-joiner.keytab ad-joiner
sleep 1

echo "Leaving the domain"
adleave -r

sleep 2

echo "Destroying Kerberos Tickets"

echo "Complete."


Checking the Results

(This is a 2-video 15 minute playlist)


Part 1 - Description of the Scenario (image launched)

Part 2 - Verification  (you can jump to this one if you understand the scenario)

  • Start-up an Instance in AWS
  • Rename the system
  • Join AD
  • Join a Centrify HZ Zone
  • Add the System to a Computer Role
  • Attest that the right people have access
  • Decommission the Instance, and cleanup.



There's a lot of improvements to be made to this, starting with the scripts, perhaps they can have error handling and logic to be used in different image templates;  Ultimately the key concepts with Centrify are the same:

- AD connectivity

- DNS settings on the UNIX/Linux hosts

- Obtain a TGT of the account with the proper rights

- Perform the operations required (add/moves/changes) with the Centrify tools


Remember there are multiple avenues for automation: 
On UNIX & Linux: CLI tools, adedit

On Windows:  Centrify PowerShell Modules and the DirectManage/Audit SDK