Showing posts with label YUM. Show all posts
Showing posts with label YUM. Show all posts

Wednesday, March 16, 2016

Deploy Centrify and Join Active Directory automatically using a stand-alone Puppet script

A few months ago I published a post titled "Deploy Centrify and Join Active Directory with a simple Chef Recipe" as customary, after I get asked about something 3 times, it's time to create a post, but now using Puppet by PuppetLabs.  This post is identical to the Chef post, just different tools.

Disclaimers and Acknowledgements
  • This article provides a "quick basic configuration";  in a true deployment you have to account for high-availability, replication, security, package integrity, supported platforms, supported versions, change control, etc. 
  • All names, logos and trademarks used in this articles correspond to their existing owners.
  • I'm not Puppet, Chef or Bladelogic subject-matter experts, hence the use of a stand-alone script or recipe. 
  • Puppet Master server/slaves/node architecture is outside the scope of this post
  • This would not be possible without my customers/prospects asking and the tutorials available online.  Some great resources:
    - Introduction to Puppet:  https://docs.puppetlabs.com/guides/introduction.html
    - Willams' blog post "How to install Puppet in Stand-Alone mode on CentOS7"
    - Kudos to MaestroDev for the wget Puppet extension: https://forge.puppetlabs.com/maestrodev/wget
What is required?
  • An Active Directory domain
  • A Centrify zone (optional - if using Centrify in licensed mode/privilege management)
  • A Centrify zone and a Computer Role  (optional)
  • An Active Directory service account for joins and removals, plus a keytab for the account and a usable krb5.conf file.  Read this article if you want to know how to create the service account and obtain the keytab.
  • A RHEL-based system with enough storage for the Centrify RPM packages for each platform (or just for the subset you need to support).  This system has to be set up as a YUM repository, as described in the the original orchestration article.
  • A second RHEL-derivative system to install Puppet (see below), this system must have DNS settings configured correctly.
Note:  Although it's possible for you to follow this and put together a working prototype, I strongly-encourage that you really explore the concepts  of DevOps/infrastructure as code.  The whole philosophy promotes constant improvement, this means that if you expect this to be a "set it and forget it" solution, I advise that you realign your expectations.

Finally, By no means what's outlined here is ready for production.  Check out the reading list below.

Example Diagram
Chef Blog - Diagram.png

Implementation Steps

Planning
The goal of this lab is to be able to deploy the Centrify bits in a RedHat, CentOS, Scientific or Oracle system in a consistent way.  Also, if you know what you're doing, you can extend this to other OSs, and platforms as well.

The 'core' process without checking for major dependencies or issues is to:
  1. Install Centrify DirectControl
  2. Authenticate against Active Directory with an account with minimal rights
  3. Join Active Directory
Building Blocks
  • YUM Repository with Centrify RPMs (detailed instructions here)
  • AD account + keytab (steps outlined in a previous post)
  • Usable krb5.conf:  You can copy this file from any Centrified system; however, depending on where you're onboarding the system, you want to edit the file only with the DCs that are reachable to the new system.

Make the krb5.conf and service account keytab available to your infrastructure
In the original article, we piggy-backed on the Apache webserver as the transport for our repository.  Now we're going to create another folder for utilities (utils for short) and copy the keytab and krb5.conf file.
If you prepared this for the Chef article, you can skip to Puppet installation.

  1. Create a folder under /var/www/html
    $ sudo mkdir /var/www/html/centrify/utils
  2. Copy the RPMs to the folder.$ cd /path/to/files
    $ sudo mv krb5.conf  /var/www/html/centrify/utils
    $ sudo mv ad-joiner.keytab  /var/www/html/centrify/utils
  3. Set the proper permissions in the folder
    chmod -R ugo+rX /var/www/html/centrify/utils
  4. Verify that the files are accessible via the web server (you may have to check the firewall settings)
    utils.PNG

Install Puppet and the wget Extension
  1. Add the Puppet repository (you must find the proper repository for your RHEL version, version 7 shown)
    $ sudo rpm -ivh http://yum.puppetlabs.com/puppetlabs-release-el-7.noarch.rpm
  2. Install the bits
    $ yum install puppet
  3. Make sure your system's DNS settings are up to date (yes, no "localsystem.localdomain")
    Can you ping your own system by name and FQDN?
    What is the output of the hostname command?
    Run this:
    facter | grep hostname
    facter | grep fqdn
    if the output isincorrect, you must edit the /etc/hosts and /etc/resolv.conf and speak to your DNS admin to set things straight
  4. Logout and log back in to verify the ruby path
    $  sudo puppet module install maestrodev-wget
    You should be ready to get going.
Create and test your stand-alone Puppet Script
To recap, the sequence to automate Installation and joins is as follows:
  1. Retrieve a usable krb5.conf file
  2. Retrieve the keytab of a valid service account with minimum rights to join systems to the target AD OU, to the target zone (if using in zone mode) and if adding to a Computer role, with rights to add to the target AD groups.
  3. Install the Centrify Package and use the kinit tool to obtain a TGT
  4. Run adjoin with the proper options.
  5. Perform cleanup

Here is the Non-idenpotent Puppet Script:

# This stand-alone recipe will install the Centrify Agent on RHEL derivatives, 
# joins Active Directory and places the system in a Computer Role
# Notes: This recipe is not idempotent (achieving this is up to you!)

include wget

# Variables for my environment (see blog post)
# domain is the most basic parameter to join Active Directory

$adname = "centrify.vms"  
# Notice that I could not use "domain" like in the Chef example.  
# That word seems to be reserved in Puppet

# In Zone Mode (licensed with UNIX identity and Access Control) the zone
# parameter corresponds is where the system will be placed.  Not needed
# if working in workstation or express mode.

$zone = "Global"

# OU is where your computer object will be placed in Active Directory
# your ad-joiner account should be able to join systems to this container

$ou = " ou=servers,ou=unix"

# A Computer role is one of the ways to group systems and define access 
# control.  A system may be a member of multiple computer roles.  
# E.g.  a LAMP system may be accessible by Web Admins, Developers and 
# DBAs with different access rights and privileges.

$crole = "App Servers"

# nodes are the managed system in Puppet;  in a true deployment you can
# apply to individual systems or collections of systems.  Since this is not
# idempotent, you must specify the fqdn.

node "your-system-fqdn" {

# Centrify's utilities are Kerberized, this means that they will use the current
# user's Kerberos TGT to attempt the transaction against AD.  However, in a 
# virgin system, there are no working krb5.conf files, therefore kinit won't know
# how to find a KDC to authenticate against.  This is why we need a krb5.conf 
# file from a working system (or that points to a reachable Domain Controller), 
# in the previous blog entry, we piggy-backed on an Apache Web server to 
# serve those files (engcen6).

wget::fetch {"download a working krb5.conf":
  source             => 'http://engcen6.centrify.vms/centrify/utils/krb5.conf',
  destination        => '/temp/krb5.conf',
  timeout            => 0,
  verbose            => true,
  nocheckcertificate => true,
  before => Exec["kinit"]
}

# The keytab corresponds to a service account that has the minimal rights, in 
# this case, the rights to write a computer object in the designated container 
# (ou), centrify zone and the AD group that contains the "App Servers"computer
# role needless to say, you need to treat this file with care and if possible, 
# remove when complete.

wget::fetch {"download the ad-joiner keytab file":
  source             => 'http://engcen6.centrify.vms/centrify/utils/ad-joiner.keytab',
  destination        => '/temp/ad-joiner.keytab',
  timeout            => 0,
  verbose            => true,
  nocheckcertificate => true,
  before => Exec["kinit"]
}

# We leverage Puppet to ensure the files are present. This will be used later
# to guarantee proper sequencing.

file {"ad-joiner.keytab":
  ensure => present,
  path   => '/temp/ad-joiner.keytab'
}

file {"krb5.conf":
  ensure => present,
  path   => '/temp/krb5.conf'
}

# In this command, we authenticate against AD with the keytab of our service 
# account.  Note that we are using the usable krb5.conf file so kinit can reach
# a KDC (domain controller).  The end-result is that root (or sudo) user will
# have a TGT and you don't need to put keys, hashes or passwords in your 
# script.  The before/subscribe and require Puppet directives guarantee proper 
# sequencing.

exec {"kinit":
  command =>  "/bin/env KRB5_CONFIG=/temp/krb5.conf /usr/share/centrifydc/kerberos/bin/kinit -kt /temp/ad-joiner.keytab ad-joiner",
  before => Exec["adjoin"],
  subscribe => [
        File["/temp/ad-joiner.keytab"],
        File["/temp/krb5.conf"],
  ],
  require => Package["CentrifyDC"],
}


# In a pre-requiste blog entry, I outlined how to create a YUM repository for 
# RHEL and derivatives.  This means that you need a yum or apt repo with 
# the Centrify packages.  Puppet will simply make sure the package is present
# notice the differences, I declared this after the previous directives, when
# the package is a pre-requisite.

package {"CentrifyDC":
    ensure => 'installed',

}

# Finally we run adjoin.  At this point we are using the variables from my 
# environment.  Although in doing so, we broke the 'idempotent principles, I'm 
# certain that Puppet experts can find ways to improve on this.  

exec { "adjoin":
  command => "/usr/sbin/adjoin -z $zone -c $ou -R \"$crole\" -V $adname",
  require => Package["CentrifyDC"]

}

# In the cleanup phase, we clear the TGT and delete the utility files
# Although the keytab provides very specific limited AD rights, always make
# a habit of cleaning-up.

exec {'kdestroy':
  command => '/bin/env KRB5_CONFIG=/tmp/krb5.conf /usr/share/centrifydc/kerberos/bin/kdestroy',
  require => Exec['adjoin'],
}

exec {"/bin/rm -f /temp/*":
  require => Exec['kdestroy'],
}

} # End of Script


Review the results
$ sudo puppet apply centrify-build.pp
Notice: Compiled catalog for engcen7.centrify.vms in environment production in 1.77 seconds
 Info: Applying configuration version '1458157258'
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Package[CentrifyDC]/ensure: created
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[krb5.conf]/ensure: created
 Info: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[krb5.conf]: Scheduling refresh of Exec[kinit]
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Wget::Fetch[download a working krb5.conf]/Exec[wget-download a working krb5.conf]/returns: executed successfully
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[ad-joiner.keytab]/ensure: created
 Info: /Stage[main]/Main/Node[engcen7.centrify.vms]/File[ad-joiner.keytab]: Scheduling refresh of Exec[kinit]
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Wget::Fetch[download the ad-joiner keytab file]/Exec[wget-download the ad-joiner keytab file]/returns: executed successfully
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kinit]/returns: executed successfully
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kinit]: Triggered 'refresh' from 2 events
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[adjoin]/returns: executed successfully
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[kdestroy]/returns: executed successfully
 Notice: /Stage[main]/Main/Node[engcen7.centrify.vms]/Exec[/bin/rm -f /temp/*]/returns: executed successfully
 Notice: Finished catalog run in 38.32 seconds

Verification Video


Saturday, November 28, 2015

Deploy Centrify and Join Active Directory automatically with a simple Chef recipe

Background
This article provides a quick-and-dirty Chef recipe that deploys the Centrify agent, authenticates against AD, joins Active Directory, joins a Centrify zone and a computer role.  This article is a modified version of a Centrify community post I authored.

Disclaimers
  • This article provides a "quick basic configuration";  in a true deployment you have to account for high-availability, replication, security, package integrity, supported platforms, supported versions, change control, etc. 
  • All names, logos and trademarks used in this articles correspond to their existing owners.
  • We are not YUM or Chef subject-matter experts.  This would not be possible without the excellent tutorials provided by Chef Software.
What is required?
  • An Active Directory domain with a zone (you can make it work in workstation/express mode)
  • A Centrify zone and a Computer Role  (optional)
  • An Active Directory service account for joins and removals, plus a keytab for the account and a usable krb5.conf file.  Read this article if you want to know how to create the service account and obtain the keytab.
  • A RHEL-based system with enough storage for the Centrify RPM packages for each platform (or just for the subset you need to support).
    This system has to be set up like the original article with a YUM repo and the Centrify bits.
  • A second RHEL-derivative system with the ChefDK installed to test the recipe locally.
    To download the ChefDK, go to this site:  https://downloads.chef.io/chef-dk/
Note:  Although it's possible for you to follow this and put together a working prototype, I strongly-encourage that you really explore the concept of infrastructure as code.
Finally, By no means what's outlined here is ready for production.  Check out the reading list below.

Example Diagram
Chef Blog - Diagram.png

Implementation Steps

Planning
The goal of this lab is to be able to deploy the Centrify bits in a RedHat, CentOS, Scientific or Oracle system in a consistent way.  The 'core' process without checking for major dependencies or issues is to:
  1. Install Centrify DirectControl
  2. Authenticate against Active Directory with an account with minimal rights
  3. Join Active Directory
Building Blocks
  • YUM Repository with Centrify RPMs (completed in the previous lab)
  • AD account + keytab (steps outlined in a previous post)
  • Usable krb5.conf:  You can copy this file from any Centrified system; however, depending on where you're onboarding the system, you want to edit the file only with the DCs that are reachable to the new system.

Make the krb5.conf and service account keytab available to your infrastructure
In the original article, we piggy-backed on the Apache webserver as the transport for our repository.  Now we're going to create another folder for utilities (utils for short) and copy the keytab and krb5.conf file.

  1. Create a folder under /var/www/html
    $ sudo mkdir /var/www/html/centrify/utils
  2. Copy the RPMs to the folder.$ cd /path/to/files
    $ sudo mv krb5.conf  /var/www/html/centrify/utils
    $ sudo mv ad-joiner.keytab  /var/www/html/centrify/utils
  3. Set the proper permissions in the folder
    chmod -R ugo+rX /var/www/html/centrify/utils
  4. Verify that the files are accessible via the web server (you may have to check the firewall settings)
    utils.PNG
Perform a basic installation of the ChefDK
  1. Go to https://downloads.chef.io/chef-dk/  and download the latest ChefDK bits.
  2. Install the bits
    $ dzdo rpm -Uvh chefdk-0.10.0-1.el7.x86_64.rpm
  3. Set the ruby path to the Chef-provided version
    $ echo 'eval "$(chef shell-init bash)"' >> ~/.bash_profile
  4. Logout and log back in to verify the ruby path
    $  which ruby
    /opt/chefdk/embedded/bin/ruby
Create and test your stand-alone Chef Recipe
  1. Create a file
    $ vi install-centrifydc.rb
    Here are the contents of my file
    # This stand-alone recipe will install the Centrify Agent on RHEL derivatives, 
    # joins Active Directory and places the system in a Computer Role
    # Notes: This recipe is not idempotent (achieving this is up to you!)
    
    # Variables for my environment (see blog post)
    # domain is the most basic parameter to join Active Directory
    
    domain = 'centrify.vms'
    
    # in Zone Mode (licensed with UNIX identity and Access Control) the zone
    # parameter corresponds is where the system will be placed
    
    zone = 'Global'
    
    # OU is where your computer object will be placed in Active Directory
    # your ad-joiner account should be able to join systems to this container
    
    ou = 'ou=servers,ou=centrifyse'
    
    # A Computer role is one of the ways to group systems and define access 
    # control a system may be a member of multiple computer roles.  
    # E.g.  a LAMP system may be accessible by Web Admins, Developers and 
    # DBAs
    
    crole = 'PCI Servers'
    
    # In a pre-requiste blog entry, I outlined how to create a YUM repository for 
    # RHEL and derivatives.  This means that you need a yum or apt repo with 
    # the Centrify packages.  Per Chef, the default action will be to install the package.
    
    package 'CentrifyDC'
    
    # Centrify's utilities are Kerberized, this means that they will use the current
    # user's Kerberos TGT to attempt the transaction against AD.  However, in a 
    # virgin system, there are no working krb5.conf files, therefore kinit won't know
    # how to find a KDC to authenticate against.  This is why we need a krb5.conf 
    # file from a working system (or that points to a reachable Domain Controller), 
    # in the previous blog entry, we piggy-backed on an Apache Web server to serve those files.
    
    remote_file '/tmp/krb5.conf' do
      source 'http://linux2.centrify.vms/centrify/utils/krb5.conf'
      owner 'root'
      group 'root'
      mode '0644'
      action :create
    end
    
    # The keytab corresponds to a service account that has the minimal rights, in 
    # this case, the rights to write a computer object in the designated container 
    # (ou) needless to say, you need to treat this file with care and if posible, 
    # remove when complete.
    
    remote_file '/tmp/ad-joiner.keytab' do
      source 'http://linux2.centrify.vms/centrify/utils/ad-joiner.keytab'
      owner 'root'
      group 'root'
      mode '0644'
      action :create
    end
    
    # In this command, we authenticate against AD with the keytab of our service 
    # account.  Note that we are using the usable krb5.conf file so kinit can reach
    # a KDC (domain controller).  The end-result is that root (or sudo) user will
    # have a TGT and you don't need to put keys, hashes or passwords in your script.
    
    execute 'kinit' do
      command "env KRB5_CONFIG=/tmp/krb5.conf /usr/share/centrifydc/kerberos/bin/kinit -kt /tmp/ad-joiner.keytab ad-joiner"
    end
    
    # Finally we run adjoin.  At this point we are using the variables from my 
    # environment.  Although in doing so, we broke the 'idempotent principles, I'm 
    # certain that Chef experts will understand how to implement an independent cookbook
    
    execute 'adjoin' do
       command "/usr/sbin/adjoin -z #{zone} -c #{ou} -R \"#{crole}\" -V #{domain}"
    end
    
    
    # Cleanup
    execute 'kdestroy' do
      command "env KRB5_CONFIG=/tmp/krb5.conf /usr/share/centrifydc/kerberos/bin/kdestroy"
    end
    
    file '/tmp/ad-joiner.keytab' do
       action :delete
    end
    
    file '/tmp/krb5.conf' do
       action :delete
    end
  2. Verify the recipe
    $ sudo chef-apply install-centrifydc.rb
    Recipe: (chef-apply cookbook)::(chef-apply recipe)
      * yum_package[CentrifyDC] action install
        - install version 5.2.3-429 of package CentrifyDC
      * remote_file[/tmp/krb5.conf] action create
        - create new file /tmp/krb5.conf
        - update content in file /tmp/krb5.conf from none to 186d5f
     [truncated]
      * execute[kinit] action run
        - execute env KRB5_CONFIG=/tmp/krb5.conf /usr/share/centrifydc/kerberos/bin/kinit -kt /tmp/ad-joiner.keytab ad-joiner
      * execute[adjoin] action run
        - execute /usr/sbin/adjoin -z Global -c ou=servers,ou=UNIX -R "App Servers" -V centrify.vms
    

Verification Video



Adjustments
There are absolutely many improvements that can be made.   Here are a few that come to mind (in no specific order):

  • Check for Perl:  CentrifyDC requires Perl 5.8 and up.
  • Chek for DC connectivity:  You can potentially check for connectivity to KDCs prior to attempting to authenticate.
  • Inspect the name of the system:  In keeping with AD Naming conventions, we should check for length and uniqueness in the forest prior to join.
  • Check if the system is already joined or in the desired zone/forest.
  • Inspect the IP/DNS configuration:  Maybe the TCP/IP and DNS config is not right.
  • Perform a Dynamic DNS update using addns:  After join, you can use addns to get the system registered with Microsoft DNS
  • Obtain Certificates with ADCert:  If the system is used for SSL communications, you can get the cert manually using adcert.
  • Manage centrifydc.conf:  There are some basic parameters that may not be manageable via GPO (e.g. DMZ) that can be managed from there.
  • New Information:  Centrify DirectControl can provide information to Chef regarding the AD topology.
  • Add dependent packages:  LDAP Proxy or Centrify DirectAudit/DirectSecure come to mind.
  • Most importantly:  This requires a cookbook!  Make it as idempotent as possible!

Reading List
Although any capable IT admin is able to spend a few hours and make something like this work, my advice is to explore deeper the concepts around 'Infrastructure as Code'; I'm of the opinion that it's a game-changing paradigm.  I recommend (still reading):
  • RESTFul Web APIs (Richardson)
  • Test-Driven Infrastructure with Chef (Nelson-Smith)
  • Learn Chef Tutorials at (http://learn.chef.io)
For a "removal" recipe, see the this Centrify Community post.

Saturday, November 14, 2015

Setting up a simple YUM repository to deploy Centrify for RHEL and derivatives

Background
The foundation to many deployment or orchestration tools is to have private hosted repositories of source installation packages.  Centrify offers native packages for all the supported platforms.  In addition, Centrify also offers install.sh;  this script and the answer files can abstract the underlying package manager for UNIX, Linux or Mac systems.
 Install.sh - Benefits.jpg

This means that you can use an NFS Server, a Samba Server, a Web Server or your package manager in conjunction with the Centrify bits to deploy software easily across your enterprise. Alternatively, the Yellow-Dog Updater Modified (YUM) (and APT) provide a simple to set-up and robust package manager that can be used primarily with RedHat and derivative platforms.

Disclaimers
  • This article provides a "quick basic configuration";  in a true deployment you have to account for high-availability, replication, security, package integrity, supported platforms, supported versions, change control, etc. 
  • All names, logos and trademarks used in this articles correspond to their existing owners.

What is required?
  • A RHEL-based system with enough storage for the Centrify RPM packages for each platform (or just for the subset you need to support).
  • If using web as the delivery mechanism, the web server (Apache) has to be set and configured accordingly.

Example Diagram
repo model.png
In my mock organization, there are different types of RHEL derivatives, including RedHatEnterprise, Fedora, Oracle, Scientific Linux, etc, all running on different architectures, including Intel (32 and 64 bit) ,  zLinux IBM s390, Itanium and IBM Power processors.

Implementation Steps

Verify pre-requisites.  I'm planning to use http as the transport for my repo.

# Check if Apache is installed
$ sudo  yum list installed | grep httpd
httpd.x86_64            2.2.15-47.el6.centos
httpd-tools.x86_64      2.2.15-47.el6.centos
# If not present
$ sudo yum install httpd
$ sudo chckconfig httpd on
$ sudo service httpd start
Install the createrepo package
$ sudo yum install createrepo
Download the Centrify Bundle for the platforms to be supported.
Example data: in my mock organization,  I will be supporting the bits for 2014.1 and 2015.1.  This organization has a policy to only deploy maintenance releases.

  1. Go to the Centrify Customer Center and Navigate to the Downloads Section.
  2. Identity the bundle for 2015.1 and 2014.1:
    bundle.PNG
    The bundle is available in ISO or ZIP formats.
  3. Copy and unzip the bundle in a staging server.  Note that ALL the platforms are present.  We are only interested in the .TGZ files that contain the word "rhel" in the name.
    centrify-suite-2015.1-rhel4-i386.tgz      <= this is for Intel x86
    centrify-suite-2015.1-rhel4-ia64.tgz      <= this is for Itanium
    centrify-suite-2015.1-rhel4-ppc.tgz       <= this is for Power
    centrify-suite-2015.1-rhel4-x86_64.tgz    <= this is for Intel x64
    centrify-suite-2014.1-rhel5-s390x.tgz     <= this is for zLinux
  4. Gunzip and untar all those files (using tar xzvf package-name.tgz).  You will see RPMs for all the software included.  Here's a description of all packages:
    CentrifyDA is the audit agent, only used with Enterprise Edition or Privilege Service.
    CentrifyDC is adclient; can be used in Express mode or Zone mode (licensed)
    CentrifyDC is absolutely the only package required in most scenarios. Any other package, and you're in the land of "you must know what you're doing"
    CentrifyDC-ldapproxy is the Centrified OpenLDAP Server - required to support filers or older apps over LDAP interfaces
    CentrifyDC-nis is another proxy.  It exists to support legacy  NIS scenarios.  Needless to say, this is a transitional package, using NIS is a bad idea and will lead to audit comments.
    CentrifyDC-openssh is our provided version of OpenSSH; since SSH has matured to provide PAM, GSSAPI and even Kerberos support, 80% of the time is not needed, however, if you have an older UNIX or are in a complex AD, this package can be your friend.
Example data: If we follow the example, there should be 5 RPM packages for each of the different architecture.  However, since there's variability on the s390 package releases, I ended up with 38 packages.

Tip: use the rpm -qpil command to inspect them.  You'll see that they are very well docummented.

Copy the Centrify RPMs to the target location and verify access
In my over-simplistic example, we'll piggy-back on the default website.
  1. Create a folder under /var/www/html
    $ sudo mkdir /var/www/html/centrify
  2. Copy the RPMs to the folder.$ cd /path/to/centrify/staging
    $ sudo mv * /var/www/html/centrify
  3. Set the proper permissions in the folder
    chmod -R ugo+rX /var/www/html/centrify
  4. Verify that the files are accessible via the web server (you may have to check the firewall settings)
    webworks.PNG
Create your Repository
  1. Use the createrepo command to create the repository
    $ sudo createrepo --database /var/www/html/centrify
  2. Update the repository database
    $ sudo createrepo --update /var/www/html/centrify
    Spawning worker 0 with 38 pkgs
    Workers Finished
    Gathering worker results 
Create your repository's configuration file
In this simple configuration, we ended-up with this file (centrify.repo):

[centrify]
name=centrify
baseurl=http://linux2.centrify.vms/centrify
enabled=1
gpgcheck=0
Note:  We are adding a keytab from a least privilege AD user that can only perform the join (or leave).  This will ensure that we don't need to put any passwords, keys or hashes in our provisioning script.  For more information on how to create the AD account and corresponding keytab, see this article.

Verify that your Repository is working
  1. Log in to a test system, copy or create the centrify.repo file in the /etc/yum.repos.d folder
    $ sudo cp /path/to/centrify.repo /etc/yum.repos.d/centrify.repo
  2. Checking package availability and Metadata
    $ sudo yum install centrifydc
    No package centrifydc available.
      * Maybe you meant: CentrifyDC
    # This verifies that our metadata is OK.
  3. More information about CentrifyDC (the base package) - output truncated.
    $ sudo yum info CentrifyDC
    Available Packages
    Name        : CentrifyDC
    Arch        : i386
    Version     : 5.2.3
    Release     : 429
    Size        : 25 M
    Repo        : centrify
    Summary     : Centrify DirectControl Agent
    URL         : http://www.centrify.com/
    License     : Copyright (C) 2004-2015 Centrify Corporation
    Description : RPM to install Centrify DirectControl on Linux x86 platforms.
    
    Name        : CentrifyDC
    Arch        : x86_64
    Version     : 5.2.3
    Release     : 429
    Size        : 34 M
    Repo        : centrify
    Summary     : Centrify DirectControl Agent
    URL         : http://www.centrify.com/
    License     : Copyright (C) 2004-2015 Centrify Corporation
    Description : RPM to install Centrify DirectControl on Linux x86_64 platforms.
    
    Note that I can see that the lastest version is available for two platforms that may apply to my system.
  4. Let's verify the integrity of dependencies (LDAP Proxy depends on DirectControl)
    $ repoquery --requires CentrifyDC-ldapproxy
    /bin/sh
    CentrifyDC <= 5.2.3-999
    CentrifyDC >= 5.2.3-000
    /bin/sh
    CentrifyDC <= 5.2.3-999
    CentrifyDC >= 5.2.3-000
    
  5. Let's install DirectControl
    $ sudo yum install CentrifyDC
    
    Resolving Dependencies
    --> Running transaction check
    ---> Package CentrifyDC.x86_64 0:5.2.3-429 will be installed
    --> Finished Dependency Resolution
    
    Dependencies Resolved
    
    ================================================================================
     Package             Arch            Version            Repository         Size
    ================================================================================
    Installing:
     CentrifyDC          x86_64          5.2.3-429          centrify           34 M
    
    Transaction Summary
    ================================================================================
    Install       1 Package(s)
    
    Total download size: 34 M
    Installed size: 87 M
    Is this ok [y/N]:

Putting it All Together
Ultimately, there are 3 operations to onboard a Centrify system in AD.
  • Get the package and install it  [we should be good here]
  • Verify that the system is ready to join  (OS check, Perl, inspect DNS, check for communicaton with AD)
    [read below note #1]
  • Use the adjoin command to activate DirectControl and join AD.
    [read below note # 2]
Note # 1:  With YUM you have a reliable way to get the packages across for multiple RHEL derivatives;  however, your logic should include adcheck in the mix if you're not using an enterprise image.  Ideally you would always do QA and use supported platforms and have a standard DNS configuration that includes the ability to get an authoritative response from a Domain controller.  If that's the case, and there are no firewalls in-between, adjoin should just work.

Note # 2:  We have covered adjoin extensively; keep in mind that it is Kerberized and it won't require a password to work.   Its counterpart (adleave) will work the same way, and it's essential for cleanup and releasing of licenses (otherwise they will count for 45 days against your usage).

The ultimate automation script should contain just 3 lines:
  1. yum install CentrifyDC
  2. kinit to authenticate to authorized AD user
  3. adjoin
In my example:

$ yum install CentrifyDC
$ env KRB5_CONFIG=/temp/krb5.conf /usr/share/centrifydc/kerberos/bin/kinit 
-kt /temp/ad-joiner.keytab ad-joiner
$ adjoin --zone Global --container "ou=servers,ou=centrifyse" 
--computerrole "PCI Systems" centrify.vms

Verification Video (5 minutes, 10 seconds)



Appendix:  Flipping the script - deprovisioning

In elastic environments, decommisioning a system  (or 'Terminating' in AWS lingo) has a Centrify implication;  it has to do with proper Active Directory hygiene and licensing purposes(*).  The proper way to leave the domain is to use the remove option of the adleave command.   Based on my example, If I wanted to leave the domain and uninstall Centrify here's the sequence:
  1. kinit to an account that is authorized to remove the computer from the domain
  2. use the adleave -r command
  3. optional:  use yum erase CentrifyDC
In my example:


$ env KRB5_CONFIG=/temp/krb5.conf /usr/share/centrifydc/kerberos/bin/kinit 
-kt /temp/ad-joiner.keytab ad-joiner
$ adleave --remove
$ yum erase CentrifyDC

 (*) If you don't use the "--remove" option with adleave, you are creating an orphaned object in the zone and a computer object that is disabled.  It takes 45 days for the Centrify consoles to consider this system as inactive;  inactive systems don't count against your Centrify license counts.  You can run the Analyze tool to find and clean orphaned and tombstoned objects.

This article was originally posted for the Centrify Community here:
http://community.centrify.com/t5/Get-Started-How-To-s/bg-p/GetStartedHow