Business Cases: Centrifying Apache HTTP Server to provide on premises AD-based SSO and Authorization

Background

Apache is the de facto Web Server for many apps and organizations have  the challenge of providing access to enterprise users that are very likely coming with Active Directory credentials;  not an issue for Centrify customers because fortunately, every centrified Unix/Linux  system has a single, secure connection to AD.

This approach results in centralized administration, streamlined authentication, policy enforcement and role-based access controls (privileged management) and since the underlying technology simplified  AD connectivity by leveraging native features and topologies (sites and services, global catalogs, subnets, one-way or cross-forest trusts, DC telemetry and caching)

In order to extend these benefits to web apps, Centrify offers the Apache HTTP SSO plugin that natively extends the authentication mechanisms of Apache to provide SPNEGO via the GSSAPI; the result is having the capability of Windows Integrated Authentication in UNIX/Linux-based Apache servers.

Translation: SSO via Kerberos or NTLM, authorization based on AD principals and the exposure of AD-attributes via native Apache APIs.  This post covers how to install the Apache plugin on a centrified server, how to get the sample application up and running, and how to incorporate it to existing Apache sites (we'll use phpPgAdmin as an example).

What is SPNEGO?

SPNEGO stands for "simple and protected GSSAPI negotiation mechanism" microsoft likes to call it IWA (Integrated Windows Authentication) and basically enables the capability for a browser to negotiate the authentication mechanism based on capabilities.  If configured correctly, the browser will attempt to use Kerberos, downgrade to NTLM if not possible fall back to basic authentication.   This means that for any Authenticated AD session, provided the browser is configured correctly the user will get SSO, otherwise they will get challeged via NTLM.

What you'll need

• A Centrified Unix/Linux system running Apache
  Joined to the domain either in zone or workstation mode.
• Apache HTTP server running
  You need to know the version and architecture to obtain the right version.
• A domain joined PC system to test access from an authenticated Windows system (or a centrified Mac) with a web browser (SPNEGO is not available on Safari)

Implementation Steps

Information gathering

1. Collect the OS version, architecture, version of Centrify adclient and if an SPN for HTTP is registered
   uname -a, adinfo -v and adinfo -C | grep http provide that information
2. Collect the service status, version, architecture and if dynamically loaded modules are enabled.
   httpd -V and httpd -l (look for mod_so.c) provide this info.
3. Make sure the Apache home page (if enabled) is accessible from the Windows client.
4. Obtain the proper version of the Apache HTTP SSO plugin from the Centrify Customer Support Center.
   Based on the information from steps 1 and 2, you can select which package to download. For example, in my CentOS 6.x, 64bit, Apache 2.2
   
   
   $ uname -a
   Linux cen3.corp.contoso.com 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

   $ adinfo -v

   adinfo (CentrifyDC 5.2.0-218)

   $ adinfo -C | grep http
   

                              http/cen3.corp.contoso.com

                              http/cen3

   $ dzdo service httpd statushttpd (pid  2811) is running...

   $ httpd -V

   Server version: Apache/2.2.15 (Unix)

   Architecture:   64-bit

   $ httpd -l | grep mod_so.c

     mod_so.c
   
   It looks like my server is running CentOS 6.x and Centrify 5.2;  the SPN for HTTP is cen3.corp.contoso.com. As far as Apache goes it is a 64 bit Apache 2.2.  Based on this information,  I will download the package "DirectControl for Apache HTTP Server on RHEL 4, 5, 6, Fedora 14, 15, 16, 17 x86_64" the version is 4.4.3 as of the original post in November 2014.  

Installation

Unpack and install the SSO plugin

$ tar xzvf centrify-apache-4.4.4-rhel3-x86_64.tgz

The installation file on RHEL for this version is called centrifydc-apache-4.4.4-rhel3-x86_64.rpm, so perform a yum or rpm install.

$ dzdo rpm -Uvh centrifydc-apache-4.4.4-rhel3-x86_64.rpm

Preparing...                ########################################### [100%]

   1:CentrifyDC-apache      ########################################### [100%]

Configuration of the Sample Application

Centrify provides a working sample app that can be used to see how to use the directives of the plugin.  To enable it, just include the path to the corresponding config file in the /etc/httpd/conf/httpd.conf file.  The sample app is in /usr/share/centrifydc/apache/samples and since I'm running Apache 2.2.x 64 bit, all I need to do is add this line 

Include /usr/share/centrifydc/apache/samples/conf/centrify22_64.conf

and restart the Web Server.

$ dzdo vi /etc/httpd/conf/httpd.conf    

==>then 'G' to go to the end and 'o'' to insert a line

# Include of Centrify Samples

Include /usr/share/centrifydc/apache/samples/conf/centrify22_64.conf  

==>Then <ESC> wq! to save

$ dzdo service httpd restart

Stopping httpd:                                            [  OK  ]

Starting httpd:                                            [  OK  ]

Verify that all is working as expected

1. Sign-in to a Windows client that is a member of your AD Domain
2. Clear your Kerberos ticket cache by opening a command line and typing "klist purge"
   C:\Users\jerry.seinfeld>klist purge
   Current LogonId is 0:0x9bb0dDeleting all tickets:Ticket(s) purged!
3. Open Internet Explorer and go to Internet Options > Security > Local Intranet > Sites > Advanced and make sure that your browser has the FQDN or the suffix of the SPN for HTTP registered by the server.
   If using Firefox, go to about:config and search for network.automatic-ntlm-auth.trusted-uris, add the SPNs suffix or FQDN there.
4. Go browse to http://<your-server>/samples.  This will expose the Centrify Sample pages.  Click on Kerberos.  If everything is correct, you should be able to see output that looks like this:
   
5. Now if you inspect your kerberos ticket cache, you'll something like this (truncated):
   C:\Users\jerry.seinfeld>klist
   Current LogonId is 0:0x9bb0d
   #0>     Client: jerry.seinfeld @ CORP.CONTOSO.COM
           Server: krbtgt/CORP.CONTOSO.COM @ CORP.CONTOSO.COM
   
   #1>     Client: jerry.seinfeld @ CORP.CONTOSO.COM
          Server: HTTP/cen3.corp.contoso.com @ CORP.CONTOSO.COM

Ticket # 0 is a Kerberos TGT and #1 is a service ticket that was requested by Jerry to access the Apache HTTP service on CEN3.

From a domain-joined computer, as it's configured by default, any valid AD user should have access. The directives to add to your Apache web sites is as follows:

 AuthType           CENTRIFYDC    # This directive enables the Centrify Plugin for the Site.

    EnableBasicAuth    true               # This directive enables Basic Auth (use only with SSL)

    EnableNtlmAuth     true               # This directive enables NTLM authentication

    EnableKerberosAuth true           # This directive enables Kerberos authentication

    Require            valid-user             # This directive controls authorization. Valid user is any AD authenticated user.

The require directive can be used for AD-based authorization, For example, if I want to only allow the members of the "Demo Users"  AD group, the Require will look like this:

Require group "Demo Users"

Plugin in Action - phpPgAdmin

In this example, we'll use the Apache SSO Plugin to AD-enable the phpPgAdmin app.  phpPgAdmin provides a web interface to manage PostgreSQL.  To install it  (e.g. in CentOS 6.x)

Add the repository

$ wget http://yum.postgresql.org/9.1/redhat/rhel-6.3-x86_64/pgdg-centos91-9.1-4.noarch.rpm

$ rpm -Uvh pgdg-centos91-9.1-4.noarch.rpm

Install the app

$ dzdo yum install phpPgAdmin

Configure the App to accept local connections

Edit the /etc/httpd/conf.d/phpPgAdmin.conf for example:

allow all from 10.0.0.0

Restart the Web Server

$ dzdo service centrifydc restart

Verify Access by browsing to your server in the /phpPgAdmin virtual directory:

To enable access with the Centrify plugin, just add the directives below inside the Location stanza of the /etc/httpd/conf.d/phpPgAdmin.conf file.  In this case we are limiting access based on membership on the Demo Users AD group.

 AuthType           CENTRIFYDC  

    EnableBasicAuth    true              

    EnableNtlmAuth     true               

    EnableKerberosAuth true           

    Require group "Demo Users"

Don't forget to restart the Apache Server!!!

Video Playlist

(11 minutes, 30 seconds total)

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (4/5)

This is part 4 of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".  (Also relates to PCI DSS 10.2)

CSC 12-11

Configure systems to issue a log entry and alert when unsuccessful login to an administrative account is attempted.

Why should you do this?
This is a detective control.  You can't control what you're not tracking.  Security operations typically leverage log aggregation technologies that tap into the native OS log facilities and centralize all this information into a centralized logging infrastructure that may or may not offer intelligence.

What is the typical approach?
On Windows:  Harvest and mine of the Windows event logs.  Surprisingly, a lot of outfits are not auditing the logon/log-off success/failure events.
On UNIX:  Harvest and mine the UNIX syslogs.

What is the real challenge for organizations?
Data vs. Noise.   How can organizations reconcile all the sources of data into meaningful information?  This is not Centrify's main capability, but it can certainly help by requiring meaningful data (e.g. change control/authorization numbers) and if all logs fail, there's always the session capture/replay capability.

Centrify's enhancers:

• Use what's native:  Uses syslog and event logs.  Unix logon/logoff success or failure are logged in the security log of the domain controller if configured by the Windows sysadmin.
• Enhance to differentiate the data from the noise:  Centrify can be configured to require reference information upon elevation, for example, change control number.
• Contextualize with DirectAudit to "clear the noise":  Enterprise Edition offers session capture and replay for both UNIX, Linux and Windows.
• Adding DirectAudit (Enterprise Edition) exceeds the requirements of PCI DSS 10.2 "reconstruct events"

Have a look:

How privileged elevation is logged (syslog) and recorded with Centrify on UNIX:

How with the Centrify dzdo validator, you can add more meaningful data to privilege elevation

How privileged elevation is logged (eventlog) and recorded with Centrify on Windows:

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (3/5)

This is part 3 of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".

CSC 12-7

Utilize access control lists to ensure that administrative accounts are used only for system administration activities, and not for reading e-mail, composing documents, or surfing the Internet. Web browsers and e-mail clients especially must be configured to never run as administrator.

Why should you do this?
To limit the exposure of administrative accounts to malware.

What is the typical approach?
On Windows:  Two sets of accounts are given to administrators,  a "dash-a" account and a normal account.  On the server side, to access the internet there's an air gap or the proxy server does not allow the servers or the "dash-a" account to go out to the internet.  The IE Enhanced Security mode is enforced.

On UNIX:  Systems are crippled from internet access or GUIs.  The email/surfing computer is different from the server systems.

What is the real challenge for organizations?
Human nature - people find ways to go around this, especially in the process of doing their actual jobs.  In the times of "knowledge on demand" having an internet browser to consult FAQs and community boards is very common.

Centrify's enhancers:
It's not all about just giving separate accounts, but being able to establish additional controls, like scope of systems, types of roles, privilege effectiveness, logon experience and flexible assignments.

CSC 12-10

Configure systems to issue a log entry and alert when an account is added to or removed from a domain administrators' group, or when a new local administrator account is added on a system.

Why should you do this?
At basic level this is a detective control, all administrative access should be traced back to an approval, otherwise this is misuse or a data-breach.

What is the typical approach?
Log aggregation.  Logs from multiple systems are sent to an enterprise security operations dashboard.

What is the real challenge for organizations?
Log aggregation lends itself for NOISE, then the log aggregation needs to be complemented by a data mining engine;  this is all to make sure that what's happening out there is authorized.

Centrify's enhancers:

• A Centrify deployment limits the local root or administrator account to break-glass situations.  They are not needed.
• Centrify (without any modification) augments log aggregation.  Therefore, the existing collection mechanisms can have richer data.
• Plus, Centrify reporting shows you what are the AD principals that grant the administrative roles, if things are tied to a Workflow or an IDM, anything that is not there by way of approvals will be identified quickly or rolled back.
• Plus Centrify DirectAudit provides the ability to view or audit who makes changes to the governance model.

Short video:

Basics: Centrify User Suite

Background

Centrify has two product lines.  Server Suite and User suite. With the release of Suite 2014.1, we are starting to see some synergy between product lines and since the blog has focused exclusively on server suite, we figured we need to expand, but first, let's explore this product.

What is Centrify User Suite?

Well, let's see:

• It's a cloud-based Identity Provider
• It provides access and SSO to on premise and cloud apps
• Provides Mobile Device, Application and Container Management
• It provides self-service capabilities (device enrollment, management, self-service password reset)
• Provides a catalog of over 2500 templates for fast publishing of Web, SaaS (SAML, WS-Fed, etc) and Mobile Apps.
• Provides Multi-factor Authentication
• Provides AD-based, Cloud-based or Mixed Identity
• Works with Active Directory in a non-intrusive (no directory duplication) and secure way
• Provides a policy engine for the directory
• Provides Role-Based Access for Application access and Privilege Management
• Provides multi-geography, shared or dedicated hosting
• Provides an interface that
• Provides access in rich (web) and mobile clients
• Provides tenants with their own publicly-rooted certification authority
• Provides access to apps can be via a self-service portal (provider-initiated) or application initiated.
• Extensible by way of an SDK, customizations and branding.
• Recognized by Gartner as a visionary in the 2014 IDaaS MQ.
• Continues to add capabilities at a near monthly rate

Where's the value?

In my opinion, the biggest value of user suite is that in the same spirit of server suite, for any organization with AD, provides the fastest, most efficient and secure way to adopt SaaS applications, it does it without breaking the bank and without aspiring to become the organization's directory of record.  The mobile, directory and hybrid identity and policy services are the cherry on top.

Here's what you don't need to do with user suite:

• Deal with servers in the DMZ
• Deal with understanding on premise federation technologies
• Deal with understanding app authentication or federation patterns
• Deal with publicly rooted certificates
• Pay for expensive MDM solutions
• Pay for 2-factor authentication solutions
• Worry about geographically located solutions
• Worry about language and branding
• Worry about having a split strategy for mobile devices

This translates to tighter control, time to market, added capabilities, etc.

What you must know and have:

• What are the different Cloud IdPs and their pros and cons.
• A policy for cloud-based access controls
• A plan for service availability

We'll explore topics related to cloud in Security Corner.

User Suite Tour

Labs and User Suite

Updated labs logo

We will keep things practical expect a lot of labs, howto's, etc.  We will be using Office365, Google Apps and Salesforce as our key apps given that they either provide a free or cheap version.  As we can find trial apps we will explore them.  As it relates to mobile, we will use iOS, Android and OS X.

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (2/5)

This is the continuation of the series on leveraging Centrify to implement SANS Critical Security controls - Section 12: "Controlled use of Administrative Privileges".

CSC 12-3

Configure all administrative passwords to be complex and contain letters, numbers, and special characters intermixed, and with no dictionary words present in the password. Pass phrases containing multiple dictionary words, along with special characters, are acceptable if they are of a reasonable length.

CSC 12-5

Ensure that all service accounts have long and difficult-to-guess passwords that are changed on a periodic basis, as is done for traditional user and administrative passwords.

CSC 12-8

Through policy and user awareness, require that administrators establish unique, different passwords for their administrative and non-administrative accounts. Each person requiring administrative access should be given his/her own separate account. Users should only use the Windows "administrator" or UNIX "root" accounts in emergency situations. Domain administration accounts should be used when required for system administration instead of local administrative accounts.

CSC 12-9

Configure operating systems so that passwords cannot be re-used within a timeframe of six months.

Why should you do this?
Because the password policy for admin accounts should be a step-up from regular users given that they hold the keys to the kingdom. 

What is the typical approach?
On Unix:  cracklib PAM module.
On Windows:  group policy.

What is the real challenge for organizations?
Human nature - sysadmins love their root or administrator accounts given their inherent mistrust in software, and unfortunately vendors promote fragmentation. 

Centrify's enhancers:
It's the solution that can accomplish this with true RBAC (allowing the administrative accounts to be put away) plus the tight AD integration with Group Policies (and support for fine-grained password policies).  In addition, Centrify's resiliency truly makes sure that the root or administrator account are only needed in emergency situations.

In UNIX - privilege elevation using Centrify-enhanced sudo (no sudoers) - DirectAuthorize (DZ)
In Windows - privilege elevation with the Centrify agent for Windows (DZ Win)

CSC 12-4

Before deploying any new devices in a networked environment, change all default passwords for applications, operating systems, routers, firewalls, wireless access points, and other systems to have values consistent with administration-level accounts.

Why should you do this?
Anyone that has had a Linksys router knows the answer to this.  In UNIX/Linux, there's too much reliance on the root account or the switch user command.  Local administrator in Windows is treasured by Windows admins.

What is the typical approach?
Unfortunately, in a lot of environments there's too much sharing of these accounts.  TACACs, RADIUS and password vaults help with network appliances.

What is the real challenge for organizations?
Human nature.  A Unified approach for these accounts like a password vault is typically the right solution.

Centrify's enhancers:
Due to the true RBAC and privilege elevation methods employed by Centrify, organizations can decrease their costs in password vault user licensing costs, by just leveraging it for non-human admin accounts, while the rest of the population uses RBAC.  The end-to-end nature and resilience mechanisms, makes it more efficient to align with regulatory requirements without a single point of failure.  In UNIX, single-user-mode or Windows safe mode without network will be the only instances in which these accounts are needed.

No need to check-out the keys to the kingdom each time the root, or administrator accounts are needed.

• Tied to your identity infrastructure (Active Directory)
• True Role-based access
• Minimal process impact
• Increased accountability using the native tools (syslog/event viewer)
• Extensible to session capture and replay

Tried and true AAA.

CSC 12-6

Passwords should be hashed or encrypted in storage. Passwords that are hashed should be salted and follow guidance provided in NIST SP 800-132 or similar guidance. Files containing these encrypted or hashed passwords required for systems to authenticate users should be readable only with super-user privileges.

Why should you do this?
There was a time in the security discipline in which encryption was thought to be the solution;  time and different attack vectors have proven this to be wrong; however, encryption in transit and encryption at rest are a must.  There's an arms race going on because although algorithms are strong, Moore's law, virtualization and well-funded and motivated agents are lurking.

What is the typical approach?
Rely on the OS, Directory or the appliance.  Fortunately Microsoft has this very-well documented.

What is the real challenge for organizations?
Human nature, again  It doesn't matter how hard your encryption is if credentials are shared or clear-text passwords are used in scripts or other facilities.

Centrify's enhancers:

• More US-federal government certifications that I can even pretend to understand
• Common Criteria
• FIPS 140-2 Validated

However, the bullets above are just marketing speak if we don't back-it up with examples:

• Kerberized tools:  install.sh adjoin, adleave, adkeytab, adcert, dzdo + more are all Kerberized, which means no need to actually store passwords.  The Hadoop and MongoDB examples illustrate practical use.
• Microsoft CA PKI client:  Use Certificates in your Unix, Linux, Mac systems.
• Extend it to your HTTP, Java, SAP or DB2 needs.

Why even have the problem when you can completely avoid it?

Security Corner: Centrify and SANS Critical Security Controls - A Near Perfect Fit (1/5)

Background

One of our prospects looking at the Centrify privileged elevation tool for Windows, just highlighted to me that Server Suite is very well-aligned with the SANS Critical Security Controls Section 12: "Controlled use of Administrative Privileges" so I decided to take a deeper look.  We will cover 2 each post until we have the 14 topics explored.

Controlled use of Administrative Privileges

CSC 12-1

Minimize administrative privileges and only use administrative accounts when they are required. Implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior.

Why should you do this?
Because the more somebody uses a privileged account the highest risk of malware being executed with elevation, more exposure to attacks like pass-the-hash attack, etc. 

What is the typical approach?
On Unix:  sudo, password vaults or RBAC
On Windows:  dash-a accounts, password vaults or RBAC

What is the real challenge for organizations?
Well, sudo is simple, proven but a pain, PVs just give out the keys to the kingdom in a controlled way - great for appliances BTW, and RBAC is hard to implement given that it typically requires multiple solutions.

Centrify to the Rescue:  Centrify Server Suite offers a serverless, cross-platform Unix, Linux and Windows based solution that provides access governance with RBAC leveraging AD.

End Result: The ability to limit access, control privileges (no giving out the keys to the kingdom) and reusing processes, cross platform, using existing technology and infrastructure.  This was explored in the 10-minutes PCI 7 challenge:.

CSC 12-2

Use automated tools to inventory all administrative accounts and validate that each person with administrative privileges on desktops, laptops, and servers is authorized by a senior executive.

Why should you do this?
This is all about keeping track and being able to attest who approved the type of access that users have.  It's also an administrative preventative control.  This is not limited to domain accounts but local accounts as well

What is the typical approach?
The solution to this is basically workflow.  Unfortunately, simple workflow engines are hard to come by, or they are tied to a monster solution.  Scripts are popular as well.

What is the real challenge for organizations?
This should be relatively simple, but vendors don't make this easy.  Surprisingly PV vendors do a good job due to the appliance/proxy based nature of their solutions. Go to the vault, request access, approver gets notified, approves/denies, then the access is granted/denied.  Great for break/fix.

How Centrify helps?  Although Centrify does not provide workflow capabilities today (wink);  it makes it very easy for any IdM or workflow engine to perform the functions upstream.  Since the process boils down to AD groups and any decent workflow engine can do this, then the solution looks like this:

Utilities:  Automatic provisioning and role assignment is often achieved with ZPA.  This post and video cover a basic design:



In the next post we'll continue with the list.

Labs: MongoDB-AD Integration with Centrify - The Kerberos Remix

Background

In the previous post, we discussed how with Centrify, MongoDB authentication can be streamlined and we discussed SASL Auth integration.  We also discussed how to leverage the authorization capabilities of Centrify to limit access to MongoDB via PAM with SASL.

However, SASL is a simple option and can be greatly enhanced by using a different option.

Advantages of using AD Kerberos with Centrify

Centrify automatically creates and maintains the Kerberos environment of a UNIX, Linux or Mac OS X environment, no need to deal with /etc/krb5.conf files, machine keytabs or incompatibilities because Centrify's shared objects are optimized to work with AD regardless of the complexity of the AD environment (one-way trusts, cross-forest trusts, etc).

The key benefit here is time to production.  When App Developers or DBAs don't have to worry about standing up an environment (such an MIT Kerberos realm), maintaining and understanding Kerberos, it's easier to focus on the tasks around MongoDB.  Active Directory is your Kerberos infrastructure and Centrify is the enabler.

From a business perspective consistency is preserved by eliminating duplication of capabilities and processes.
From a security perspective, the access model remains the same and no additional attestation mechanisms need to be created.
From the user's perspective they are more productive because we can eliminate an additional authentication prompt (remember how bad it looked when we saw the plaintext passwords on the screen?)

Another benefit is the utilities like adkeytab that allow for the provisioning and maintenance of service accounts and kerberos key tables in your systems.  MongoDB uses the GSSAPI interfaces to provide Kerberos authentication.

Moderation note:  This post requires that you understand the basics of Active Directory and Kerberos.  If any of these terms: domain controller, kdc, service principal name, user principal name, TGT, TGS, DNS, etc, are foreign to you, please do some background study.

Basics:  What is GSSAPI?

Wikipedia:  "The Generic Security Service Application Program Interface (GSSAPI, also GSS-API) is an application programming interface for programs to access security services.."

The key here is that MongoDB supports Kerberos via the GSSAPI interfaces, Since Centrify makes Kerberos work effortlessly , the implementation is relatively simple:

MongoDB will start with GSSAPI authentication enabled and will use the key table file (keytab file) of an AD service account that has a UPN set to mongodb/<fqdn of system>@DOMAIN and an SPN set to mongodb/<fqdn of system>.  This will allow for it to request a ticket-granting-ticket or a service ticket depending on the call.

Implementation  (on CentOS)

Note:  You will need the Enterprise Edition of MongoDB to get this going.  For instructions of how to set up, go here: http://docs.mongodb.org/manual/tutorial/install-mongodb-enterprise-on-red-hat-or-centos   (use CentOS to follow along) - I will be elevating with dzdo:

Use adkeytab to create the service account and key table file for MongoDB

Adkeytab has been discussed previously here.  Remember that when you use it, the service account's password is randomized;  this eliminates the risk of several people knowing the credentials of a shared account, however, makes the burden around protecting the keytab file.  Make sure you have protocols around this.  If you're using separation of duties, the UNIX admin may not have the rights to create a service account in AD, so you have to work in cooperation with the AD team.
Note:  Remember that the Centrify Kerberos tools are in the /usr/share/centrifydc/kerberos/bin directory.

Step 1:  Understand the adkeytab parameters:

• this is a new account  (the -n option is required)
• credentials are required to create the new account (-u <ad user that can create>)
  e.g. jerry.seinfeld  (the AD admin in my environment)
• a key table file will be created (-K /path/to/file)
  e.g. /etc/mongodb.keytab
• An OU for service accounts in AD will be used (-c "dn of ou")
  e.g. "ou=Service Accounts"
• A UPN will be specified (-U service/principal@REALM)
  e.g. mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM
• A SPN will be specified (-P service/principal)
  e.g. mongodb/cen3.corp.contoso.com
• The UserName (samAccountName) will be different than the cn (-S name)
  e.g. mongodb.service  (note:  the limit here is 20 chars)
• The final parameter is the cn
  e.g. mongodb

Step 2:  Run adkeytab in verbose mode  (elevated to be able to copy on /etc)

$ dzdo adkeytab -V -n -u jerry.seinfeld -K /etc/mongodb.keytab -U mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM -P mongodb/cen3.corp.contoso.com -c ou="Service Accounts" -S mongodb   mongodb

ADKeyTab version: CentrifyDC 5.2.0-218
Options
-------
use machine ccache: no
domain: corp.contoso.com
server: null
gc: null
user: jerry.seinfeld
container: ou=Service Accounts
account: mongodb
trust: no
des: no
jerry.seinfeld@CORP.CONTOSO.COM's password:
Attempting bind to corp.contoso.com site:CorpHQ server:dc1.corp.contoso.com: ccache:MEMORY:0x5666c0
Bind successful to server dc1.corp.contoso.com
Attempting bind to GC domain:corp.contoso.com site:CorpHQ gcserver:dc1.corp.contoso.com ccache:MEMORY:0x5666c0
Bound to GC server:dc1.corp.contoso.com domain:CORP.CONTOSO.COM
Searching for AD Object: filter = (samAccountName=mongodb.service), root = DC=corp,DC=contoso,DC=com
Searching for AD Object: filter = (samAccountName=mongodb.service$), root = DC=corp,DC=contoso,DC=com
AD Object not found.
Building Container DN from OU=SERVICE ACCOUNTS
Account 'CN=mongodb,OU=SERVICE ACCOUNTS,DC=corp,DC=contoso,DC=com' does not exist
Search for account in GC: filter = (samAccountName=mongodb.service), root = DC=CORP,DC=CONTOSO,DC=COM
SAM name 'mongodb.service' not found in GC
Problem to create account; try again with no password required
Searching for AD Object: filter = (samAccountName=mongodb.service), root = DC=corp,DC=contoso,DC=com
AD Object found: CN=mongodb,OU=Service Accounts,DC=corp,DC=contoso,DC=com
Key Version = 1
Adding managed account keys to configuration file: mongodb
Changing account 'mongodb' password with user 'jerry.seinfeld@CORP.CONTOSO.COM' credentials.
Searching for AD Object: filter = (samAccountName=mongodb.service), root = DC=corp,DC=contoso,DC=com
AD Object found: CN=mongodb,OU=Service Accounts,DC=corp,DC=contoso,DC=com
Key Version = 2
Success: New Account: mongodb

Step 2:  Verify the AD user account attributes and make sure you can get a TGT and a TGS with the keytab  (elevating to read from /etc)

$ adquery user -PS mongodb

userPrincipalName:mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM

serverPrincipalName:mongodb/cen3.corp.contoso.com

Principals are OK.

$ dzdo /usr/share/centrifydc/kerberos/bin/kinit -kt /etc/mongodb.keytab mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM

[cosmo.kramer@cen3 ~]

$ dzdo /usr/share/centrifydc/kerberos/bin/klist                                                               Ticket cache: FILE:/tmp/krb5cc_1149240408

Default principal: mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM

Valid starting     Expires            Service principal

10/25/14 14:19:40  10/26/14 00:19:40  krbtgt/CORP.CONTOSO.COM@CORP.CONTOSO.COM

        renew until 10/26/14 14:19:40

TGT successful.

$ dzdo /usr/share/centrifydc/kerberos/bin/kinit -kt /etc/mongodb.keytab -S mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM mongodb

$ dzdo /usr/share/centrifydc/kerberos/bin/klist

Ticket cache: FILE:/tmp/krb5cc_1149240408

Default principal: mongodb@CORP.CONTOSO.COM

Valid starting     Expires            Service principal

10/25/14 14:20:00  10/26/14 00:20:00  mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM

        renew until 10/26/14 14:20:00

TGS successful

Step 3: Secure the Keytab

Copy the keytab to /var/lib/mongo

$ dzdo mv /etc/mongodb.keytab /var/lib/mongo/mongodb.keytab 

Change the owner of the keytab to mongod

$ dzdo chown mongod:mongod /var/lib/mongo/mongodb.keytab 

Set up a test user and configure MongoDB for GSSAPI authentication

Note:  If you don't know how to properly set up users in Mongo and you're following along from the SASL posting, just disable auth and create the user.  We will reenable it later.

Step 4:  Make sure that SASL is configured to work with PAM and identify the path for the socket.

$ mongo
> use $external
switched to db $external
> db.createUser({user: "j.peterman@CORP.CONTOSO.COM",roles: [ { role: "read", db: "reporting" }]})
Successfully added user: {
        "user" : "j.peterman@CORP.CONTOSO.COM",
        "roles" : [
                {
                        "role" : "read",
                        "db" : "reporting"
                }
        ]
}

The result should be success.  Keep in mind that the user's domain has to be in CAPS.


Step 5:  Set the KRB5_KTNAME environment variable for the keytab

vi /etc/sysconfig/mongod

and add this line:

export KRB5_KTNAME=/var/lib/mongo/mongodb.keytab

Step 6:  Edit the mongodb.conf file to enable GSSAPI

Comment out the bind_ip directive. For Kerberos SSO to work, you must bind over the network.

Otherwise the appropriate will be localhost versus the actual hostname of the system

#bind_ip=127.0.0.1

Re-enable authentication.  Note that you can enable both SASL and GSSAPI

auth=true

setParameter=saslauthdPath=/var/run/saslauthd/mux

setParameter=authenticationMechanisms=PLAIN,MONGODB-CR,GSSAPI

Restart MongoDB and make sure there are no errors.
$ dzdo service mongod restart

Test GSSAPI/Kerberos authentication

Step 7:  Log in to the system with the externally identified user that was created with the full UPN, inspect the Kerberos TGT.

$ /usr/share/centrifydc/kerberos/bin/klist
Ticket cache: FILE:/tmp/krb5cc_1149240919
Default principal: j.peterman@CORP.CONTOSO.COM

Valid starting     Expires            Service principal
10/25/14 15:23:35  10/26/14 01:23:35  krbtgt/CORP.CONTOSO.COM@CORP.CONTOSO.COM
        renew until 11/01/14 15:23:35
10/25/14 15:25:13  10/26/14 01:23:35  mongodb/cen3.corp.contoso.com@CORP.CONTOSO.COM
        renew until 11/01/14 15:23:35

Notice that during login, Centrify will automatically kinit and enable your TGT.

Step 7:  Launch mongo with the system name and perform the testing.

mongo cen3.corp.contoso.com
MongoDB shell version: 2.6.5
> db.getSiblingDB("$external").auth({mechanism: "GSSAPI",user:'j.peterman@CORP.CONTOSO.COM',})
1

Output of 1 proves that authentication with Kerberos/GSSAPI was succesful.

> db.getSiblingDB("$external").auth({mechanism: "PLAIN",user:'j.peterman',pwd:'<jp's password>',digestPassword: false})
1

Both GSSAPI and SASL Plain can be used simultaneously.  Kerberos is superior due to the fact that the user eliminates one prompt ad a readable password.

Video