Info: Obtaining / Managing Keytabs from Windows 2003 KDC

[Dan Perry]

Hi All,

I though you may be interested in a patch I've worked on for Samba which adds
the ability for Samba's utilities to create / update the system keytab from a
windows 2003 server.   My post to the samba mailing list is available here:

http://lists.samba.org/archive/samba-technical/2004-April/035331.html

The patch is designed to replace Window's ktpass.exe and to provide means to
obtain a keytab and to add principals to that keytab easily.  Below is a long
winded explanation of how this patch / samba should be setup and used. Please
send me any comments you may have on this.

Thanks,
Dan Perry



---------- Further Details & Examples -----------------

Current versions of samba have a large set of LDAP and Kerberos functions to
interact with Active Directory.   Samba is capable of using Kerberos for
authentication, and has a utility to obtain service principals automatically.
However, those service principals are not stored in a 'normal' keytab, so
other applications, i.e. openssh cannot use the same HOST principals that
samba does.   Some patches were bounced around the samba mailing list to
enable storage of the Kerberos principals in the system keytab.   

I took one of those patches and added some functionality to it to make it
more complete.  An example of that functionality is as follows:

[root at host]$ klist -k
Error: No Keytab Found at /etc/krb5.keytab
[root at host]$ net ads join
Joined 'host' to realm 'REALM'
[root at host]$ klist -k
Keytab Name: FILE:/etc/krb5.keytab
KVNO Principal
---- -----------------------------------------
   2 host/host at REALM
   2 host/host at REALM
   2 host/host at REALM
   2 host/host at REALM
   2 host/host at REALM
   2 host/host at REALM
   2 cifs/host at REALM
   2 cifs/host at REALM
   2 cifs/host at REALM
   2 cifs/host at REALM
   2 cifs/host at REALM
   2 cifs/host at REALM

In the above session, we started with a machine with no keytab present.  Then
we used samba's net utility to join the host to the realm (active directory
domain).   This creates both a computer account in active directory, and also
creates a keytab on the host machine.    The newly created keytab has several
entries for each principal... one for each encoding type supported by the
client.   Having principals for multiple encoding types can sometimes help
make things work with other clients / services that don't necessarily support
a given encoding type.

Another feature I added is only that allows keytabs for any given service to
be created.  For example:

[root at host]$ net ads keytab add afs
[root at host]$ klist -k
Keytab Name: FILE:/etc/krb5.keytab
KVNO Principal
---- -----------------------------------------
   2 host/host at REALM
   2 host/host at REALM
   2 host/host at REALM
   2 host/host at REALM
   2 host/host at REALM
   2 host/host at REALM
   2 cifs/host at REALM
   2 cifs/host at REALM
   2 cifs/host at REALM
   2 cifs/host at REALM
   2 cifs/host at REALM
   2 cifs/host at REALM
   2 afs/host at REALM
   2 afs/host at REALM
   2 afs/host at REALM
   2 afs/host at REALM
   2 afs/host at REALM
   2 afs/host at REALM

The 'add' sub command allows any given principal to be created using the
machine secret that samba obtains.

A final feature is enabling delegation for the host principal on a Windows
2003 domain.   When using openssh with GGSAPI delegation enabled, I noticed
that the logins via GSSAPI would work, but the credentials would not be
delegated to the remote machine.  It turns out that in order to make this
work, delegation needs to be enabled for the computer account requesting
delegation.  I've added the following option to allow a computer account to
delegate to the host principal.  In windows 2000, the only way to do
delegation (at least as far as I know) was to allow delegation for
everything, which is not the best idea, security-wise.   In 2003, it is
possible to enable delegation for only a select set of hosts and principals.
My patch enables just that under a 2003 domain.   Here's an example:

[user at host]$ ssh remote
[user at remote]$ klist
No credentials cache found

.....

[root at host] net ads delegation enable

.....

[user at host]$ ssh remote
[user at remote] klist
(credentials are present now on the remote system)