Centrify Server Suite is a popular and effective method to integrate *NIX machines with Microsoft Active Directory. Over the years, I've worked with a wide range of enterprise customers to implement the Centrify solution in their enterprise environments.
During the planning and design phase of these integration projects, many questions are posed, to figure out how to best implement the solution in the client's environment.
After having explained which procedures are available with the Centrify solution, to join a *NIX system to the Active Directory domain, most customers ask the same question: what is the best procedure for joining a *NIX system to Active Directory?
The short answer to this question is: the procedure that has the best match with the client's needs. However, this is not straight-forward, as each procedure has different advantages and disadvantages, in terms of automation, convenience and security.
The long answer to this question is: read the entirety of this post, to get a better understanding on the available method, how each of them lend themselves for automation, and what the implications are in terms of security.
Required Active Directory delegations
Before showing the various join procedures, it should be noted that one thing is conspicuously absent from this guide: Active Directory delegation rights. These can be found in the chapter named Active Directory permissions required for administrative tasks of the Centrify Planning and Deployment Guide, included with the installation media of the Centrify Server Suite Windows consoles.
Alternatively, the deploy.ps1 PowerShell script, included with the DirectManage Access Manager console, can be used to deploy a Centrify structure in Active Directory for use with the Centrify solution, and automatically delegates the required rights for pre-staging and joining systems in a newly created Computers OU inside the Centrify OU structure, to a group called ComputerManagers in the Centrify Administration OU.
The different join procedures
Manual adjoin with on the spot object creation
The simplest form of joining a *NIX system to Active Directory, is to do all operations in one go:
Create the computer object in Active Directory, create its profile in the Zone, initialize the computer object to the right values and reset the computer password to initialize the system keytab with a random password, all by using the Centrify command adjoin on the *NIX machine.
This join is performed by a group of users that have specific Active Directory permissions, most importantly the ability to create the computer object in a specific OU.
In the example, the join operation to the Centrify Zone LinuxServers, as well as the ability to create the computer object in the OrganizationalUnit OU=UNIX Servers,OU=Centrify in the Active Directory domain company.com, has been delegated to an Active Directory group called ComputerManagers. On that same OU, the SELF principal has been explicitly delegated the ability to write certain attributes on computer objects.
User John is a member of the ComputerManagers group, and has been granted in the local sudoers file on the *NIX machine, the ability to run the adjoin command with the required parameters.
The create computer object and join operation on UNIX for a system with hostname rhel-01, will then look as follows:
# sudo adjoin company.com --zone LinuxServers --container "company.com/Centrify/UNIX Servers" --name rhel-01 --user john
Note that this will automatically register the DNS zone of the Active Directory domain in the fully qualified name of the computer object's dNSHostName attribute. If --name is omitted, as it is in the other adjoin examples, the hostname of the machine is automatically used as first component of the hostname when setting the value of dNSHostName of the computer object in Active Directory.
To register a different DNS zone for the computer object, specify the desired fully qualified hostname as argument of the --name parameter.
Please study the man page of the adjoin command to use other advanced features, such as registering additional Kerberos service principals or support for use in a DMZ with a RODC.
Automated adjoin with on the spot object creation
Certain constraints, such as joining large numbers of *NIX machines to Active Directory, or when aiming to minimise human error, result in a desire to automate the pre-staging and join process.
Let's suppose that instead of the Active Directory user account John, a service account has been created called svc-centrifyjoin, that is member of the same ComputerManagers group, and has the same permissions required for creation of computer objects and joining them to the Centrify zone. This service account has as its password: 'ServiceAccountPassword'.
Using the service account to create computer object and join operation on UNIX will then look as follows:
# sudo adjoin company.com --zone LinuxServers --container "company.com/Centrify/UNIX Servers" --user svc-centrifyjoin --password ServiceAccountPassword
Obviously, hardcoding the service account's password in a join script may neither be the safest option available, nor the easiest to manage when trying to meet the periodic password change requirement in Active Directory.
Anyone who gets their hands on the account password would be able to create new computer objects in the designated OU, and set the computer passwords to a value that is known to them. To limit people from learning the password, you could secure erase the script running adjoin at the end of the join procedure, and regularly cycle the service account password, and update the join script in a master template/image used for deploying new *NIX systems.
Kerberized adjoin with on the spot object creation
Alternatively, a Kerberos keytab could be used for the service account, instead of a password. This requires that the command or network protocol accepts Kerberos tickets for authentication, i.e. a so-called kerberized command or service.
Fortunately, most of the Centrify supplied commands requiring authentication are kerberized, and so are most of Microsoft Active Directory related services. Note that there are some exceptions to this, such as the sudo-replacement tool 'dzdo'.
Using the Kerberos approach, some groundwork needs to be performed to allow the service account to use a keytab to retrieve a TGT.
On a system that already is joined to Active Directory, a keytab can be generated as follows in /etc/svc-centrifyjoin.keytab for the service account svc-centrifyjoin by user svc-manager that has the Active Directory reset password permission on the service account svc-centrifyjoin.
# sudo adkeytab --adopt --user svc-manager --keytab /etc/svc-centrifyjoin.keytab --samname svc-centrifyjoin "Centrify Join Account"
Note that if the Common Name of the service account differs from the sAMAccountName, both need to be specified; the sAMAccountName svc-centrifyjoin as argument of the --samname parameter, and the Common Name (cn) "Centrify Join Account" as argument between double quotes if it contains a space.
Note further that the Active Directory account specified with --user needs to have reset password permission on the target service account object, in order to initialize the keytab. In this example we used the service account svc-manager, but you could also delegate this task to the service account itself, using the initial password as one-time password for this procedure.
Keep in mind that whoever has the password reset permission, will be able to reset the service account password to the any value regardless of the password history, and minimum password age.
Note that the resultant keytab file should be treated as a password-equivalent for the service account, as it can be used to retrieve a Kerberos ticket-granting-ticket (TGT), giving the ability to authenticate as the service account to any kerberized services. It would be prudent to make sure that the service account does not have any authorizations to kerberized services other than to those that are required (i.e. AD LDAP). Further more, if NTLM authentication has not explicitly been disabled in the Active Directory domain, the RC4-MD5 password hash in the keytab can also be used for NTLM authentication.
To cycle the Active Directory password (and resultant keytab secrets), the following command can then be used on a system joined to the domain:
# sudo adkeytab --change-password --user svc-manager --keytab /etc/svc-centrifyjoin.keytab --samname svc-centrifyjoin "Centrify Join Account"
If the reset password permission has been delegated to the service account itself, the following kerberized procedure could be used instead:
# sudo kinit -kt /etc/svc-centrifyjoin svc-centrifyjoin
# sudo adkeytab --change-password --keytab /etc/svc-centrifyjoin.keytab --samname svc-centrifyjoin "Centrify Join Account"
# sudo kdestroy
The service account's password should be cycled before it expires; to meet this requirement, these commands can be run from a script run as a weekly or monthly cron job, for example on the system that maintains the master image for deploying new *NIX systems. The generated keytab for the service account can then be automatically integrated into the image of the system that needs to be joined to the domain.
The kerberized join operation, including secure erasure of the keytab post join, will then look as follows:
# sudo /usr/share/centrifydc/kerberos/bin/kinit -kt /etc/svc-centrifyjoin svc-centrifyjoin@COMPANY.COM
# sudo adjoin company.com --zone LinuxServers --container "company.com/Centrify/UNIX Servers"
# sudo kdestroy
# sudo shred --iterations=1 --remove /etc/svc-centrifyjoin.keytab
Note that the initial kinit command does not use the /etc/krb5.conf that the adjoin command generates when joining the domain. Instead, it will retrieve a KDC from the DNS zone specified as Kerberos REALM COMPANY.COM as part of the service account name (indicated with the at sign when specifying the Kerberos principal name). Alternatively, a domain controller in the same site as the target system could be manually specified as KDC in a basic /etc/krb5.conf file, that gets replaced during the adjoin operation.
Note further that the shred command overwrites the keytab file prior to deletion, making it harder to recover the contents. Take precautions to prevent access to previous snapshots of the file system that still include the service keytab, and note further, that overwriting a file on solid state media does not necessarily change the actual bits containing the original data.
In part 2 of the series, the security implications are examined of a compromise of the account used to join systems to Active Directory, and what options are available to reduce this risk.