Kerberos Principals for Unix-based Services in Active Directory (OBSOLETE)

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