Active Directory and Centrify:  Plug-n-play Kerberos for UNIX, Linux and Mac
Aside from establishing a secure communications channel with AD, provide identity information and privilege management, in UNIX, Linux or OS X systems, Centrify takes care of the Kerberos environment.  At a high-level, here's what happens:

Configuration: The /etc/krb5.conf file is modified to include information about Active Directory's Kerberos realm, this includes encryption levels, realms (domains), KDCs (domain controllers) and trusted realms (using Microsoft's Kerberos extensions)
This capability is very convenient, because when AD administrators add or decommission domain controllers or establish trusts, there's no need to go back and update the krb5.conf file.
In failure scenarios, authentication also "just works" provided there's communication with the target DCs.
System Key Table: The system keytab (typically /etc/krb5.keytab) is updated with entries for the Service Principal Names (SPNs) created.

$ dzdo klist -kt /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp         Principal
---- ----------------- ------------------------------------------
   5 09/10/15 07:28:33 nfs/engcen6.centrify.vms@CENTRIFY.VMS
   5 09/10/15 07:28:33 nfs/engcen6@CENTRIFY.VMS
   5 09/10/15 07:28:33 http/engcen6.centrify.vms@CENTRIFY.VMS
   5 09/10/15 07:28:33 http/engcen6@CENTRIFY.VMS
   5 09/10/15 07:28:33 host/engcen6.centrify.vms@CENTRIFY.VMS
   5 09/10/15 07:28:33 host/engcen6@CENTRIFY.VMS
   5 09/10/15 07:28:33 ftp/engcen6.centrify.vms@CENTRIFY.VMS
   5 09/10/15 07:28:33 ftp/engcen6@CENTRIFY.VMS
   5 09/10/15 07:28:33 cifs/engcen6.centrify.vms@CENTRIFY.VMS
   5 09/10/15 07:28:33 cifs/engcen6@CENTRIFY.VMS
   5 09/10/15 07:28:33 engcen6$@CENTRIFY.VMS

Service Principal Names (SPNs) in AD:  At join, by default, Centrify will create SPNs for host, nfs, http, ftp, and CIFS.  This can be verified with the adinfo -C command

$ adinfo -C
Computer Account Diagnostics
  Joined as: engcen6
  Trusted for Delegation: false
  Use DES Key Only: false
  Run adinfo as root to examine local key info
  Key Version: 5   (local key version unavailable)
  Service Principal Names: nfs/engcen6.centrify.vms
                           nfs/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


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

Operating System Version: 6.1:6.6

Optimized Kerberos Tools:   Centrify's MIT Kerberos tools are placed in the /usr/share/centrifydc/kerberos/bin folder.  These tools are optimized to work with Microsoft's Kerberos extensions.  In addition, tools like adkeytab are available to administrators.  adkeytab provides much more robust capability than traditional tools like kutil.

Other Configuration:
Name Resolution:  Although the Centrify's adclient will respect the settings in /etc/resolv.conf, Centrified clients support advanced capabilities like Dynamic DNS updates and maintain an independent DNS cache.  Part of the telemetry calculations performed when making sure DC connectivity is optimal include DNS sweeps.
Time Synchronization:  Kerberos has a mechanism to deter replay attacks that relies on KDCs and Kerberos clients to keep with a skew of 5 minutes or less.  Upon system join, system time uses the AD domain controllers as time source.

Finally, there's the issue of Kerberos principal format.  With Centrify, regardless of the case sensitivity of the AD user or UPN (Kerberos expects user@REALM) , Centrify will always work Active Directory implementations.

What about support for Mixed Environments?
Centrify has very large organizations that may fall in the following categories:

• Government, commercial, educational or research organizations that have MIT Kerberos realms defined, but need to provide interoperability while they migrate completely to Active Directory.
  We have also seen this with commercial organizations that have implemented MIT Kerberos realms for a particular application (e.g. Hadoop), but are ready to eliminate the duplicity and complexity introduced.

• Organizations that have legitimate reasons to maintain MIT Kerberos implementations for critical apps or other situations.

There are 3 categories of implications:

1. Name resolution implications:  In an ideal scenario, DNS is always symmetric and hierarchical; but we've seen situations in which systems have asymmetric configurations.
2. Time source implications:  Although ideally, all systems sync up time with a hierarchical time source, sometimes IT organizations are quite fragmented.
3. Kerberos configuration implications:
   The Centrify client will only write information about local and trusted Active Directory realms and KDCs
   The system keytab is automatically set up or overwritten by adclient during system join.

With all those challenges, the idea is to eliminate additional complexity.  
 
Centrify Parameters to Support Mixed Scenarios

Here's a sample mixed scenario:

In a normal Centrify setup, James won't be able to log in or use tools in the EXAMPLE.COM realm, however everything will work fine for UNIX-enabled users in the corp.contoso.com.  Other key areas are the different time sources and potential asymmetry of DNS.

To overcome these issues, Centrify has 4 parameters (with corresponding Group Policy Objects):

adclient.krb5.autoedit:  when set to true (default), centrify's agent will maintain the system's Kerberos configuration (/etc/krb5.conf) file.  when set to false, the file will be left alone.

adclient.krb5.keytab:/path/to/file.keytab:  when set, this parameter will enable administrators to place the keytab used with AD in a different location than the default system keytab (/etc/krb5.keytab)

dns.dc.domain_name:  This configuration parameter allows administrators to specify domain controllers that service the target domain.  E.g.
dns.dc.corp.contoso.com: dc1.corp.contoso.com dc2.corp.contoso.com

adclient.sntp.enabled:  This parameter tells the agent if it will use the Windows Time Service running in the domain controller as the time source.


Tradeoffs
With this unorthodox configuration (basically multiple authentication sources) there tradeoffs;  part of the reason of any Centrify deployment is to promote simplicity.  For example, once the autoedit parameter is introduced, organizations lose the automatic maintenance of AD topology for Kerberos, however, this can be managed via group policy, or any config management tool (like Chef, Puppet, etc), but it requires constant communication between the UNIX/Linux or Mac administrators and Active Directory Administrators.

The benefit here is that Centrify has the maturity and flexibility to support these kinds of scenarios.

Ideally this scenario is only a temporary one. 

For more information, check out the Centrify Configuration Parameters Guide.