Patch: Keytabs / Improving Samba's Interaction With Other Kerberized Services

[Dan Perry]

The advantage of the patch mentioned below is not in the patch itself, but in
whatever you use to manage your keytab.   I wrote the patch specifically to
go with the msktutil utility I wrote.   That utility does things like
preserve the old key on a machine password change that Samba doesn't seem to
do.  (Someone please correct me if I'm wrong on this...)

However, the feedback I've gotten so far doesn't seem to like this variant of
the keytab patch.   Instead I'll look into cleaning up the previous keytab
patch (the one that had net ads keytab...) and adding newer features like the
key preservation on a password change into the patch.

-Dan



-----Original Message-----
From: Rakesh Patel [mailto:rapatel at optonline.net] 
Sent: Saturday, May 22, 2004 12:27 PM
To: Andrew Bartlett; Dan Perry
Cc: samba-technical at lists.samba.org
Subject: Re: Patch: Keytabs / Improving Samba's Interaction With
OtherKerberized Services


Andrew Bartlett wrote:

>On Sat, 2004-05-22 at 01:10, Dan Perry wrote:
>  
>
>>Hi All,
>>
>>Here is a patch for Samba 3.0.4 that adds an option to disable Samba's own
>>keytab creation / management functions.   This patch prevents certain ads
>>functions from running, i.e. net ads join, net ads changetrustpw, etc.   It
>>also changes the kerberos_verify routines to verify an incoming Kerberos
>>transaction using the system's keytab, rather then generating an in-memory
>>keytab from the machine's trust password.
>>    
>>
>
>The problem with this patch is that it completely disables our schannel
>client support, as well as our ability to use kerberos to connect to a
>domain controller.
>
>  
>
I have to agree with this - Samba has a number of integral 
authentication requirements that we must not break
and must not prevent future changes/progress on that front.

>Both of these rely on being able to get at the very least the type 23
>key out of the keytab.  
>
>  
>
Due to the ability of Microsoft code to dynamically handle multiple 
principal names utilizing the same "key",
I would prefer Samba continue to NOT utilize the keytab directly.  This 
also keeps Samba independent of keytab
requirements other than to generate and update the keytab entry if the 
host (machine) key is changed. Obviously
a basic issue is to assist in migrating from the DES key exported via 
the Microsoft tool to generate/export a machine key for UNIX systems 
(ktadd?). 

>Even with that aside, we do this, because we had a very painful
>experience trying to make MIT kerberos correctly behave with the many
>different ways an incoming MS client ticket can behave.   In particular,
>I understand the host principal name seems to vary widely, particularly
>in case.  Doing this 'properly' (which I long advocated) soon turned out
>to be just too hard, in real life networks.
>
>  
>
As long as the Samba facilities include the ability to set/maintain the 
"host/{machine-lower-cased-fqdn}@REALM"
entry in the machines keytab using the key in secrets.tdb or other 
repository Samba elects to support, I believe the majority
of requirements would be addressed.

>There is another set of patches floating around, that need to be
>applied, that instead make Samba write out to the system keytab.  
>
>  
>
Dan did base his patches upon the work we did before, however we need to 
agree on functionality requirements
and get the basics integrated.  Can we at least come to a concensus on 
the basic requirements and get that
functionality integrated?

Thanks,
Rakesh Patel.

>(I thought jra was doing it, but more urgent things keep bumping things
>off his priority queue).  
>
>Andrew Bartlett
>
>  
>