Business Problems: Using Centrify on Mixed Kerberos Environments (UNIX, Linux, OS X)

Background

Organizations typically use Centrify's Server Suite to simplify the implementation of Kerberos by using Active Directory and the DirectControl (adclient).  However, in special situations, there may be a need to support independent MIT Kerberos realms along with Active Directory participation.

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:

Kerberos Configuration

• 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 failover 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) and information required for it to work in Active Directory.
• 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:

• Name resolution implications:  In an ideal scenario, DNS is always symmetric and hierarchical; but we've seen situations in which systems have asymmetric configurations.
• Time source implications:  Although ideally, all systems sync up time with a hierarchical time source, sometimes IT organizations are quite fragmented.
• 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.  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.