Applies to: All versions of Centrify DirectControl
How does Centrify manage Kerberos?
Centrify does the following from a Kerberos perspective on a UNIX/Linux system.
As part of joining a system to AD, Centrify sets up the UNIX's system Kerberos environment. By default, Centrify writes a keytab and krb5.conf file in /etc/ (or /etc/krb5 on some OSes). The krb5.conf file is constructed based on the intelligence the Centrify client has about AD and to assure that Kerberos applications will be able to leverage an AD KDC infrastructure (ie. Sets correct encryption types, domain to realm mappings, etc.).
Since the AD environment changes, the Centrify client continually updates the krb5.conf to assure it is up to date.
Centrify has also implemented additional security improvements around Kerberos credential caches.
These features include:
1) Cleaning up Kerberos credential caches upon logout
2) Constant sweep for credential caches on the system for users that are logged off the system
3) Creation of unique Kerberos credential caches for each logon session so that a logoff from one session does not affect other open sessions
4) Using in memory Kerberos credential caches versus file caches so that privileged users cannot steal a user's Kerberos credential caches
5) Infinite renewal capabilities to assure Kerberos tickets never expire for a logged on user which is useful for users running long jobs
Centrify has features for keytab creation and management.
Centrify delivers these value add features in addition to the core capabilities Centrify provides around authentication, authorization, policy enforcement and auditing. Centrify does not need a Kerberos environment to properly function.
1) All of this capability is 100% configurable. Customers have complete control on how Centrify behaves with regards to the Kerberos environment or whether or not you even want to leverage these capabilities from Centrify. They can be all turned off if you like. Most customers really appreciate these features and the fact they don't have to manually manage the Kerberos environment, but again, they have total control.
a. If you do not want Centrify to manage the krb5.conf, set adclient.krb5.autoedit: false in /etc/centrifydc/centrifydc.conf
b. If you do not want Centrify to create unique Kerberos credential caches for each session, set krb5.unique.cache.files: false
c. If you do not want Centrify to write the keytab in the default location, set adclient.krb5.keytab:/someotherlocation/centrify.keytab
Customers are free to make changes to the Kerberos environment as needed, although generally not recommended, as long as they understand that the maintenance of the Kerberos environment will no longer be the responsibility of Centrify.
2) Once the user logs into a system with AD credentials via Centrify, Centrify is NOT involved in any Kerberos activity moving forward. Kerberized applications will leverage the local Kerberos environment (whether that's setup by Centrify or not) to directly communicate to the KDC infrastructure, Active Directory.
a. When a kinit is performed, Centrify is not involved
b. When a user SSHs with Kerberos to a system, Centrify is not involved in the authentication
(Centrify is involved in the authorization of the user if the user is an AD user)
c. When a GSSAPI application like NFS uses Kerberos, Centrify is not involved
d. When Hadoop tries to kinit, obtain Service principals, etc., Centrify is not involved