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.

Basics: Active Directory

Directory Service
Active Directory (AD) is Microsoft's official Directory Service. It was introduced with Windows 2000 and is the successor of NTDS 4.0 (Windows NT 4.0 Directory Services).  Microsoft made some good decisions when designing AD, because it included a Kerberos implementation with their existing capabilities.
AD not only stores users, computers, printers, etc; but since version 31 (Windows Server 2003 R2) it contains the RFC 2307 schema (more on that later).

In Summary, Active Directory provides:

• An LDAP Directory that supports Discretionary Access Control Lists (securable objects)
• A Kerberos authentication infrastructure
• Group Policy, for policy enforcement and computer and configuration management 
• A Certificate Authority that leverages Group Policy for digital certificate life-cycle management
• Highly-available and highly scalable:  this is a key capability, especially for big enterprises

Basic AD Concepts

For an official explanation, go here.  I think that understanding these basic concepts will help understand the rest of this blog.
 

Component	Description
Organizational Units	OUs are like folders.  They can store objects.  Use them to organize your domain in a way that makes sense to you or your organization.
Domains	Domains are containers that share a common database and security policy.  Think about them as a major management unit.  They can span multiple locations and can contain millions of objects.
Domain Trees	Domain trees are hierarchical structures.  They are named like DNS.  E.g.  contoso.com is a parent domain.  sub1.contoso.com and sub2.contoso.com are part of the contoso tree.
Forests	A forest is a full instance of AD.  It can contain multiple domains that share the same global structure, schema and directory configuration.  Forests serve as security boundaries.
Sites and  Services	Sites are typically collections of subnets connected to a fast network link. Services are scoped to sites, so that services that rely on Active Directory can find the best connected server

Name Resolution

Active Directory depends on DNS to provide name resolution and also has the ability to store the DNS database in Active Directory, this makes DNS fully replicated and scalable; however it's possible to host AD DNS zones in BIND servers. SRV records provide the information required by hosts to find the nearest services.

Domain Controllers

Domain Controllers (DCs) contain a copy of the Active Directory database.  DCs process and return results of LDAP queries, process authentication requests (over Kerberos), and present Group Policy objects that are processed by clients.  Communications between DCs and clients are encrypted.

There are special domain controllers:

RODCs - DCs that only contain read-only data

Global Catalogs - Contain a subset of attributes for all the objects in an AD forest

Flexible Single Master Operations (FSMO) - these are DCs that hold special roles in an AD given that there are DCs that have an authoritative copy of a particular role.  Read more here.
Connection Points According to Technet:   "A Connection Point object represents one or more instances of a service that is available in a network." Centrify uses service connection points to instantiate multiple UNIX identities for AD principals.   For now, these are enough concepts.  We will cover more concepts throughout the process.