Info: Obtaining / Managing Keytabs from Windows 2003 KDC

[Actually davidchr]

That seems pretty cool.  Does this do everything that ktpass does, or
strictly the keytab-generation functionality?  

I'd love to see more interop tools developed by the community-- it might
increase the number of people doing it, and possibly reduce the number
of questions that the various mailing lists and newsgroups have to
answer about the topic.

---
This message is provided "AS IS" with no warranties, and confers no
rights.
This message may originate from an unmonitored alias ("davespam") for
spam-reduction purposes.  Use "davidchr" for individual replies.
Any opinions or policies stated within are my own and do not necessarily
constitute those of my employer.
This message originates in the State of Washington (USA), where
unsolicited commercial email is legally actionable (see
http://www.wa-state-resident.com).
Harvesting of this address for purposes of bulk email (including "spam")
is prohibited unless by my expressed prior request.  I retaliate
viciously against spammers and spam sites.
 

> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] 
> On Behalf Of Dan Perry
> Sent: Friday, April 16, 2004 8:31 AM
> To: krbdev at mit.edu
> Subject: Info: Obtaining / Managing Keytabs from Windows 2003 KDC
> 
> 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)
> 
> 
> 
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>