Let's break a few things....

In this video series we explore how different Centrify products respond to failure scenarios.

Centrify UNIX, Linux Mac Clients - Cached Credentials

Setting up the Account Prevalidation GPO

How Privileged Elevation for Windows handles AD Failures

DirectAudit High-Availability (playlist)

Identity Service HA for Cloud Connectors

Business Problems: Overcoming the Confidentiality and Integration challenges with Hadoop Clusters using Centrify

Background

Hadoop implementations present multiple challenges to enterprises at the Operating System layer(*), I like to categorize them in 2 areas:

Confidentiality

• Hadoop clusters are unsecure by default.  What that means is that there's no service-to-service authentication and that privileged users have access to world-readable information and can elevate to privileged Hadoop accounts.
• Multiple clusters are needed because of the development nature of the apps.  Typically at least a DEV/QA and PROD environments are needed, depending on the risk profile of the organization, each environment may be in different isolated environments and require different access control rules.
• Different types of users need access:  From the SysAdmin, to the Hadoop Admin, to the Data Scientist, they all have different access and privileged needs.
• The data classification of the business intelligence may require additional controls.  What if the cluster crunches Personal, Financial, Health, Energy or Card data?   SOx, PCI, HIPAA, NERC or FERC compliance is needed.

Integration

• Kerberos:  Many organizations balk at the proposition of standing-up a separate MIT Kerberos implementation; and even if AD is an option, test environments may be in a one-way trust.
• Different organizations == Different requirements, therefore the devil is in the details:
• Process
• Technology/Infrastructure
• People
• Regulations

(*) There are additional security challenges, like how to protect data at the Hadoop layer, for this, your trusted Hadoop vendor (Cloudera, Hortonworks, MapR, etc) have an ecosystem of applications.  Centrify can provide identity information to those apps.

Technical Briefing

The following videos provide technical demos on how Centrify can overcome these challenges

Putting it all together

• Centrify allows for OS level integration for Linux and UNIX systems that enables:
• Centralized Administrations of multiple Hadoop Clusters
• Regardless of how complex your AD may be 
• No schema extensions or software in domain controllers
• Using UNIX frameworks
• Kerberos just works out of the box
• Leverage AD fully:  Kerberos, Group Policy, PKI
• Centrify enables the implementation of strong access controls to enforce
• Least access
• Least privilege (RBAC- not password Centric)
• Easy attestation and reporting
• Separation of Duties
• Works on Windows to eliminate the problem of the persistent administrator
• For environments with Personal, Financial, Health or Card data
• Session transcription 
• Session replay
• Event consolidation
• Works on Windows
• Hadoop-exclusive features:
• adkeytab for advanced keytab/service account provisioning
• Kerberos infinite ticket renewal parameters and GPOs
• LDAP Proxy to assist apps like Sentry, Hue and Knox
• Partner with Cloudera, MapR and Hortonworks

Centrify + AD + Hadoop = faster, more secure and regulation-aligned big data projects.

Implementing the Centrify's Account Prevalidation Capability on UNIX, Linux and OS X using Group Policies

Requirement
In case of an Active Directory catastrophic failure, a limited set of trusted administrators shall be able to log in to UNIX, Linux or OS X systems and perform the actions defined in their privileged management roles.

Scenario
Contoso has 3,000 servers and many of them on branch deployments and public clouds, there are no DCs in the branches.  WAN connectivity can be lost and a mechanism to allow trusted administrators to perform actions should be available.  It's highly unlikely the set of trusted admins have logged in to all systems. This is why Centrify implemented the account prevalidation feature.

Tools and Targets

• Group Policy Management
• Active Directory Users and Computers
• CLI tools:  adgpupdate, adgpresult, setspn & PowerShell(windows)
• Configuration files:  /etc/centrifydc/centrifydc.conf

 Planning

• Target Group:  Account prevalidation can be assigned to users or groups.  Ideally this would be assigned to groups so the management can be delegated to the Helpdesk, or front ended by an ITSM or Worfklow solution.
  This means that an AD Group should be requested.  Sample Name:   Centrify-Prevalidated-Admins
• Process: 
  Onboarding:  When senior UNIX, Linux or Mac OS X administrators are onboarded, the user template or form should be updated so they are added to this group by default.
  One-offs:   When critical projects are going on and stakeholders need to be added to this group, our ITSM tool will front end a workflow request that ends on a PowerShell action that adds (or removes) the user from the target group.
  Attestation:   This group does not have any additional rights, however it has to be attested as part of the disaster recovery plan.

Implementation
What you'll need

• Centrify Standard Edition or Centrify Identity Service Mac Edition  (licensed)
• A Windows system with Group Policy Management and the Centrify Group Policy Extensions (GPOE) installed
• An Active Directory group pre-populated with the users that will be prevalidated
• A GPO tied to the OU of the target UNIX, Linux or OS X systems.
• Rights to edit the GPO
• Centrified system in the OU that has the GPO linked to verify.

First, Gather information about the members of the group

From a Centrified System 
$ adquery group -A Centrify-Prevalidated-Users | grep members
members:centrifyimage.vms/Staff/IT/Diana Wirth

From Windows with PowerShell
PS > get-adgroupmember Centrify-Prevalidated-Users | Select-Object samaccountname

samaccountname
--------------
dwirth
rpimentel

Second, Configure the GPO

1. Open Group Policy Management
2. Create or edit the GPO in the corresponding forest/domain/OU.
   
3. In group Policy Editor, navigate to Computer Configuration > Policies > Centrify Settings(*) > DirectControl Settings(**) > Account Prevalidation.  In the right pane, double-click on "Specify allowed groups for prevalidation" select Enabled and populate the dialog box with the group predefined for this purpose and press OK and close Group Policy Editor.
   
   (*) If you don't see a Centrify Settings section, you don't have the Centrify GPOE installed.
   (**) If you don't see a "DirectControl Settings" folder, you need to add the template.

Third, Add the Preval SPN to the members of the group and commit the changes in the Centrified system

a) To add the SPN

# From Windows with the setspn utility
C:\> setspn -A preval/rpimentel rpimentel
Checking domain DC=centrifyimage,DC=vms

Registering ServicePrincipalNames for CN=Diana Wirth,OU=IT,OU=Staff,DC=centrifyimage,DC=vms
        preval/dwirth
Updated object

# From Windows using PowerShell
PS > Get-ADUser dwirth | Set-ADUser -ServicePrincipalNames @{Add="preval/dwirth"}

# From a Centrified System Using adedit
## Authenticate as someone who can edit the target object
$ kinit administrator
Password for administrator@CENTRIFYIMAGE.VMS:

# Open adedit, bind to domain and use the add_object_value function
$ adedit
>bind centrifyimage.vms
>package require ade_lib
1.0
> add_object_value "CN=Diana Wirth,OU=IT,OU=Staff,DC=centrifyimage,DC=vms" serviceprincipalname "preval/dwirth"
1
> exit

# Manually using Active Directory Users and Computers

1. Open ADUC
2. In the View menu, check "Advanced Features"
3. Open your target user > Attribute Editor > servicePrincipalName
4. Click add, and type  preval/<user>, press OK twice.

b) To verify the SPN was added succesfully
# from a Centrified system using CLI

$ adquery user dwirth --attribute servicePrincipalName
preval/dwirth

# from Windows using PowerShell
PS > Get-ADUser dwirth -prop ServicePrincipalNames | Select-Object Name, ServicePrincipalNames

Name                                  ServicePrincipalNames
----                                  ---------------------
Diana Wirth                           {preval/dwirth}

c) To commit the changes to a system for the purposes of testing

## flush the cache - only if you want this immediately (will happen automatically after cache flush interval + gpo refresh
$ dzdo adflush
DNS cache flushed successfully.
Authorization cache store flushed successfully.
GC and DC caches expired successfully.
DA name cache flushed successfully.
DA installation information cache flushed successfully.


## perform a group policy update - again, this happens on the GPO refresh.
$ adgpupdate
Refreshing Computer Policy...
Success
Refreshing User Policy...
User Policy disabled on this machine.

## verify that the GPO inserted changes in the config file
$ adgpresult | grep Centrify-Prevalidated-Users
        adclient.prevalidate.allow.groups = Centrify-Prevalidated-Users,

Notes:  This process can also be implemented with a Management tool like Chef, Puppet, Spacewalk, etc.  Ultimately the parameter that will be adjusted is the "adclient.prevalidate.allow.groups" in the /etc/centrifydc/centrifydc.conf file.  This can also be part of a master config file that is enforced across the board, but watch out for conflicts with GPOs.  You must pick a tool.

Verify and Test
 To verify prevalidation you'll need a recently centrified system OR a system that you know one of your test subjects has never logged in.  You will also have to switch the agent to offline mode.  There are two ways to do it:
a) If this is a VM, go to the hypervisor console, and disconnect the network; OR
b) Force the agent to go offline by adding all your DCs to the dns.block parameter.
E.g. if I have 2 DCs  (dc1.corp.contoso.com and dc2.corp.contoso.com), the parameter would look like this:

dns.block:  dc1.corp.contoso,com, dc2.corp.contoso.com

c) If you have console access, you can also disable the network interface momentarily.

This video explains the installation and testing process:


Adjustments
 There are several areas of improvement for this process:

Automation
A really cool improvement has to do with the automation of the prevalidation SPN.  For example, you can implement both in a Centrified UNIX/Linux system or with Windows PowerShell script that checks if new users are added to your target group, and automatically will add (or remove) the preval SPN.

Service Management and Approvals
If you have an ITSM (like ServiceNow) or an IdM with workflow/approvals, you can front-end this process by adding references and approvals to be able to answer these questions:

• Why is this user a member of this group?
• Who approved?
• What's the reference number

Centrify Identity Platform - Making Strides and Taking Names

Centrify Identity Platform consists of two products:  Identity Service and Privileged Service

Centrify Identity Service (formerly User Suite) has continued its meteoric rise and I want to congratulate many of my coworkers on their hard work and dedication.

In the past two weeks, to major publications have continued to highlight its critical acclaim:

• 2015 Gartner Magic Quadrant for Identity and Access Management as a Service
• Positions Centrify as a visionary, proving and validating the completeness of the vision that combines On-Prem/SaaS SSO with Enterprise Mobility Management plus robust policy, Multi-factor Authentication and VPN-less Access.
• Ranks #3 among the solutions in a year that saw Salesforce, IBM and Microsoft enter the market and continues to beat the leader in execution and completeness of vision (#2 in pure play).  It's only a matter of time given Centrify's leadership.
• This is all looking at data from last year!!!!  This is before App Gateway, Privileged Service, ServiceNOW integration and others were ready to go.
  Get the report here.
• Network World Names Centrify Identity Service the best SSO tool for 2015
• Calls out the integration of SSO+EMM+MFA+Management interface.  Everyone else left to eat the dust.

Centrify Privileged Service (CPS) is a new entry (announcement) to the hybrid family of products that has a pure play in two areas (and growing):  Shared Account Password Management (SAPM) and Secure Remote Access, but it builds on the existing capabilities of the Identity Service to deliver complementary capabilities to Server Suite.

RBAC continues to be the preferred method for Privileged Account Management (PAM), however, for emergency, one offs and change control, using a shared privileged account can be useful.  Here's a video that illustrates the differences between the approaches:

Capabilities of CPS

Shared Account Password Management

Use your AD account and Multi-factor authentication to check out UNIX, Linux or Windows accounts, enforce policy, access anywhere (centrally or via mobile app).  Upon check-out, the password is rotated for you.

Secure Remote Access

Leverage the existing cloud connector infrastructure to deliver secure remote access to resources regardless of their location (on premises or in the cloud IaaS).  

Apps, UNIX, Linux and Windows sessions can be presented to users in a cohesive way

Much more to come, and many synergies with Server Suite

Very exciting time to be at Centrify and especially to help out prospects and existing customers.

Scripting - Using Centrify PowerShell to Automate Access and Privilege Operations

Background

In some of the examples that we use in this blog, we leverage a basic reference design that consists of a Centrify Active Directory zone, a few computer roles, a UNIX and Windows SysAdmin role and some basic assignments at the Zone, Computer Role and System levels.  Since some of you have told me that you use the blog to follow along, I've decided to share the PowerShell code for this purpose.

There are several cast of characters that I create  (in this case, the Simpsons), but you can change it as needed.

Why post this?
As I meet with many of the current or prospective Centrify customers I see 3 common threads: many more of you are using public/private cloud (as evidenced by some of the recent posts) and want tools and examples of automation;  many of you are looking to leverage IT Service Management solutions for  workflow/approvals (like ServiceNow) and combine it with automation; this post provides some examples.

Disclaimer:  I am not a programmer.  I've made my forays into scripting in the past (mostly vbscript) but I'm not a PowerShell, Bash or any other type of programmer.  This is done for illustration purposes.  When working with scripts in production environments, you.must.add.error.handling!!!

The Basic Reference Design

The cadence will be the same as the GUI.  Create the zone, define rights, define roles, populate the roles and assign them.  These are considered the infrequent steps.
The normal operations are UNIX-enabling users, and performing role assignments directly or leveraging AD groups.  This is the same for Windows and UNIX.

PowerShell Modules

You'll need the Active Directory and the Centrify DirectManage PowerShell modules.

Import-Module ActiveDirectory
Import-Module Centrify.DirectControl.PowerShell

Notice that I'm assuming the default location.


Creating the Zone

$zone = New-CdmZone -Name "Model" -Description "Reference Zone" -Type hierarchical -Container "cn=Zones,ou=Unix,dc=example,dc=com"

Notice that I'm using a shortcut to create the zone and add it to a variable.  Obviously the Container assumes that your domain is example.com and there's a UNIX OU with a Zones SubOU contained within.

Defining the Rights

$cmd1 = New-CdmCommandRight -Zone $zone -Name "Run any command as root" -Pattern "*" -MatchPath "*" -DzdoRunAsUser root -Authentication user 

Creates the sensitive command to run any command as root and requests authentication.

$criteria = New-CdmMatchCriteria -Description "Event Viewer" -FileType "exe" -FileName "eventvwr.exe" -Path "C:\Windows\System32\"

$cmd2 = New-CdmApplicationRight -Zone $zone -Name "Audit Windows Event Log" -MatchCriteria $criteria -RunasSelfGroups "Builtin\Administrators"

Creates Event viewer as Administrator.  The first part is to create the application criteria (a Windows application may contain multiple criterion), then we create the right with the proper criteria.

$cmd3 = Get-CdmPamRight -Zone $zone -Name "sshd" 

This is getting the stock sshd right.  Keep in mind that work in most Linux, but probably you'll have to create something different for Ubuntu or Solaris.

$cmd4 = New-CdmCommandRight -Zone $zone -Name "Audit RHEL Secure Log" -Pattern "tail /var/log/secure" -DzshRunas root

This is another platform-dependent command right.  

$cmd5 = Get-CdmPamRight -Zone $zone -Name "login-all"

This gets, the stock "login-all" PAM right for the SysAdmin Role.

Defining the Roles

$role1 = New-CdmRole -Zone $zone -Name "Mixed Auditor" -UnixSysRights login, ssologin, nondzsh -WinSysRights remote

Defines the Mixed Auditor Role with the ability to log in with a password and with SSO to unix systems and via Citrix or RDP to Windows systems.

Add-CdmCommandRight -Right $cmd4 –Role $role1 
Add-CdmApplicationRight -Right $cmd2 –Role $role1 
Add-CdmPamRight  -Right $cmd3 –Role $role1 

The previous 3 commands add the unix command, windows application and ssh rights into the Mixed Auditor role.

$role2 = New-CdmRole -Zone $zone -Name "UNIX Sysadmin" -UnixSysRights login, ssologin, nondzsh 
Add-CdmCommandRight -Right $cmd1 –Role $role2
Add-CdmPamRight -Right $cmd5 –Role $role2

The defines the UNIX SysAdmin role and adds the "Run any command as root" and login-all PAM right.

Defining Computer Roles

Computer Roles are groupings of systems.  They may contain UNIX or Windows systems that exist within the zone.  Computer Roles are stored within AD Security groups, therefore we have to define some groups, and groups have to be put in an OU.  In this case an OU called Demo.

$oupath = (Get-ADOrganizationalUnit -Filter 'Name -like "Demo"').DistinguishedName

New-ADGroup -Name "Centrify-Model-CR-WebServers" -Path $oupath -GroupScope Global

New-ADGroup -Name "Centrify-Model-CR-DatabaseServers" -Path $oupath -GroupScope Global

$crgroup1 = Get-ADGroup -Filter 'Name -like "Centrify-Model-CR-WebServers"'

$crgroup2 = Get-ADGroup -Filter 'Name -like "Centrify-Model-CR-DatabaseServers"'

The naming convention is easy to figure out for these AD groups:  Centrify-NameofZone-Type of Group-Description.

$crweb = New-CdmComputerRole -Zone $zone -Name "Web Servers"  -Group $crgroup1

$crdb = New-CdmComputerRole -Zone $zone -Name "Database Servers" -Group $crgroup2

At this point there's an empty zone, with a basic security access and privilege model.

UNIX-Enabling Users

To access a UNIX/Linux system, users need to have a UNIX identity in the Centrify Zone in AD;  this is quite simple using PowerShell.  In addition, they must have a role as well.

New-CdmUserProfile -Zone $zone –User marge.simpson@example.com -login marge.simpson -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"

New-CdmUserProfile -Zone $zone –User bart.simpson@example.com -login bart -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"

New-CdmUserProfile -Zone $zone –User maggie.simpson@example.com –login maggie.simpson -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"

New-CdmUserProfile -Zone $zone –User homer.simpson@example.com–login homer -UseAutoUid -AutoPrivateGroup –HomeDir "%{home}/%{user}" –Gecos "%{u:displayName}" –Shell "%{shell}"

Since this is a clean environment, I'm using very few overrides and all UID/GID info is generated based on the user's SID.  

Granting access and Assigning Roles

A permanent assignment at the zone level

$role1 = Get-CdmRole -Zone $zone -Name "UNIX SysAdmin"  

New-CdmRoleAssignment -Zone $zone -Role $role1 -ADTrustee marge.simpson@example.com

As discussed in previous postings, these are rare and only assigned to senior trusted admins

A permanent assignment at the computer role level (WebServers)

$role2 = Get-CdmRole -Zone $zone -Name "Mixed Auditor" 

$crweb = Get-CdmComputerRole -Zone $zone -Name "Web Servers" 

New-CdmRoleAssignment -ComputerRole $crweb  -Role $role2 -ADTrustee bart.simpson@example.com

Note that this is a mixed role.  If the computer role has IIS and Apache servers, this auditor can review both the event log and the secure log.

A time-bound role assignment (perhaps a change control Window or a break-glass scenario) to an individual system

$role3 = Get-CdmRole -Zone $zone -Name "UNIX login"  

$comp = Get-CdmManagedComputer -Zone $zone -Name "your-zone-enabled-system" 

New-CdmRoleAssignment -Computer $comp -Role $role3 -ADTrustee homer.simpson@example.com -StartTime (Get-Date) -EndTime (Get-Date).AddMinutes(60)

In this example, Homer is getting the ability to log in to this system for an hour.  

Video

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

Labs: Using Couchbase's upcoming LDAP functionality with AD leveraging Centrify’s LDAP Proxy

Background

Couchbase is including LDAP support in the upcoming March release and we wanted to preview how to leverage your existing Centrify assets to help with this scenario.  The instructions below are for testing purposes only.
This capability will provide the ability to use LDAP users (From AD or other LDAP directories) to be provisioned as Full or Read-only administrators of the web console.

About this configuration

In this configuration  Couchbase is using saslauthd to connect to LDAP.  By leveraging the Centrify LDAP Proxy, this configuration can benefit from the robust capabilities of the Centrify agent (AD sites and services awareness, performance, caching, etc).

What’s required?

• Couchbase Server 3.5.x:  http://latestbuilds.hq.couchbase.com/couchbase-server/sherlock/1415/couchbase-server-enterprise-3.5.0-1415-centos6.x86_64.rpm
• Centrify Agent + LDAP Proxy:  http://www.centrify.com/products/server-suite/active-directory-bridge/
• Cyrus-SASL (saslauthd):  http://linux.die.net/man/8/saslauthd

Instructions (All steps on CentOS 6.x)

Step 1 – Install the Centrify Agent and join AD

1. With a privileged user, install the Centrify agent.
   rpm –Uvh centrifydc-<version>  (e.g. centrifydc-5.2.2-rhel3-x86_64.rpm)
2.  Check if all is OK to join Active Directory
   adcheck <your domain>  (e.g. adcheck corp.contoso.com)
   Make sure you fix any issues (e.g. DNS, DC connectivity, etc)
3. Join active directory (you’ll need an account that can join computers in AD)
   adjoin –z Model –c “ou=Servers,ou=UNIX” –u jerry.seinfeld -V corp.contoso.comJoins the corp.contoso.com in Centrify zone mode (Model) mode, and places the computer on the /UNIX/Servers OU and uses jerrry.seinfeld's  account for the corp.contoso.com domain.

Step 2 – Install, configure, start and test the Centrify LDAP Proxy

1. Install the Centrify LDAP Proxyrpm – Uvh centrify-ldapproxy-<version>  (e.g. centrifydc-ldapproxy-5.2.2-rhel3-x86_64.rpm)
2. Elevate and start the proxy manually or configure a startup script.  For example
   dzdo /usr/share/centrifydc/libexec/slapd  -f /etc/centrifydc/openldap/ldapproxy.slapd.conf -h ldap://cen1.corp.contoso.com
   This makes the LDAP proxy to start reading the indicated startup file and listens to the hostname cen1.corp.contoso.com
3. To test that the LDAP proxy is responding to queries, use ldapsearch:$ /usr/share/centrifydc/bin/ldapsearch -h cen1.corp.contoso.com -x -b "ou=staff,dc=corp,dc=contoso,dc=com" "(cn=George Constanza)"
4. Your search should yield results.

Step 3 – Install and Configure and Test saslauthd for LDAP

1. Install cyrus-sasl (saslauthd)$ dzdo yum install cyrus-sasl
2. Configure SASL for LDAP

• a.       Edit the /etc/sysconfig/saslauthd and make sure the MECH parameter is set to LDAPMECH = ldap
• b.      Configure the LDAP parameters for SASL the config file should be on /etc/saslauthd.conf. You need to add the ldap_server parameter (the system running the Centrify LDAP proxy) as well as your search base and the attribute that corresponds to the user name.  With Centrify you can use the AD name (samAccountName) or the uid contained in the PosixAccount class.  In my test scenario:
  ldap_servers: ldap://cen1.corp.contoso.comldap_search_base: ou=Staff,dc=corp,dc=contoso,dc=com=ldap_filter: (samAccountName=%u)
  
  Note that in a production environment you’ll use multiple proxies for HA and secure LDAP (ldaps://) and most likely your Couchbase configuration will be clustered.  Use the same availability controls for the Authentication that you are using for the cluster.
• c.       Start the saslauthd service (or set it to start automatically with chkconfig)$ dzdo service saslauthd start

1. Test saslauthd for LDAPUse the testsaslauth script to test LDAP authentication:/usr/sbin/testsaslauthd -u george.constanza -p <cleartextpw> -f /var/run/saslauthd/mux
2. If everything is well set up, the output should be:  0: OK "Success."

Steps 1 to 3 - Potential misconfigurations:

• Firewall ports are not open for LDAP
• The Proxy is not started or hasn't started with the appropriate protocol or hostname.
• The configuration of saslauthd is incorrect (look at /etc/sysconfig/saslauthd OR /etc/saslauthd.conf)
• Your LDAP filters are not correct.

Step 4 – Install Couchbase and Perform Initial Setup

Official instructions here: http://docs.couchbase.com/admin/admin/Install/rhel-installing.html

1. Obtain the new bits that support LDAP: wget http://latestbuilds.hq.couchbase.com/couchbase-server/sherlock/1415/couchbase-server-enterprise-3.5.0-1415-centos6.x86_64.rpm
2. Add the following lines to the /etc/rc.localfor i in /sys/kernel/mm/*transparent_hugepage/enabled; doecho never > $i; donefor i in /sys/kernel/mm/*transparent_hugepage/defrag; doecho never > $i; done 
3. Save and reboot the server.
4. Install couchbase$ dzdo rpm --install couchbase-server-version.rpm
5. Provided that your firewall ports are open, you can go to a browser and navigate to the Couchbase admin page:  http://your-hostname:8091
6. Follow the steps to complete the initial configuration (hostname, cluster, sample apps, Administrative user, etc)

Note: In my environment I performed a reboot.  Keep in mind that if you ran the Centrify LDAP proxy manually, you need to launch it again and restart saslauthd before the next step.

Step 4 – Set up Couchbase for LDAP and test settings

1.  Log in to the couchbase administrative interface with your administrator account.
2. Navigate to Settings > LDAP Auth Setup
3. Under Setup, check the Enable Checkbox and press Save.
4. Add a Full or Read-Only administrator
   (I used the AD username, since my LDAP filter uses samAccountName).  E.g. George.Constanza
5. To test the user, use the Validate box.
   
6. Sign out of the Console.  Attempt login with the newly assigned Admin.   If your admin is Full, they’ll get access to all the settings, if they are read-only, they’ll get the settings grayed out.

Summary

Setup was fairly simple using the Centrify LDAP proxy.  The benefits are tangible because the underlying adclient agent serves as a way not to have to maintain multiple LDAP entries and for additional performance gains.  Keep in mind, this was a "quick-and-dirty" setup, in reality you would have to account for LDAPS and HA.

As far as Couchbase goes, I was very impressed with how simple it was to set up and things just worked. They have been adding security features incrementally, and we are hoping that we can see them leverage PAM, Kerberos, PKI and to be able to leverage NSS UNIX users/groups for at least administrative interfaces; this will enable Centrify users to expose AD capabilities and accelerate the security posture of the platform.  We are keeping our eyes and ears locked on these newer technologies.

Quick Video Playlist (11 minutes total)