Sassafras TN 4266: Preparing a Unix-based KeyServer for Kerberos authentication within an Active Directory domain

Using Kerberos authentication with any network service requires a certain amount of configuration. When KeyServer is running on a MacOS or Linux host and the Kerberos services are provided by Active Directory there are a few extra steps that must be taken.

If you are running KeyServer on a Windows host, or if your Kerberos servers are Unix based, the configuration steps will be slightly different from what is described below.

Setup Service Account

Let's assume KeyServer runs on the host named "keyserver.ad.sample.org" and you have a domain controller on "pdc.ad.sample.org". Note that the various names chosen for this example are mostly arbitrary, but follow typical conventions for Kerberos. You can use whatever names make sense as long as you use them consistently. Commands that you type are in bold below. Windows commands must be run on pdc.ad.sample.org, unix commands must be run on keyserver.ad.sample.org.

— Create an account in AD, e.g. "keyserver", and give it a strong password, e.g. "x3oM8pvEud"
— Open a command prompt window as a user with sufficient privileges to manage AD accounts
— Run the ktpass command like this (all on one line):

[dos-prompt] ktpass -princ KEYSERVER/keyserver.ad.sample.org@AD.SAMPLE.ORG -mapuser keyserver -mapop set -pass x3oM8pvEud -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL +desonly -out keyserver.ad.sample.org.keytab Targeting domain controller: pdc.ad.sample.org Using legacy password setting method Successfully mapped KEYSERVER/keyserver.ad.sample.org to keyserver. Key created. Output keytab to keyserver.ad.sample.org.keytab: Keytab version: 0x502 keysize 60 KEYSERVER/keyserver.ad.sample.org@AD.SAMPLE.ORG ptype 1 (KRB5_NT_PRINCIPAL) ...etc. Account keyserver has been set for DES-only encryption.

If the ktpass command fails with the message "Aborted", this most likely means the password you provided is incorrect or of insufficient strength. Change the password for the account if necessary and be sure to provide this password with the -pass option as shown in the example above.

— On the KeyServer host use the ldapsearch command to check that the Service Principal Name was properly set by ktpass (all on one line):

[unix-prompt] ldapsearch -h pdc.ad.sample.org -x -W -s base -D "cn=keyserver,cn=users,dc=ad,dc=sample,dc=org" -b "cn=keyserver,cn=users,dc=ad,dc=sample,dc=org" '(objectclass=*)' servicePrincipalName msDS-KeyVersionNumber Enter LDAP Password: x3oM8pvEud ... # keyserver, users, ad.sample.org dn: cn=keyserver,cn=users,dc=ad,dc=sample,dc=org servicePrincipalName: KEYSERVER/keyserver.ad.sample.org msDS-KeyVersionNumber: 9 ...

If there is no servicePrincipalName attribute, ktpass was not run with sufficient privileges or was otherwise unable to modify the user object. If servicePrincipalName has a different value than KEYSERVER/keyserver.ad.sample.org you must delete the incorrect value and run ktpass again. You can edit the object attributes with ADSI Edit (adsiedit.msc) or with ldapmodify on a Unix host.

Take note of the value for the msDS-KeyVersionNumber attribute. In the example above it is 9, but will be different each time you run ktpass. The value of this attribute must match the KVNO field that is displayed in several of the commands you will run on the KeyServer host.

Setup Server Host

— Move the keyserver.ad.sample.org.keytab file to the KeyServer host (it must be on the local disk, not on a remote volume). You can see the entries in the file by using this command:

[unix-prompt] klist -k keyserver.ad.sample.org.keytab KVNO Principal ---- --------------------------------------------------------------------- 9 KEYSERVER/keyserver.ad.sample.org@AD.SAMPLE.ORG

— Test that the keytab is valid using the kinit and klist commands. First you must clear out any existing tickets using kdestroy:

[unix-prompt] kdestroy [unix-prompt] kinit -k -t keyserver.ad.sample.org.keytab KEYSERVER/keyserver.ad.sample.org [unix-prompt] klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: KEYSERVER/keyserver.ad.sample.org@AD.SAMPLE.ORG Valid Starting Expires Service Principal 06/29/10 07:24:56 06/29/10 17:24:54 krbtgt/AD.SAMPLE.ORG@AD.SAMPLE.ORG renew until 07/06/10 07:24:56

If kinit fails with a message like "Password incorrect..." or "Preauthentication failed...", the keytab does not contain the correct password or has other incorrect information. You must start again from the beginning, making sure all the host names, user names, and domains accurately reflect your environment.

— On the KeyServer host run this command (the sudo is needed since you will be changing the protected file /etc/krb5.keytab):

— You will then be at the ktutil prompt, where you need to enter a few commands:

ktutil: rkt keyserver.ad.sample.org.keytab ktutil: wkt /etc/krb5.keytab ktutil: list slot KVNO Principal ---- ---- ---------------------------------------------------------------- ... 16 9 KEYSERVER/keyserver.ad.sample.org@AD.SAMPLE.ORG ktutil: quit

— Test that the keytab is valid and installed correctly using the kinit and klist commands. As above, sudo is needed since you will be using the protected file /etc/krb5.keytab. If you are prompted for a password it will be for sudo, not for Kerberos. First you must clear out any existing tickets using kdestroy:

[unix-prompt] kdestroy [unix-prompt] sudo kinit -k -t /etc/krb5.keytab KEYSERVER/keyserver.ad.sample.org [unix-prompt] klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: KEYSERVER/keyserver.ad.sample.org@AD.SAMPLE.ORG Valid Starting Expires Service Principal 06/29/10 07:32:30 06/29/10 17:32:28 krbtgt/AD.SAMPLE.ORG@AD.SAMPLE.ORG renew until 07/06/10 07:32:30

Setup KeyServer Authentication

— Run KeyConfigure and open the Authentication dialog. With Kerberos selected as the active auth method, enter the values as shown below:

Now your KeyServer is set up to use Kerberos within your AD domain.

Setup Client Computers

The next step is to make sure your clients are configured correctly to use Kerberos. On Windows computers that are already part of the AD domain you should be all set, no additional steps needed. On Mac clients you should configure the Kerberos realm mappings in the /Library/Preferences/edu.mit.Kerberos file. This might already be done if you've got your Macs using Kerberos for other services. On non-Mac Unix computers this same information is kept in /etc/krb5.conf. For example, your edu.mit.Kerberos (or /etc/krb5.conf on non-Mac Unix) file might look like this:

[libdefaults] default_realm = AD.SAMPLE.ORG [realms] AD.SAMPLE.ORG = { kdc = pdc.ad.sample.org.:88 admin_server = pdc.ad.sample.org. default_domain = ad.sample.org } [domain_realm] .ad.sample.org = AD.SAMPLE.ORG ad.sample.org = AD.SAMPLE.ORG [v4 realms] AD.SAMPLE.ORG = { kdc = pdc.ad.sample.org. admin_server = pdc.ad.sample.org. default_domain = ad.sample.org } [v4 domain_realm] .ad.sample.org = AD.SAMPLE.ORG ad.sample.org = AD.SAMPLE.ORG

Some older Mac OS X systems might have configuration in /etc/krb5.conf. If this file exists, you should either remove it or move it to /Library/Preferences/edu.mit.Kerberos if the latter does not exist already. There can also be configuration in users' personal ~/Library/Preferences/edu.mit.Kerberos file. Unless there is a specific need for per-user configuration, these user files should be removed.

You can test this configuration using these commands:

[unix-prompt] kinit Please enter the password for user@AD.SAMPLE.ORG: [unix-prompt] klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: user@AD.SAMPLE.ORG Valid Starting Expires Service Principal 06/29/10 07:48:05 06/29/10 17:48:39 krbtgt/AD.SAMPLE.ORG@AD.SAMPLE.ORG renew until 07/06/10 07:48:05

Once things are set up on the client side you should be able to logon to KeyServer without being prompted for name and password. Use klist again to check that the proper Kerberos tickets were obtained:

[unix-prompt] klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default principal: user@AD.SAMPLE.ORG Valid Starting Expires Service Principal 06/29/10 07:48:05 06/29/10 17:48:39 krbtgt/AD.SAMPLE.ORG@AD.SAMPLE.ORG renew until 07/06/10 07:48:05 06/29/10 08:28:40 06/29/10 17:48:39 KEYSERVER/keyserver.ad.sample.org@AD.SAMPLE.ORG renew until 07/06/10 07:48:05

In a typical Active Directory environment the default settings for KeyServer's Kerberos authentication method should suffice to allow authenticated client connections. If you have followed the steps above and cannot get a client connection, or if KeyAccess prompts for a password, contact Sassafras Software Support for assistance.