11 April,19 at 11:49 AM
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:
There are 3 categories of implications:
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.