Kerberos Principals for Unix-based Services in Active Directory

A service principal is needed whenever you want to provide Single Sign-on for users that have already authenticated against an Active Directory domain. They are also handy for verifying the TGT issued by a domain controller on user login. The process of creating a principal can be summarized in a few basic steps:

• Create a user in AD representing the service
• Map the Windows user name to a service principal name
• Set the password on the account
• Generate a keytab file and install (or merge) it on the Unix host providing the service

CSCF Conventions

In AD, the Windows user name for the principal account is of the form hostname-servicename. So, the user name representing the host service principal for cpu02 would be cpu02-host.

Another thing to keep in mind is that Unix-based service principals are located in a specific place in the directory tree of the domain. (actually this does not matter, as the principal will be searched for in the AD tree albeit from an administrative point of view you should put them in a human findable location).

Creating Principals from the Unix side using mkADprincipals.pl

With a standalone Ubuntu Linux box and domain credentials with sufficient privileges, you can do all you need to without access to a Windows host. All you need to do, is run the mkADprincipals.pl script.

Pre-Requisites for mkADprincipals.pl

• Set-up LDAPS on your Linux client
  • Install ldap-utils
  • Download http://ist.uwaterloo.ca/security/IST-CA/cacert.pem
  • Set TLS_CACERT /full/path/to/cacert.pem in your .ldaprc or system ldap.conf
• Install PERL modules: libio-socket-ssl-perl liblocale-gettext-perl    libnet-ldap-perl libterm-readkey-perl libunicode-map8-perl    libunicode-string-perl libstring-random-perl

Example usage

Suppose you wish to create an nfs service principal for the hosts krbtux and krbsol in the STUDENT.CS.UWATERLOO.CA domain. First, create a file named myhosts that contains the FQDN of each host, one per line. Then run the script:

mkADprincipals.pl -h canadenis.student.cs.uwaterloo.ca -D Administrator@STUDENT.CS.UWATERLOO.CA 
-b 'OU=Unix machine accounts,OU=Special Accounts,OU=CS,DC=student,DC=cs,DC=uwaterloo,DC=ca' 
-f myhosts -R STUDENT.CS.UWATERLOO.CA -s nfs

After running the perl script, for each host, you need to do the following:

• Run ktutil.
• At the ktutil: prompt, type addent -password -p PRINCIPAL_NAME -k KVNO -e des-cbc-crc, where PRINCIPAL_NAME and KVNO are given by the perl script.
  • The principal generated may have the shortened form (for host principal) host/hostname without mention of the realm. You must change it to host/hostname@STUDENT.CS.UWATERLOO.CA.
• When prompted, enter the password output by the perl script.
• Type wkt hostname.keytab.
• Exit ktutil by typing q.
• Securely copy the keytab file(s) that you generated to the krb5.keytab file on each host. Note that the host(s) might already have a keytab file, so you may have to merge them using ktutil.

Possible Improvements to mkADprincipals.pl

• Better error handling.
• Just plain better coding.
• Have it generate keytab files itself.

Creating Principals on the Windows Side

This method is clearly not as convenient as the above Unix side approach but it might be more reliable as both the account and keytab are being created by Windows tools and are therefore likely to be consistent but this is merely a speculative comment and cannot be justified formally

Create a User based account for the host such that the User login name is host\FQDN@DOMAIN_NAME where FQDN is to be substituted with the _fully qualified domain name_ of the host and DOMAIN_NAME is the Windows domain the principal is being added to. As a result of this you will see the field =User login user (pre-windows 2000)= field filled out automatically. Instead edit it to read hostname-host, where hostname has no dots (I suspect this isn't really too important but you will need to remember it when using the ktpass command to generate a keytab file). Set a password and set to not expire and set 'Do not require kerberos pre-auth'.

Create keytab file to transferred to Linux system.

ktpass -ptype KRB5_NT_PRINCIPAL -crypto DES-CBC-MD5 -princ host/fqdn@KERBERO_REALM
          -mapuser Domain_Name\hostname-host -pass ComplexPasswd -out c:\temp\krb5.keytab

where DOMAIN_NAME is either cscf.uwaterloo.ca, cs.uwaterloo.ca, student.cs.uwaterloo.ca, =sysadmins.cscf.uwaterloo.ca which correspond, to the NetBios names CSCF, CS-GENERAL, CS-TEACHING, CSCF-SYSADMINS, respectively (Aside: The notion of a NetBios name seems to correspond to something called pre-windows 2000 Domain name). The KERBEROS name is simply the uppercase of the domain name (see http://support.microsoft.com/kb/248807 for confirmation).

As an example suppose we have a host called mathdude.cscf and that we want to add it to the CSCF domain. We would then have User login name of host/mathdude.cscf.uwaterloo.ca@cscf.uwaterloo.ca and the older pre-windows 2000 name of CSCF\mathdude-host. The corresponding ktpass command to generate a keytab for this host is

ktpass -ptype KRB5_NT_PRINCIPAL -crypto DES-CBC-MD5 -princ host/mathdude.cscf.uwaterloo.ca@CSCF.UWATERLOO.CA
         -mapuser CSCF\hostname-host -pass ComplexPasswd -out c:\temp\krb5.keytab.mathdude

where ComplexPasswd is the same one you used to create the principal for the hostname. Next transfer (via ssh, for example) the file c:\temp\krb5.keytab.mathdude to mathdude.cscf and copy it to /etc/krb5.keytab which will have the following permissions and ownership

-rw------- 1 root root 82 2007-11-19 13:47 /etc/krb5.keytab

Package installed on Ubuntu client

apt-get install libnss-ldap
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  auth-client-config ldap-auth-client ldap-auth-config libpam-ldap
Recommended packages:
  nscd
The following NEW packages will be installed:
  auth-client-config ldap-auth-client ldap-auth-config libnss-ldap libpam-ldap
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 165kB of archives.
After unpacking 754kB of additional disk space will be used.
Do you want to continue [Y/n]? 
Get:1 http://ca.archive.ubuntu.com gutsy/main auth-client-config 0.4-0ubuntu1 [13.8kB]
Get:2 http://ca.archive.ubuntu.com gutsy/main libpam-ldap 184-1ubuntu2 [57.0kB]
Get:3 http://ca.archive.ubuntu.com gutsy/main libnss-ldap 255-1ubuntu2 [81.2kB]
Get:4 http://ca.archive.ubuntu.com gutsy/main ldap-auth-client 0.4 [2450B]
Get:5 http://ca.archive.ubuntu.com gutsy/main ldap-auth-config 0.4 [10.7kB]
Fetched 165kB in 0s (680kB/s)       
Preconfiguring packages ...
Selecting previously deselected package auth-client-config.
(Reading database ... 16043 files and directories currently installed.)
Unpacking auth-client-config (from .../auth-client-config_0.4-0ubuntu1_all.deb) ...
Selecting previously deselected package libpam-ldap.
Unpacking libpam-ldap (from .../libpam-ldap_184-1ubuntu2_i386.deb) ...
Selecting previously deselected package libnss-ldap.
Unpacking libnss-ldap (from .../libnss-ldap_255-1ubuntu2_i386.deb) ...
Selecting previously deselected package ldap-auth-client.
Unpacking ldap-auth-client (from .../ldap-auth-client_0.4_all.deb) ...
Setting up auth-client-config (0.4-0ubuntu1) ...
Selecting previously deselected package ldap-auth-config.
(Reading database ... 16123 files and directories currently installed.)
Unpacking ldap-auth-config (from .../ldap-auth-config_0.4_all.deb) ...
Setting up ldap-auth-client (0.4) ...
Setting up ldap-auth-config (0.4) ...

Setting up libpam-ldap (184-1ubuntu2) ...
Setting up libnss-ldap (255-1ubuntu2) ...

The primary file /lib/libnss_ldap-2.6.1.so has the following library dependencies

# ldd /lib/libnss_ldap-2.6.1.so
        linux-gate.so.1 =>  (0xffffe000)
        libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0xb7f00000)
        liblber.so.2 => /usr/lib/liblber.so.2 (0xb7ef4000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xb7eca000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7ec6000)
        libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7eae000)
        libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0xb7e9b000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e83000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d39000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7d0a000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb7cf3000)
        libgnutls.so.13 => /usr/lib/libgnutls.so.13 (0xb7c83000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xb7bfb000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xb7bd6000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xb7bd2000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7bca000)
        libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb7bc8000)
        /lib/ld-linux.so.2 (0x80000000)
        libtasn1.so.3 => /usr/lib/libtasn1.so.3 (0xb7bb8000)
        libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0xb7bb4000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7b9e000)
        libgcrypt.so.11 => /usr/lib/libgcrypt.so.11 (0xb7b4d000)

from which we see that Kerberos, TLS, and SASL are builtin. The package ldap-auth-config has a bunch of debconf questions, i.e., when one runs dpkg-reconfigure -plow ldap-auth-config it allows one to configure /etc/ldap.conf (NOTE. This file is different from /etc/ldap/ldap.conf which a program like ldapsearch would use. It would seem one could link /etc/ldap/ldap.conf to /etc/ldap.conf).