Automation - Adding a UNIX/Linux system to a Centrify Computer Role in Private/Public cloud scenarios

Background

Note from July 2015:  With the release of Centrify Suite 2015.1 (agent 5.2.3) adjoin has been modified to add the --computerrole parameter;  this in effect eliminates the need for the steps below.  I will leave the article intact for historical reasons, but if you're at 5.2.3 or above you don't need to do this anymore.

Back in August 2014, I wrote a blog posting illustrating how to use Centrify Kerberos tools like adkeytab to assist in automation scenarios while maintaining the least privilege model and separation of duties.

I also put together a consolidated post here: http://community.centrify.com/t5/Get-Started-How-To-s/HOWTO-Use-Centrify-Tools-for-Public-Private-Cloud-Automation/ba-p/20369

This post extends the use case to add the system to a computer role after the system ins joined.  As you know Centrify computer roles are a powerful way to group systems by adding them to AD security groups.  This increased flexibility allow for groupings of servers within zones.  When combining the knowledge of the original post and this one, you can accomplish the following:

• Launch a UNIX/Linux template used in a private or public cloud scenario.
• During post-installation, the system joins a zone and a computer role automatically without human intervention.

Variables:  

• Domain to be joined
• Zone to be joined
• Computer role(s) to be joined

These parameters need to be passed to your automation or orchestration solution (or be part of your template for that type of system).

Implementation

Modifying the automation account permissions to add accounts to groups

So far, the automation account (ad-joiner in our example) only has the rights to add/move/change AD computer objects in an OU and to add/move/change computers in to the Centrify zone.  We will grant this account the ability to add/move/change members of groups that are in a specific OU.   In keeping with the least privilege model, we need to provide the account only the privileges it needs.

Like the previous example, we'll use the AD delegation wizard in the OU that contains the AD groups that are used to contain Centrify Computer Roles.  There is already a canned delegation task that suffices "Modify the membership of a group" 

Note:  this is a one-time process.

Adding the system to the appropriate Computer Role

There are several ways to accomplish this because ultimately the action is to add a computer object to an active Directory group.

In UNIX/Linux, using adedit, it's as simple as illustrated in this example ( 5 lines)

$ adedit  

# this opens the adedit TCL utility

> bind corp.centrifying.net   

# binds to the corp.centrifying.net domain or returned by adinfo -d

> package require are_lib  

# loads the required libraries

> add_user_to_group awscentos01$@corp.centrifying.net centrify-global-unix-cr-webservers@corp.centrifying.net 

# adds the awscentos01 computer object (append a $ to the output of adinfo -n) and joins it to the centrify-global-unix-cr-webservers AD group (you can pass as parameter or have as part of the template)

$ adflush 

# flushes the cache to the access controls are updated.  In older versions of the Centrify agent, this required a service restart so the machine re-authenticated against AD and refreshed the ACLs.

Notes:  

1. This is the process that will repeat each time an instance is built.
2. This is also the area that I've found that many prospects and customers encounter challenges.  Success in these cases has to do with simplicity and standardization.  For example, if I have a naming convention and I'm adhering to the best practices (e.g. a separate OU to store AD computer groups) then the logic of my script is very simple.  If I have NOT standardized and I have a centralized AD mess (or even worse, classic zones), then this will increase complexity significantly.
   For example.  If I'm using a script that expects 3 variables:
   - AD domain,
   - Hostname:  keep in mind, you can join a system to AD with one name, but the local honstname is different
   - Type of Server:  (e.g. database server, web server, PCI server, etc)
   In a standardized environment you can afford to get those variables from the output of some of the centrify or environment variables.  E.g.
   
   sh adedit /tools/scripts/add-member.tcl -d `adinfo -d` -n `adinfo -n` -r `echo $SERVERTYPE`

Alternative method - Using PowerShell

In the case you have multiple automation avenues, you can perform the same tasks above with PowerShell.

Import-Module ActiveDirectory 

# loads the required PowerShell Module
Get-ADGroup  centrify-global-unix-cr-webservers | Add-ADGroupMember -Members (Get-ADComputer -filter 'samAccountName -like "awscentos01$"') 

# Gets the centrify-global-unix-cr-webservers AD group and adds a member which is the the awscentos01 computer object.

Note:  Always perform cleanup after you're done.  Keytabs should be handled with the same sensitivity as private keys.

Implementation

Putting it all together in an AWS scenario (2 videos ~16 mins)

Description:


Verification