Centrify DirectControl 5.0.x on all platformsQuestion:
What files are modified by Centrify's adclient during an install and join operation. The below KB does not have sufficient information.KB-1748: What are the list of system files changed by Centrify unix/linux agent installation?Answer:
This article describes the system files that DirectControl 5.0.2 modifies for its operation.
Files modified during install:
For AIX platform:
1. During install, on AIX 6 or later, as part of install, DirectControl will re-arrange /usr/lib/security/methods.cfg so it points to the copy in /etc/centrifydc/methods.cfg. This is for WPAR support.
2. In methods.cfg, under CENTRIFYDC stanza, adjoin code puts
options = noprompt
because Centrify's loadable authentication module will be responsible for password prompt
Please see more detail from IBM Knowledge Center: https://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com.ibm.aix.files/methods.cfg.htm
No other system files are changed at install time.
For all other OSes:
No system files are changed at install time.
Files modified during adjoin process:
- adjoin creates /var/centrifydc boot strap files for adclient. It does not modify system files directly.
- adclient on startup performs autoedit functions to modify the various system files to hook itself in. This is configurable.
- PAM (Pluggable Authentication Modules) - different OS are done differently:
- For older version of Solaris, HPUX and AIX, there is /etc/pam.conf.
- For Linux, Mac and the new Solaris 11.1, it is the files in /etc/pam.d representing the various PAM services.
- For pam.conf, for selected services, adclient will insert lines in the beginning of the file to make sure pam_centrifydc is invoked first - for authenticating AD users, and validate AD user accounts. The same goes for /etc/pam.d/ files. However, there are various new include facilities. for example, on RH (and variant), most services include /etc/pam.d/system-auth. In this case, CentrifyDC only have to modify system-auth.
- On SLES and Ubuntu, there is common-auth, common-account, common-password, and common-session.
- NSS (/etc/nsswitch.conf)
- adclient modifies the lines: passwd, shadow and group to ensure centifydc is first in line to answer NSS queries for AD users.
- Solaris 11.1, this is done with svccfg in later releases. For Solaris, there is additional (optional) support for other services like auth_attr, user_attr, etc.
- AIX does not have NSS. it relies on LAM:
- adclient modifies /usr/lib/security/methods.cfg to add mapping for LAM libraries of CENTRIFYDC to point to /usr/lib/security/CENTRIFYDC (ditto for 64-bit).
- adclient modifies /etc/security/user to fix default stanza SYSTEM directive to make sure CENTRIFYDC is invoked first.
- in older release, we fix root stanza so it goes through CENTRIFYDC as well, but in suite 2014 (5.1.3), this is changed such that by default, root is left alone.
- adclient modifies /etc/security/login.cfg to add /usr/bin/dzsh to the login shells.
- For SLES platforms:
- When AppArmor is installed, adclient will modify /etc/apparmor.d/abstractions/authentication and nameservice to include centrifydc,so that client processes can communicate with adclient.
- There are other optional NIS maps that can be specified so that adclient will support them in NSS. These are not normally enabled, and thus does not have any impact. They are quite involved, and are not described in this document.
- Kerberos (krb5.conf, krb5.keytab)
- Every 28 days, by default, adclient will try to change machine password. As a result, it will generate a new set of keytab entries - these include the UPN, DOM name (samAccountName@domain), and all known SPNs from the computer account. One set of entries per defined encryption type.
- For CentrifyDA 2.0.x, for user login session auditing, it works by the login shell symlink to cdash. it does not modify system configuration files for this purpose.For per user auditing, /etc/shells (AIX, /etc/security/login.cfg) are modified to include cdash as login shell.
- Additionally, adclient on start up, and every 8 hours, will (re)examine all of the trusts that has discovered from AD (and NOT told to ignore).
- For each trust, it will try to locate and identify the useable DCs of the domain in the trust.
- For cross forest transitive trust, it will actually do one more level of look up.
- The resulting REALM names, and DCs are used to update krb5.conf for the various Kerberized applications to use.
- Note: GP update is run about every 90 minutes or so. if customer has configured, and enabled some of the GP to update system configuration files, it will do so - for example, sshd configuration (if enabled).