of keytabs, kerberos and winbindd

[simo]

On Fri, 2012-06-15 at 10:42 -0700, Matthieu Patou wrote: 
> On 06/14/2012 03:11 PM, simo wrote:
> > On Thu, 2012-06-14 at 12:02 -0700, Matthieu Patou wrote:
> >> Hello all,
> >>
> >> Currently in samba stable release we have 4 possibility related to the
> >> kerberos method:
> >>
> >> 1) secrets
> >> 2) system keytab
> >> 3) secret + system keytab
> >> 4) dedicated keytab
> >>
> >> The man page indicate that "system keytab" and "dedicated keytab" is
> >> almost the same but the latter method relies on kerberos to find the
> >> correct keytab entry instead of filtering based on expected principals.
> >>
> >> It turns out that if you use method 2 and method 3, the system keytab
> >> will be created or updated when samba join the domain (net ads join),
> >> the keytab is also updated if you do a net ads changetrustpw. This make
> >> the use of system keytab or secret + system keytab very desirable if you
> >> want to use kerberized services (ie. ssh or http) but then you loose the
> >> capacity to have winbindd changing periodically the password of the
> >> machine account used by samba.
> >> I understand that this limitation is due to the fact that samba didn't
> >> control completely control the keytab update but then why update the
> >> keytab when we issue the changetrustpw. If we don't allow periodic
> >> password change when using kerberos method 2, 3 or 4 then I'm wondering
> >> if it wouldn't be interesting to have an option for kerberos method 1 to
> >> dump a keytab with samba's secret when joining, changing the password
> >> with changetrustpw and also when done periodically.
> >> Is there anybody with strong feeling against this ?
> > When I was working on the MIT krb5 support for samba 4 a few months ago
> > I was really close to propose a patch to *always* use a dedicated
> > keytab. (The RC4 key is the NTLM hash so we wouldn't need secrets.tdb at
> > all in theory).
> >
> > I haven't done so only because I was running out of time, and couldn't
> > spend the time chasing all corner cases, but I have code somewhere that
> > makes the secrets functions always dump a keytab when a password change
> > occurs, I can dig them up if you care.
> My understanding of dedicated keytab is that you don't have a strong 
> promise that someone else is not creating or not modifying this, and I 
> think that's the reason that lead to the decision to disallow automatic 
> password update when a dedicated keytab is used, here you seems to 
> propose that we always dump a dedicated keytab and that we use it for 
> kerberos ticket verification (or even for NTLM) and to dump it everytime 
> the password is changed.
> I'm not against this change but it's a kind of change with the previous 
> promise or did I miss something ?

My understanding was that 'dedicate keytab' meant it was private to
samba and so samba could do what it "needed", however the main point is
that these options were devised before AD support was real, they were
meant to kerberize samba also in environments were Windows clients were
not necessarily joined to an AD domain controller.

Fast forward a few years and things has changed quite a lot. I think it
is time to rationalize the way we use keytabs, and I find it reasonable
also to change/remove some options.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>