Monday, December 28, 2015

Centrify Server Suite 2016 - New Features in Action

Centrify Server Suite 2016 - New features, New Platforms, New Possibilities

Just in time for the Holidays and the New Year Centrify delivered Server Suite 2016;  this release is focused on unleashing the power of the Centrify Platform:
a) Server Suite
b) Identity Service
c) Privilege Service
As well as continuing to delight customers and prospects.

Here are a few demos:

Step-Up Authentication (+ CIS)

Reporting Services (+SSRS)

Local UNIX User and Group Management

Privilege Service Integration - Automation Unleashed

Centrify Start Menu for DirectAuthorize Windows, CLI Tools, PowerShell, GPOs

New Supported Platforms (CDC)

-  Windows 10 (x86_64)
-  Mac OS X 10.11 (x86_64)
-  Fedora 23 (x86, x86_64)
-  CentOS 6.7 (x86, x86_64)
-  Oracle Enterprise Linux 6.7 (x86, x86_64)
-  Red Hat Enterprise Linux Desktop 6.7 (x86, x86_64)
-  Red Hat Enterprise Linux Server 6.7 (x86, x86_64)
-  Red Hat Enterprise Linux Server 6.7 (ppc64 – no Power8)
-  Red Hat Enterprise Linux Desktop 7.2 (x86_64)
-  Red Hat Enterprise Linux Server 7.2 (x86_64)
-  Red Hat Enterprise Linux Server 7.0, 7.1, 7.2 (ppc64 – no Power8)
-  Scientific Linux 6.7 (x86, x86_64)
-  Ubuntu Desktop 15.10 (x86, x86_64)
-  Ubuntu Server 15.10 (x86, x86_64)
-  SUSE Linux Enterprise Desktop 11 SP4 (x86, x86_64)
-  SUSE Linux Enterprise Server 11 SP4 (x86, x86_64, ppc64, ia64)
-  SUSE Linux Enterprise Server 12 (ppc64 – no Power8)
-  Oracle Solaris 11.3 (x86_64, SPARC)







Wednesday, December 16, 2015

Centrify DirectControl for UNIX/Linux/Mac and servicePrincipalNames

Background
IT Ops often ask themselves about servicePrincipalNames in the context of Kerberos and ActiveDirectory.  When a system is Centrified, part of the process is to populate some of these entries to facilitate certain services to "just work";  SPNs play a part on that equation;  however there may be conflicts as well;  many organizations use Centrify software to simplify and secure Hadoop implementations at the OS-layer;  there may be conflicts with other Kerberos-enabled apps as well.  This quick article consolidates the questions that we commonly get as it relates to SPNs and Centrify DirectControl.

What is a Kerberos SPN?
ServicePrincipalName is the name by which a Kerberos client identifies an instance of a service.  The simple format entry in Active Directory looks like this:  service/realm:PORT.  E.g. HTTP/host.example.com

What does this have to do with Centrify?
Centrify uses Kerberos for authentication against Active Directory.  When you join a UNIX, Linux or Mac system into Active Directory using Centrify, there are a set of ServicePrincipalNames defined for the system by default.  Some of these are (varies between platforms). 

afpserver:  for an Apple file server
cifs: for a Samba file server
ftp: for a Kerberos-enabled ftp server
host: for host services like SSHD
http: for Web Servers that use SPNEGO
ipp: for web-based printing
nfs: for Kerberos-enabled NFS

How commonly used are this servicePrincipalNames?
In an Active Directory environment, because it uses Kerberos as the authentication protocol, you interact with Kerberos-enabled services all the time.  As an example, right now, you can connect to a Centrified system using ssh.  When you do, you are getting a service ticket for the HOST service for that system.  You can verify this with the klist command on Windows or in UNIX.    For example:  Diana (dwirth) connects to two centrified systems using PuTTY (engcen6 and linux2); then she opens PowerShell and verifies that she has a service ticket.
Windows PowerShell
Copyright (C) 2014 Microsoft Corporation. All rights reserved.

PS C:\Users\dwirth> klist | sls host

    Server: host/engcen6.centrify.vms @ CENTRIFY.VMS
    Server: host/linux2.centrify.vms @ CENTRIFY.VMS

When does the service registration happen, when I install your CentrifyDC package?
No.  Remember that installing our packages only will place our binaries in your system.  These changes happen when you run the adjoin command OR on the AD side, when you use the "Prepare UNIX computer" option in Centrify Access Manager or when you use the New-CdmManagedComputer PowerShell commandlet.
Access Manager - Precreate SPNs.png
You have a chance to add/remove or modify SPNs during the Pre-Create stage.

Why do you do this?
To make sure that certain common services that rely on Kerberos just work out of the box.

Can I control the behavior of the default SPNs?
Yes.  The adclient.krb5.service.principals parameter takes care of what SPNs are set up in the computer’s AD object and its corresponding system keytab entries. All you need to do is enable the parameter, PRIOR to running adjoin to join AD and only the entries defined will be created by default.  From the Centrify UNIX configuration guide:

"adclient.krb5.service.principals

This configuration parameter specifies additional service principals 
for entries in the Kerberos key table. The key table is populated by 
default with the service principals host, http, cifs, and nfs.
This parameter's value must be one or more principal service names, 
separated by a space or by a comma. For example:

adclient.krb5.service.principals: http ftp cifs nfs

If this parameter is not defined in the configuration file, no 
additional principal names are added to the Kerberos key table."

You can also leverage the Precrate option in Access Manager or the New-CdmManagedComputer PowerShell commandlet.

How can I see the existing registered SPNs for a Centrified system?
On UNIX/Linux/Mac CLI:   Use the “adinfo –C” command from the CLI. 
  1. Make sure you have a current Kerberos ticket. If you get a "cannot bind" error, just kinit and reauthenticate against AD.
$ adinfo -C
Computer Account Diagnostics
  Joined as: engcen6
  Trusted for Delegation: true
  Use DES Key Only: false
  Run adinfo as root to examine local key info
  Key Version: 11   (local key version unavailable)
  Service Principal Names: myservice/engcen6
                           myservice/engcen6.centrify.vms
                           nfs/engcen6.centrify.vms
                           nfs/engcen6
                           ipp/engcen6.centrify.vms
                           ipp/engcen6
                           http/engcen6.centrify.vms
                           http/engcen6
                           host/engcen6.centrify.vms
                           host/engcen6
                           ftp/engcen6.centrify.vms
                           ftp/engcen6
                           cifs/engcen6.centrify.vms
                           cifs/engcen6
                           afpserver/engcen6.centrify.vms
                           afpserver/engcen6

Supported Encryption Type(s): RC4-HMAC
                              AES128-CTS-HMAC-SHA1-96
                              AES256-CTS-HMAC-SHA1-96

Operating System Version: 6.1:6.5 (Final)
From Windows using the CLI:  Use the “setspn.exe –L <hostname>”

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\>setspn -L engcen6
Registered ServicePrincipalNames for CN=engcen6,OU=Servers,OU=centrifyse,DC=cent
rify,DC=vms:
        myservice/engcen6
        myservice/engcen6.centrify.vms
        nfs/engcen6.centrify.vms
        nfs/engcen6
        ipp/engcen6.centrify.vms
        ipp/engcen6
        http/engcen6.centrify.vms
        http/engcen6
        host/engcen6.centrify.vms
        host/engcen6
        ftp/engcen6.centrify.vms
        ftp/engcen6
        cifs/engcen6.centrify.vms
        cifs/engcen6
        afpserver/engcen6.centrify.vms
        afpserver/engcen6
From Windows Using Active Directory Users and Computers

  1. Make sure that the Advanced Features check is set in the View menu.
  2. Find the computer object > right click > Properties > Attribute Editor
  3. In the Attribute Editor, find the servicePrincipalName field.
    ADUC - SPNs.png

What if I need to change the SPNs for an existing system?
There are several ways to do it.  The easiest way to do it is using adkeytab; however if you want this to happen automatically during join, you have to modify the configuration file.
You can also use adleave/adjoin, however this has the drawback that the agent will be disabled temporarily.

Using adkeytab 
To add an SPN to the computer
Example:  adding the oracle service to the shortname engcen6 – notice that you need to be root or elevate to change the system keytab, plus you'll need an AD user that can modify the computer object in AD.
  1. Run “dzdo adkeytab --addspn --principal [principal in correct format] --user [ad-user-that-can-modify-computer-object] --verbose”
    $ dzdo adkeytab --addspn --principal oracle/engcen6 --user dwirth --verbose
    Active Directory Password:
    ADKeyTab version: CentrifyDC 5.2.0-218
    Options
    -------
    use machine ccache: no
    domain: centrify.vms
    server: null
    user: dwirth
    container: null
    account: null
    trust: no
    des: no
    dwirth@CENTRIFY.VMS's password:
    Attempting bind to centrify.vms site:Demo-Network server:dc.centrify.vms: ccache:MEMORY:0x5666c0
    Bind successful to server dc.centrify.vms
    Searching for AD Object: filter = (samAccountName=engcen6$), root = DC=centrify,DC=vms
    AD Object found: CN=engcen6,OU=Servers,OU=centrifyse,DC=centrify,DC=vms
    Key Version = 11
    Success: Add SPNs: Default Key Tab
    
  2. Verify the new SPN with “adinfo –C”
    $ adinfo -C | grep oracle
      Service Principal Names: oracle/engcen6
    
  3. Optional:  List the contents of the system keytab
    dzdo /usr/share/centrifydc/kerberos/bin/klist -kt /etc/krb5.keytab | grep oracle
      11 12/16/15 07:27:47 oracle/engcen6@CENTRIFY.VMS
    [output truncated]
    
    The KVNO goes up, and the new entry is present.
To remove an SPN from the computer (example:  removing the entry I added above to the same system)
  1. Run “dzdo adkeytab --delspn --principal oracle/engcen6 --user [ad-user-that-can-modify-computer-object] --verbose”
    $ dzdo adkeytab --delspn --principal oracle/engcen6 --user dwirth --verbose
    ADKeyTab version: CentrifyDC 5.2.0-218
    Options
    -------
    use machine ccache: no
    domain: centrify.vms
    server: null
    user: dwirth
    container: null
    account: null
    trust: no
    des: no
    dwirth@CENTRIFY.VMS's password:
    Attempting bind to centrify.vms site:Demo-Network server:dc.centrify.vms: ccache:MEMORY:0x5666c0
    Bind successful to server dc.centrify.vms
    Searching for AD Object: filter = (samAccountName=engcen6$), root = DC=centrify,DC=vms
    AD Object found: CN=engcen6,OU=Servers,OU=centrifyse,DC=centrify,DC=vms
    Key Version = 11
    Deleting SPN oracle/engcen6
    Keeping SPN myservice/engcen6
    Keeping SPN myservice/engcen6.centrify.vms
    Keeping SPN nfs/engcen6.centrify.vms
    Keeping SPN nfs/engcen6
    Keeping SPN ipp/engcen6.centrify.vms
    Keeping SPN ipp/engcen6
    Keeping SPN http/engcen6.centrify.vms
    Keeping SPN http/engcen6
    Keeping SPN host/engcen6.centrify.vms
    Keeping SPN host/engcen6
    Keeping SPN ftp/engcen6.centrify.vms
    Keeping SPN ftp/engcen6
    Keeping SPN cifs/engcen6.centrify.vms
    Keeping SPN cifs/engcen6
    Keeping SPN afpserver/engcen6.centrify.vms
    Keeping SPN afpserver/engcen6
    Removing SPNs from ADObject engcen6
    Removing spns and from config file for engcen6
    Removing SPNS from Keytab for engcen6
    Success: Del SPNs: Default Key Tab
    
  2. Verify the new deleted SPN with “adinfo –C”
    $ adinfo -C | grep oracle
    $
    
    No results imply that there's no entry.

Using adleave/adjoin 
  1. Edit the /etc/centrifydc/centrifydc.conf file and use the krb5.service.principals parameter to reflect the desired SPNs and save the file
  2. Note the Zone and Computer Roles the system belongs to  (using access manager, UNIX CLI or ADUC)
  3. Leave AD by running “dzdo adleave –r –u [AD-user-that-can-remove-the-computer-object]”
    this will leave the domain and remove the computer object;  if you rather do an offline leave, use the adleave -f command.
  4. Join AD by running the “[elevate] adjoin –z [zone] –c [container-in-ad] –u [ad-user-that-can-join]  [domain.name]” 
    if you have to join any computer roles, use the –computerrolrole parameter and list the computer roles.
  5. Verify that the newly-joined system has the SPNs you require by using adinfo -C

Do you know any instances of conflicts with these SPNs?
Yes.  Other Kerberos-enabled apps may rely on these SPNs.  Some notables:
  • Hadoop:  Applications like Cloudera Manager, Hortonworks Ambari or MapR Control System will create HTTP records for SNEGO-enabled services.  The best practice is to disable the http SPN using the krb5.service.principals parameter PRIOR to joining any systems that will participate in Hadoop clusters.
    For example, if I forgot to remove the http entry and I already joined my Hadoop node, all I need to do is run the "sudo adkeytab --delspn --principal http/shortname --principal http/fqdn --user myuser"  > this will remove all http SPNs.
  • Certain Java apps:   Some Kerberized java applications may have other conflicts.  Applications vary.
  • Mixed Kerberos Environments: In environments with mixed Kerberos environments (where AD and MIT Kerberos coexist) there may be conflicts, however if you follow the guidelines on Mixed Kerberos, there should be none given that the realms are different and the system keytabs & krb5.conf files are independent.

Tuesday, December 8, 2015

Centrify and Active Directory Functional Upgrades

This article was written originally for the Centrify Community.

What are Active Directory Functional Levels?
When Microsoft introduces new versions of Windows Server, they may add new capabilities to Active Directory. These new capabilities impact the environment and require planning, the “functional levels” can be introduced by the organization as they become ready. There are two types of functional level upgrade: domain and forest; the scope of forest functional levels affect the whole subtree, and domain-level changes only affect the target domain. A very common misconception is that all features are enabled. A functional upgrade may make a new capability or schema objects available, but it does not mean that your organization is ready or will use those capabilities.

Why should I know this, I only deal with UNIX | Linux | Mac OS X and upper-layer apps (Apache, Java, SAP, DB2)?
When your organization committed to use Active Directory on non-Windows platforms, they gained efficiencies and improved security capabilities, however, AD becomes an integral piece of infrastructure just like power, cooling, switching/routing, etc. All systems relying on AD must be aware of “functional-level” major changes.

What will be the impact to my UNIX, Linux or Mac systems when the Functional level goes up?
The answer to this question really depends on how well you manage your environment.
The rule of thumb is this. If you deployed Centrify in your UNIX, Linux or Mac environment a few years ago and time constraints have kept you from maintaining it (or because it just works), you’ll have a tougher time. If you’ve been keeping-up with the software lifecycle (upgrades) and are listening-in your AD planning calls; you may be so ready that your impact could be close to nothing.
To level-set here, this is not a “Centrify-only” consideration; this affects software and hardware that integrates to Active Directory. This article is to deep-dive into Centrify Server Suite and Identity Service Mac Edition (on-premises client).

You caught my interest. Can you tell me more about Active Directory functional levels?
The best source of information is this Microsoft TechNet article: https://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels%28v=ws.10%29.aspx. If you want to be better informed, see the reading list below.

What happens when I raise the Domain Functional Level as it relates to Centrify?
The answer depends on what your current functional level is and what functional you're raising it to.
Let’s focus on 3-key aspects of going from DFL 2003 and DFL 2012 (conveniently how I set up my lab :smileyhappy:).

Kerberos
Centrify DirectControl (centrifydc/adclient), just like any other Active Directory client, uses Kerberos as the authentication protocol. In Kerberos session tickets encrypted using cyphers (algorithms).
As time goes both computers have more power and mathematicians grow smarter or find issues with existing algorithm. A very good example is the Data Encryption Standard (DES), it has been around since the 70s and it was broken in the late 90s; therefore DES became phased out by AES officially in 2002.
One of the changes introduced by a DFL is better encryption algorithms.

  • Raising the DFL to Windows Server 2008 implements AES 128 and AES 256 for Kerberos.

This is why Microsoft's first guidance is to perform an inventory of your AD real estate. When this change happened, many older systems could not authenticate as illustrated in this example. In some instances, even a non-DFL change like adding a “newer OS” to perform the domain controller role can introduce side effects. For example, introducing a Windows Server 2012 Domain Controller to a Windows 2003 DFL Domain will immediately will disallow older crypto algorithms.

Summary – stronger cryptography is good, however, raising the DFL to Windows 2012 OR introducing a Windows 2012 domain controller in a 2003 forest requires at a minimum Server Suite 2014.1 (5.2.x).

KRBTGT Password Change
Active Directory has a built-in account called “krbtgt” (Kerberos TGT). This account has a complex password that is only known to low-level services; However, this is a very important account because every Ticket Granting Ticket (TGT) generated by users and computers is encrypted with a key that is derived from this password. As you probably can infer from the previous topic, once you switch the cypher, the secret is updated as well.

  • Raising the DFL will change the password of the KRBTGT account; this makes older secrets invalid.
Microsoft, as part of their strategy to mitigate advanced attacks like Pass-the-Hash (PtH) and others has established new best practices around the krbtgt account, but that’s the topic for another post.

Summary: When using stronger crypto, the passwords for the krbtgt will change.

SID Compression
The Windows Security Identifier (SID) is the unique and immutable identifier for an AD principal (user, group, etc.). Microsoft Kerberos implements methods that use the Privilege Attribute Certificate (PAC), in an over-simplistic way, the PAC contains information about the group membership and authorization information for the corresponding security principal.
Active Directory clients often need to make decisions about access control with information contained in the PAC; however when principals belong to large numbers of groups the information can't fit inside the data structure and that's why SID compression was implemented. Within Centrify Server Suite, this is very important especially in the context of Zones and DirectAuthorize.

  • Windows 2012 Domain Controllers implement SID compression and is turned on by default.  If an AD client can't decompress the SID to view the PAC, it will have functionality issues.
This has caused many known issues, however there's flexibility given that you can disable SID compression at the object  level or at the DC level.

Summary: SID compression is enabled on Windows 2012 DCs.  This is important for group enumeration and authorization.

Now you made me worried, What should I do?
 No need to be worried, there are plenty of resources available (see the reading list below); I think that by reading this article you should be informed and dangerous enough, however my advice is this:

  • Keep your agents up-to-date.
    This can be painful, but if you’re within the 3-year software life-cycle (for standard support, 5 years for premium), you should be fine. Keep in mind, you have to also be realistic. For example, Windows 2012 R2 was released in October of 2014 and Server Suite 2014.1 was released in August. In that case Centrify was ahead of the ball if organizations were looking to deploy that version of the software. In some instances we are behind and provide functionality based on the needs of our customer base.
  • Maintain your consoles and utilities up-to-date
    Consoles and PowerShell commandlets are backwards compatible. Tools like Deployment Report can be great tools to inventory clients.
  • Familiarize yourself with Microsoft’s methodology
    The methodology is outlined here: http://blogs.technet.com/b/askpfeplat/archive/2013/04/29/upgrading-or-migrating-active-directory-to-windows-server-2012-build-your-roadmap-now.aspx
    If you are working closely with your AD team, in the Assess phase you should be providing an inventory of all your Centrify clients and inform them if the version installed will support these key things: AES Encryption, KRBTGT password changes and SID Compression.
  • Document  any exceptions
    You should also inventory if you have hardcoded certain parameters like adclient.krb5.permitted.encryption.types. Ideally you should let DCs negotiate with the client, they typically go for the maximum (AES256).

Any tools, tips or tricks to share?
You can use Centrify CLI tools, Consoles and Utilities to discover, diagnose and collect information for your Functional Upgrade project.  Here are some examples:

Determining the Centrify version (per system - see below for inventory)
$ adinfo -v
adinfo (CentrifyDC 5.2.3-429)
Determining the forest and domain functional levels (per forest/domain)
$ adinfo --diag | grep Functionality
    domainFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    forestFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    domainControllerFunctionality: 6
    domainFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    forestFunctionality:           5 = (DS_BEHAVIOR_WINSERVER_2012)
    domainControllerFunctionality: 6
Determining if the encryption types have been changed (per client exception)
$ grep encryption.types /etc/centrifydc/centrifydc.conf
# adclient.krb5.tkt.encryption.types: aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
# * the default encryption types permitted for Windows 2000 server and
#   adclient.krb5.permitted.encryption.types: arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
# * the default encryption types permitted for Windows Server 2008 domain
#   adclient.krb5.permitted.encryption.types: aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
Determining the Kerberos system key table (keytab) encryption (per agent)
$ dzdo /usr/share/centrifydc/kerberos/bin/klist -ke /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   7 nfs/engcen6.centrify.vms@CENTRIFY.VMS (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   7 nfs/engcen6.centrify.vms@CENTRIFY.VMS (AES-128 CTS mode with 96-bit SHA-1 HMAC)
   7 nfs/engcen6.centrify.vms@CENTRIFY.VMS (ArcFour with HMAC/md5)
[output truncated] 
For each ServicePrincipalName (SPN) you should see an AES256 entry for DFL 2008 and above.

Determining if the encryption type on the system's ticket cache
$ dzdo /usr/share/centrifydc/kerberos/bin/klist -fe /etc/krb5.ccache
Ticket cache: FILE:/etc/krb5.ccache
Default principal: engcen6$@CENTRIFY.VMS

Valid starting     Expires            Service principal
12/08/15 14:56:35  12/09/15 00:56:34  krbtgt/CENTRIFY.VMS@CENTRIFY.VMS
        renew until 12/09/15 14:56:35, Flags: FRIA
        Etype (skey, tkt): AES-256 CTS mode with 96-bit SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC
Building an Inventory of Centrify agents and versions
Open Access Manager > Right Click "Centrify DirectManage Access Manager [dc]" > Select Deployment Report (Standard Edition)
DFL - Deployment Report.png

What if I want to test this?

You'll need
a) A Windows Server (2003 or 2008) acting as a DC at the low level (e.g. Windows Server 2003 DFL)
To test the raising of the DFL to

b) A Windows Server 2012 member server that you can promote to a DC
To test the introduction of a 2012 DC
c) A Centrify client in any mode (Express | Workstation | Zone) for UNIX, Linux or OS X.

Video


Reading List

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.

Monday, November 16, 2015

Security Corner - How to demonstrate alignment with Sarbanes-Oxley with Centrify for UNIX/Linux and Active Directory

Background on the Sarbanes-Oxley Act

You need to understand what a security analyst or auditor is asking of you, let's start with the basics:
  • What is SOx?The Sarbanes-Oxley act of 2002 or “Public Company Accounting Reform and Investor Protection Act”
  • Who needs to comply with it?All publicly-traded companies.
  • How can you prove due-diligence with SOx?They need to provide the assurance that systems that impact financial statements have implemented the proper security controls.
  • What is the point of SOX?The main intention of SOX is to establish verifiable security controls to protect against disclosure of confidential data, and tracking of personnel to detect data tampering that may be fraud related. The central purpose of the act is to reduce fraud, build public confidence and trust, and protect data that may affect companies and shareholders.
  • What is the cost of non-conformance?Very steep penalties and/or prison time for executives.
  • What systems are bound by SOx rules?Any system that supports applications that impact the business bottomline.  Your organization should have written guidelines to categorize the data that travels or is stored in those systems.
  • What are the guidelines to determine if a system may be bound by SOx?This should be defined by a risk assessment exercise, however, a simple model is to use the CIA rating (Confidentiality-Integrity-Availability).  This triad can be used to do a simple test.  As yourself these 3 questions.
    If the data on these systems....
    a) is made public (confidentiality breach)
    b) is tampered with or not reliable
    c) is not available (system down)

    ... is there an impact to the organization's bottomline (financial, reputation, major productivity loss)?
    The answer to this question should give you a pretty good idea.  As a matter of fact, any system that falls into that category (infrastructure like Routers, Switches, DNS, PKI, etc.) has impact to operations.

What are the common misconceptions of the SOx Act?
That you should only produce reports (e.g. lists of users in the context of IAM).  The whole point of the concept of "verifiable security controls" is to prove the effectiveness of the controls;  the reason why organizations have to produce reports is due to legacy issues.
For example, if you are using /etc/passwd for 20 users, you have to potentially attest for 20 different user/attestation reports.

Now let's discuss how Centrify can help.

Centrify-Sarbanes Oxley Reference Guide
This table, should be a good starting point; however we ask that you reconcile this information with your organization's security policies, guidelines and procedures.

SectionWhat it meansCentrify Products/FeaturesCentrify Implements
Section 302.2 – Establish safeguards to prevent data tampering.Controls are implemented to prevent, correct or detect data breachesDirectControl, DirectAuthorize, DirectAudit / Privileged user management, logging, auditingCentrify implements a RBAC mechanism that allows to control:
a)     Who can access a system
b)     How they can access the system (console, SSH, RDP, etc)
c)      What can they do in that system (DirectAutorize)
This approach protects systems end-to-end and it’s not password-centric.  It’s called Least Access/Least Privilege Principle
Resource: What is DirectAuthorize?
Section 302.4.B – Establish verifiable controls to track data access.Controls are implemented to attest who has accessDirectControl, DirectAuthorize, DirectAudit / Reporting, AuditingAll access and privilege elevation events are logged to UNIX/Linux syslog and the Windows Event log (if Kerberos events are being audited)
Section 302.4.C – Ensure that safeguards are operationalSelf-describedDirectControl, DirectAuthorize, DirectAudit / site awareness, watchdog, caching, offline auditCentrify implements the following high-availability mechanisms:
a)     AD Site/Services awareness – this means that it will failover upon domain controller failure
b)     Offline Cache:  in case of no DC availability it can provide login with cached credentials
c)      Telemetry calculations:  the client proactively will probe to see if it’s talking to the most optimal DC.
d)     Watchdog processes:  Implements a watchdog daemon that will spawn new processes if needed.
Resource: Youtube Playlist - HA Mechanisms.
Section 302.4.D – Periodically report the effectiveness of safeguards.Attest that controls are working as expectedDirectControl, DirectAuthorize, DirectAudit /enhanced logging, alerts.Centrify Implements
a)     Console-based reporting
b)     Script-based reporting (UNIX, Windows PowerShell)
c)      SQL-Server Based Reporting (CSS 2016, now in Beta)
Section 302.5.A&B – Detect Security BreachesSelf-describedDirectControl, DirectAudit / logging, capture and replayCentrify Provides:
a)     Event log and syslog logging
b)     Session Transcripton (EE)
c)      Session Capture and Replay (DVR-like) (EE)
d)     Event consolidation (EE)
e)     Event reporting (EE)
Section 404.A.1.1 – Disclose security safeguards to independent auditors.
Section 404.A.2 – Disclose security breaches to independent auditors.
Section 404.B – Disclose failures of security safeguards to independent auditors. 
Demonstrate the existence of a security framework, for example:
•       Procedures to eliminate terminated (or changed) employees
•       Password Policy
•       Separation of Duties
•       Attestation
DirectControl, DirectAuthorize, DirectAudit / zone provisioning agent, policy enforcement, zone delegation,  role-based access, reporting, logging, auditingCentrify allows for
a)     Collapsing the termination of users directly in active directory
b)     The password policy from Active Directory is reused in UNIX, Linux, Mac and Apps
c)      Provides mechanisms to implement delegation and separation of duties.

The bottomline is this:
Organizations that have multiple identity silos (like /etc/passwd or /etc/group) have a very hard time (or have a lot of complexity or an army of people) just to manage simple tasks like the user/group life-cycle (add/moves/changes).  With Centrify and Active Directory these tasks become centralized, making the security controls more effective.  Organizations effectively piggy-back on existing processes, so when you get the question "how can you prove that you're performing on-time user add/moves or changes?" you can simply say:  "This is all tied to our Active Directory processes and procedures"

Here's a good sequence (for user adds/moves and policy)
1. Log on to a UNIX, Linux or Mac with an AD user.
2. Show the system log (messages log, syslog or event log)
3. Logoff and Disable the user in AD
4. Attempt login (you should fail).  Show the log again.
5. Re-enable the user and log in.
6. Try to change the password to something misaligned with policy (like 1235).
7. Show the failure in password updates.

Note
: You have to be auditing logon success and failure events in Active Directory Domain Controllers to see this.  You can set this up by enabling success and failure of the Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit Account Logon Events GPO.


Samples:
In this sequence, the user Diana (dwirth) logs in to a CentOS system via SSH.


Event on UNIX/Linux:
Jul 27 17:17:55 engcen5 adclient[3313]: INFO  AUDIT_TRAIL|Centrify Suite|PAM|1.0|200|
PAM set credentials granted|5|user=dwirth(type:ad,dwirth@CENTRIFYIMAGE.VMS) 
pid=25913 utc=1438035475776 centrifyEventID=24200 status=GRANTED service=sshd tty=ssh 
client=member.centrifyimage.vms

Event on Windows:
Event Viewer - Kerberos success.png

Centrify Architecture and Credential Consolidation
You often have to explain how our solution is architected.  The bottomline is that for all intends and purposes, the system acts like a Windows system.  However, you may need to materialize diagrams like this:
architecture.png
Make sure you explain that Centrify uses UNIX frameworks, standard protocols and Microsoft Active Directory specifications.  Here are some of the key ones:
  • Name Service Switch (NSS) –provides a facility to the OS for sources of identity information like users and groups
  • Pluggable Authentication Modules (PAM) – provides a facility to the OS applications to abstract authentication providers.
  • Kerberos:  Centrify communicates with AD for authentication using Kerberos.  Kerberos is an authentication protocol that relies on a Key Distribution Center and Authentication servers.  The whole principle behind Kerberos is the use of mutual authentication, tickets, encryption and mechanisms to detect replay attacks.  Centrify provides MIT-Kerberos based tools and libraries that have been optimized to work with Microsoft’s Active Directory Kerberos implementation.
  • High-availability is provided by AD Site Awareness, offline credential cache, telemetry calculations and the watchdog process.
How does the authentication process work?
At a very simple level:
  1. A UNIX-enabled AD user attempts to log in using a PAM-enabled(*) application (like login or SSH)
  2. An application like login uses the Centrify PAM module to attempt to log in.
  3. The PAM modules will perform a series of checks, e.g. (user is authorized, AD account in good standing), password is correct, etc,
  4. Kerberos: The system will use a mutually authenticated encrypted connection (with the highest allowed encryption) to talk to a domain controller and get the appropriate service tickets.
  5. The user will be logged in to the system via the corresponding application (e.g. login, SSH)
    (see the attachment)

Encryption Levels
You may be asked about encryption too.  Make sure you explain that in an Active Directory environment, encryption algorithms and strength are defined by the version and functional level of the environment.  For example, an AD DC that is running in 2008R2 functional level will use AES256 for encryption, previous versions would use lower encryption levels.  The Centrify agent will follow the levels defined by Active Directory. 

Passwords are stored in Active Directory domain controllers and the encryption level is defined by the msDS-SupportedEncryptionTypes attribute.  To view the encryption levels supported by your current infrastructure, consult your AD team, or look at the /etc/krb5.conf configuration of any Centrified system. 

Encryption is used for two areas:
  • Kerberos transactions (encryption in traffic – self-explanatory)
  • Offline cache:   Centrify just like Windows supports the use of offline logins, as a compensating high-availability mechanism in case of lack of communication with a Domain controller.  The encryption levels for the offline has are the ones available by the AD functional level.  The parameter to encrypt the hash of the offline credential is cache.encrypt (or its corresponding Group Policy Object) and you can force an encryption type by using the adclient.cache.encryption.type (or the corresponding GPO).

Due Diligence
Due to Centrify’s penetration in high-security environments, we’ve had to perform additional due diligence and have achieved the following certifications:

Resources:

Identity: Why aren’t AD Schema extensions or software in Domain Controllers required?
I've seen instances in which the auditor/security analysts asks this question.  
As it relates to identity data, Centrify has several ways to use Active Directory without requiring Schema Extensions:
  • Pre-Windows 2003R2 AD functional levels:  Centrify zones implement mechanisms to store UNIX identity information in classic zones.
  • Windows 2003R2 and above functional levels:  Centrify can use identity stored in the RFC2307 attributes implemented natively in this schema.
  • Services for UNIX (SFU) Schema:  If a customer or prospect extended the AD schema to SFU, we can store information there (although it provides less flexibility than Centrify zones).
In addition, Centrify subscribes to Microsoft’s documented APIs (ADSI), therefore there’s no need to add software in domain controllers.

Resources for Identity: 
  • Video – How DirectControl stores information in Active Directory:  https://www.youtube.com/watch?v=JO3_AJObkAs
    in this video, the CTO and creator of DirectControl, explains how Centrify stores data in AD.
  • RFC 2307: https://www.ietf.org/rfc/rfc2307.txt
  • Attached - The “Understanding the Centrify DirectControl Agent.pdf” excerpt; explains the process step by step and more detail.

    (*) Centrify provides functionality for IBM Loadable Authentication Modules (LAM) as well.

Application Edition
If an Application (Apache, Java, DB2, SAP) initiates an authentication request via an interface (SPNEGO, GSSAPI, SASL, SNC, etc) ultimately the agent will use Kerberos for authentication.
sso.png

In addition  Centrify has a whitepaper titled "Using Microsoft Active Directory to Address Sarbanes-Oxley (SOX) Compliance in Heterogeneous Environments".

Note: the original version of this article was published in the Centrify Community.

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