Configure a clustered environment with a load balancer

This section describes how to configure a clustered environment with a load balancer. To provide authentication across all of the servers, you need to create a service account for the load balancer on the domain controller, create a new keytab based on that account, and then merge that keytab on each application server.

Note:   To create new service accounts, you need permission to the container in which you are creating or deleting the account. See Understanding object permissions for using adkeytab in the Using adkeytab description in the Administrator’s Guide for Linux and UNIX for the description of the permissions required.

In this demonstration:

  • the DirectControl agent and Centrify for Apache software are already installed on servers B and C (do not install either software package on the load balancer)
  • the load balancer hostname is LB
  • the Apache servers behind the load balancer are named B and C
  • the domain is ace.com.

The following figure summarizes the steps for a two-server configuration. For each additional machine, perform Step 8 once more on machine B, and Step 9 through Step 16 on each additional machine.

This procedure requires users who have the following permissions:

  • Create user account on Active Directory on the domain controller
  • Add a new service principal name to the user account on the domain controller
  • Change service account password from the UNIX computer.

To configure a clustered environment with a load balancer:

  1. Confirm that you have the DirectControl agent (adclient) and the Centrify for Apache package installed as required.

    Unless they are already joined to the domain controller, run adjoin on servers B and C (and all other application servers) to join them to the domain controller.

  2. Create a new Active Directory account called centrifyprod. Verify that the user principal name (UPN) is centrifyprod@ace.com.

    Note:   To have setspn available to run in Step 3 and Step 4, you need to install Windows Support Tools.

  3. From a Windows system with Windows Support Tools installed, run the setspn command to add a new service principal name (SPN) to the user account:

    setspn -a HTTP/LB.ace.com centrifyprod
  4. Confirm that the SPN was created correctly:

    setspn -l centrifyprod

    You should see the SPN HTTP/LB.ace.com listed.

    Note:   Perform Step 5 through Step 8 (below) on machine B only.

  5. Use the following adkeytab command with the --adopt option to create the keytab for the new centrifyprod account and have the authentication service take over the management of the keytab:

    adkeytab --adopt --principal HTTP/LB.ace.com \
    --encryption-type arcfour-hmac-md5 \
    --encryption-type des-cbc-md5 \
    --encryption-type des-cbc-crc \
    --keytab /etc/krb5/centrifyprod.keytab centrifyprod

    This example uses sample encryption types to illustrate the command. You must make a separate --encryption-type entry for each encryption type you use. Replace the options above with the encryption types in your configuration.

    Note:   See the additional information about running adkeytab in Notes on running adkeytab.

  6. Verify that the keytab was created correctly:

    /usr/share/centrifydc/kerberos/bin/klist \
      -kt /etc/krb5/centrifyprod.keytab

    You should see the SPN HTTP/LB.domain.com.

  7. Verify that the keytab works:

    /usr/share/centrifydc/kerberos/bin/kinit \
      -kt /etc/krb5/centrifyprod.keytab centrifyprod

    You should see no output if everything worked correctly.

  8. You must have the same Kerberos keytab on each computer. Copy the keytab /etc/krb5/centrifyprod.keytab to server C.

    Perform Step 9 through Step 16 on both servers B and C.

  9. Disable the DirectControl agent to prepare for merging keytabs:

    svcadm disable centrifydc
  10. Back up the existing keytab:

    cp /etc/krb5/krb5.keytab \
      /etc/krb5/krb5.keytab.todaysdate
  11. Merge the keytabs:

    /usr/bin/ktutil
    rkt /etc/krb5/krb5.keytab
    rkt /etc/krb5/centrifyprod.keytab
    wkt /etc/krb5/krb5.keytab.new
    q
  12. Verify that the new keytab was created correctly:

    /usr/share/centrifydc/kerberos/bin/klist \
      -kt /etc/krb5/krb5.keytab.new
  13. Copy the new keytab to the default location with the appropriate name:

    cp /etc/krb5/krb5.keytab.new /etc/krb5/krb5.keytab
  14. Verify that the new keytab works:

    /usr/share/centrifydc/kerberos/bin/kinit -kt centrifyprod

    You should see no output if everything worked correctly.

  15. Enable the authentication service:

    svcadm enable centrifydc
  16. Run adinfo and check that adclient goes into a connected state. If adclient reports that it is disconnected, something has gone wrong in the setup.

Note:   If the password for the centrifyprod Active Directory account is changed, run Step 5 through Step 16 after every change.This password is changed transparently in a protocol initiated by Active Directory; that is, Active Directory prompts for a new account password on an interval defined in the DirectControl agent adclient.krb5.password.change.interval configuration parameter (see the Configuration and Tuning Reference Guide for the description). The DirectControl agent then automatically generates a new password for the computer account and issues the new password to Active Directory. The default interval is 28 days.

Notes on running adkeytab

To run this adkeytab command the user must have write permission to change the password for the service account and read/write permission to the userAccountControl attribute on the Active Directory domain controller. (See Understanding object permissions for using adkeytab in the Using adkeytab description in the Administrator’s Guide for Linux and UNIX for the description of the permissions required.) Often, this is NOT the case for the UNIX administrator running adkeytab.

Use the following adkeytab option to work around this problem. This does require, however, the UNIX admin to know and then expose the password in the command line. (The alternative would be to give the Active Directory admin root privileges on the Linux or UNIX computer or the UNIX admin password reset privileges on the domain controller.)

  • The Active Directory administrator creates the new AD account and adds the SPN to the account as above but then provides the password to the UNIX admin.
  • The UNIX admin uses the following adkeytab command instead of the command in Step 5. In this example the new user created by the AD admin is again centrifyprod@ace.com and the password is ABC123xyz:

    adkeytab --adopt --user centrifyprod@ace.com \
    --local --newpassword ABC123xyz \
    --encryption-type arcfour-hmac-md5 \
    --encryption-type des-cbc-md5 \
    --encryption-type des-cbc-crc \
    --keytab /etc/krb5/centrifyprod.keytab centrifyprod@ace.com

Note:   The --user option specifies the new account created by the AD admin; --local updates the keytab file on the computer (in this case, B) without changing the password in AD and --newpassword specifies the new password (required by the --local option). (This example uses the same sample encryption types as above.) See the adkeytab description in the Administrator’s Guide for Linux and UNIX for the full explanation of each option.