Installing the Agent - Multiple Avenues
Centrify provides multiple ways for system administrators to install and deploy the Centrify agent. The agent (adclient) is supported in a variety of systems; the rule of thumb is this: any commercial system that uses PAM and NSS is likely to be supported. A great resource is
this page.
The installation options are:
- Native packages: Centrify includes native packages for each platform (rpm, deb, etc.)
The benefit of native packages is that it allows the use of existing package management and software distribution, repositories or configuration management platforms. Here's an example with YUM.
- The installation script (install.sh): This is an orchestrator that will install the software based on an interactive menu or an answer file.
The benefit of install.sh is that it allows for easy manual setup and the integration of scripting.
- DevOps tools like Chef, Puppet, Satellite or Ansible:
- Example with Chef
- Example with Puppet
- Deployment Manager: This is a free tool included with the suite designed to aid in deployments for very small environments. It's not a substitute for a software distribution or configuration management solution.
Moderation Note: Deployment Manager is not covered in this blog.
When the Centrify agent is installed, the binaries are in place, but there are no changes to the system until it is joined to Active Directory.
Joining Active Directory on Windows - Basics
When a Windows computer joins Active Directory (at a very high level) these operations are performed:
- The user account performing the join operation is checked for the right authorization
- AD is checked for any duplicate computer account names
- A computer object is created for the computer account
- A secret is shared between Active Directory and the Computer
This shared secret allows for encrypted communications (secure channel), Kerberos ticket processing, etc.
- Domain Users (and any trusted domains) become users for the computer
- Domain Administrators can perform administrative duties in the computer
- Targeted Group Policies are set to be processed
Note: to really find out what happens when you join a Windows computer, just read the NETSETUP.LOG file under the system folder (or %systemroot%)\debug folder.
In general there are 3 major pre-requisites to perform a join in Windows:
- The system needs to be able to resolve the name of the domain (proper DNS configuration)
- The system needs to be able to establish communications correctly
- The user account performing the join is authorized for the operation in the target container
The process is very similar with the Centrify agent, step 5 being the most notable exception. In standard edition in zone mode, only Unix-enabled users with the proper rights can log in to the AD-joined UNIX/Linux system (centrified system).
Joining UNIX/Linux (and Mac) systems to Active Directory - Basics
adcheck - the Quality Assurance tool
adcheck is a tool included with the package that is used to assess the readiness of the system to join AD. The general syntax is:
./adcheck-platform domain
E.g. for RedHat 64 bit:
./adcheck-rhel3-x86_64 corp.contoso.com
It's also a great tool to troubleshoot connectivity issues. It will check
OSCHK : Verify that the system is supported by that version of the package.
PATCH : If there's any pre-requisite OS patches (great for AIX, HPUX and Solaris)
PERL : Perl is required to perform the installation tasks and to process group policies.
SAMBA : If the system is running it, will warn to use Centrify-enhanced Samba for proper UID/GID assignments
SPACECHK : Check if there is enough disk space in /var /usr /tmp
HOSTNAME : Verifies if the hostname is acceptable (localhost and some others aren't allowed)
NSHOSTS : Verifies the configuration of this entry in the /etc/nsswitch.conf
DNSPROBE : Will try to communicate the DNS servers. Will warn if there's only one entry.
DNSCHECK : Same as above.
WHATSSH : Verifies that the SSH version has been tested and there's no issues. It will warn to use Centrify-enhanced SSH if you will use Kerberos authentication. Stock SSH will be fine.
SSH : Checks the SSH configuration
DOMNAME : Will check for the domain name, it will warn if it's a .local domain.
ADDC, ADDNS, ADPORT, GCPOR, DCUP, SITEUP: It will perform a series of checks:
- SRV records for the domain
- DNS communications
- Will verify that the proper communication ports are open for each DC and Global Catalog
- Will check for domain controllers in the AD Site.
DNSSYM : It will check the consistency of the DNS configuration.
ADSITE, GSITE: It will check that the subnet is within an AD Site and that the correct site is selected.
TIME : It will check that the clock between AD and the local time source is not skewed more than 5 minutes (Kerberos requirement)
ADSYNC : It will check that the domain controllers are in the same page.
Typically, the most common issues are around DNS configuration, Communications, DNS symmetry and clock skews. Solve all the issues before moving forward. Warnings can be typically ignored but should be addressed depending on the situation. After that, you can move on to join the system
adjoin - to Join Active Directory Domains
With Centrify, computers can be joined with:
- install.sh in interactive or unattended (quiet) mode
- the adjoin command
- with Deployment Manager
All these methods ultimately use the adjoin command.
Joining a system is a privileged operation, so it has to be performed as root or elevating with sudo.
Adjoin Syntax
usage: adjoin [options]
domain
options:
-u, --user user[@domain] user name
-p, --password pw user password, prompts if absent
-c, --container dn subtree to create below or move to.
LDAP is used to create
computer object,
if computer object
does not exist.
-n, --name comp computer account name
-N, --prewin2k name pre-windows 2000 computer account name
must be 19 characters or less
-D, --dnsname name optional parameter to override the
dNSHostName
attribute in the computer object
-f, --force overwrite existing joined
computer
-a, --alias alias add an alias computer account name
-C, --noconf do not update PAM or NSS config
-z, --zone zone zone to join
-s, --server ds domain server for join operations
-Z, --zoneserver ds domain server for zone operations
useful if zone is in
another domain
-g, --gc ds domain server for global catalog
searches
-U, --upn upn user principal name for the account
-T, --trust trust computer for delegation,
requires
administrator
permission
-k, --des use DES key only
-P, --precreate precreate computer and extension
object
-m, --compat make computer and extension object
compatible with
DirectControl 2.x.
-S, --selfserve use reset computer account
credentials to perform
a self-service join
-w, --workstation join computer to Auto Zone
-l, --ldap
use LDAP method to
create the computer object
-x, --extramap mapname add named nss map to nss configuration. Can
be repeated
-i, --noinit skip cache preload
-A, --attempt attempt to grant authenticated
users read permissions to PSO objects so that the
computer account can read fine grain password security policies in
the current domain.
Note that the
administrator(s) may also need to grant authenticated users read
permissions to PSO objects in trusted domains and forests as well for more
accurate password expiration times for cross domain and cross forests users.
-v, --version print version information
-V, --verbose print debug information for each operation
-h, --help print this help information and
exit.
Example: To join the corp.contoso.com domain in the HQ zone, place the computer account in the Servers OU under the top level UNIX OU in verbose mode with Jesse's AD account, the adjoin command is:
adjoin -z HQ -c "OU=Servers,OU=UNIX" -V -u jessie.matthews corp.contoso.com
What happens in a system when you join Active Directory?
Several things happen:
Type
|
On
|
File location
|
Kerberos configuration file
|
Most platforms
|
/etc/krb5.conf
|
|
Solaris
|
/etc/krb5/krb5.conf
|
Kerberos keytab file
|
Most platforms
|
/etc/krb5.keytab
|
|
Solaris
|
/etc/krb5/krb5.keytab
|
NSS configuration file
|
Most platforms
|
/etc/nsswitch.conf
|
PAM configuration file
|
Red Hat Linux
|
/etc/pam.d/system-auth
|
|
All other Linux
|
/etc/pam.d/*
|
|
HPUX, Solaris
|
/etc/pam.conf
|
LAM configuration file
|
AIX
|
/usr/lib/security/methods.cfg
|
Login control files
|
AIX
|
/etc/security/user
|
The previous configuration is saved to be restored if the system leaves the domain.
(*) Note that these changes only apply to the centrifydc (adclient) program. If you also install Centrify-enhanced OpenSSH, other modifications pertaining to the SSH server are made.
Sample entries in /etc/nsswitch.conf file after a system is joined to AD:
passwd: centrifydc nis files
shadow: centrifydc nis files
group: centrifydc nis files
What does this mean?
Name Server Switch is a UNIX facility that allows for network-based services, including directory services. As a consequence:
a) Any NSS-enabled program will check for the user or group in AD (centrifydc), an existing NIS domain, and then in the local /etc/passwd or /etc/group files.
b) Users from local files, NIS or LDAP can coexist happily, also migrations are easier because they can be done in a phased-approach.
c) This also means that local users, service accounts and super user accounts are available and can be managed locally.
d) Hands-off approach: any NSS (or PAM, or Kerberos-related) file does not need to be touched. Centrify makes it work out of the box. This includes if there's any changes in Active Directory.
Entries in the /etc/pam.d/system-auth
# lines inserted by Centrify
Direct Control (CentrifyDC 5.1.0-494)
auth sufficient pam_centrifydc.so
auth requisite pam_centrifydc.so deny
account sufficient pam_centrifydc.so
account requisite pam_centrifydc.so deny
session required pam_centrifydc.so homedir
password sufficient pam_centrifydc.so try_first_pass
password requisite pam_centrifydc.so deny
What does this mean?
PAM is a framework to allow program to leverage authentication services. Therefore, any PAM-enabled program will perform the account, password, session and authorization checks using Centrify's shared libraries in addition to the existing system methods. For example, if a UNIX-enabled AD user issues the passwd command, since this command is PAM-enabled, the password module will be invoked to enforce things like length, complexity, expiration, etc. in AD (defined in Group Policy).
At this point you define policy once (in AD) and it will be enforced in the Centrified UNIX/Linux system in addition to Windows. More process and policy reuse!
The opposite of joining a domain is leaving the domain, and since Centrify's tools are very consistent the command is adleave.
How do I know if a system is joined to AD?
Use the
adinfo command.
If the system has the Centrify binaries but is not joined to a domain, the output is
No joined to any domain
Licensed Features: Enabled
If the system has the Centrify binaries and is joined to a domain, the output is
Local host name: suse1
Joined to domain: corp.contoso.com
Joined as: suse1.corp.contoso.com
Pre-win2K name: suse1
Current DC: dc1.corp.contoso.com
Preferred site: HQSite
Zone:
corp.contoso.com/UNIX/Zones/HQ
CentrifyDC mode: connected
Licensed Features: Enabled
Notice that the output of adinfo is very helpful to understand what is going on in your system and the agent. You can tell how the system was joined, to what domain, what domain controller the agent is talking to, and if there's communications to AD.
About Computer Accounts
In Active Directory, computer accounts (just like user accounts) have passwords too, and by default they change automatically every 30 days, this applies to AD-joined systems using Centrify.
Computer accounts can belong to AD Groups. In fact, Centrify Computer Roles (the collections of systems) are all contained within a previously created AD group. E.g. in our lab, we have a UNIX Database Servers group, to hold the computer accounts of Database Servers.
Process and knowledge reuse
All the processes outlined by Microsoft (add, remove, move, pre-create, disabling, renaming, etc.) can be performed with centrified systems.
http://support.microsoft.com/kb/320187
These operations affect provisioning processes, operations and even group policy processing. Most likely, any major organization has processes in place for Windows computer accounts and they can be leveraged for the UNIX/Linux (or Mac) systems.
Update 1 (March 2015)
This update is based on feedback, the original post has been left intact, typos and all.
Should I install Centrify-enhanced OpenSSH?
Short answer: No
Why would you need Centrify OpenSSH?
- If you have a version of SSH Server that is not compiled/configured for PAM support.
Older box UNIXes used not to be ready out of the box (e.g. old HPUX, AIX, Solaris)
- If you want granular PAM access controls to be set up automatically for you.
For example, if you wanted to set up an account to be able to only scp a file, but not login. Centrify-enhanced OpenSSH has all those settings done for you.
- If you want optimized Kerberos or GSSAPI support on SSH
This version of OpenSSH is compiled to use the Centrify AD shared objects and MIT Kerberos tools. This means that in scenarios with complex AD infrastructures (one-way trusts, etc) you don't have to worry about SSO working.
- Smartcard Environments
Somewhat related to the previous bullet. In some environments, interactive sign-on is with Smartcard, then the rest is via Kerberos.
Basically the answer is No, but choosing Yes, helps in many advanced scenarios.
Should the system be restarted after Centrify installation and AD join?
The answer really depends. Most of the time the answer is no, but the determining factor is have long-running daemons (e.g. like DB2 on UNIX, or X-Window, etc), then a restart is in order. This is because unlike dynamic daemons (like sshd) these programs only read the PAM configuration at start-up.
A note of warning
My advice is that you reboot the system PRIOR to installing any new program. This is because most of the pride of UNIX, Linux and post 2008 windows admins is uptime, but the longer the system is up, the more possibility that changes may have been made while the system was running. Services may have been altered, environment variables modified but not committed, etc.
If the system restarts, and something is not right, the logical conclusion will be to blame it to the last program that was installed. This leads to flawed troubleshooting and possibly introducing additional issues. So, prior to a major change, have the system(s) rebooted and working again for a week, then the next window the programs or upgrades can be performed and any failures can be attributed to the recent event with accuracy.
