of keytabs, kerberos and winbindd

[simo]

On Mon, 2012-06-18 at 11:53 -0700, Matthieu Patou wrote: 
> On 06/16/2012 07:31 AM, simo wrote:
> > 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.
> Looking at the code gives the impression that AD support has been 
> gradually bolt on rather than built-in.
> > 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.
> The dedicated keytab has been added by  Dan Sledz on commit 
> d96248a9b46559552f53b0ecd3861387ea7ff050 a bit more than 3 years ago I 
> think it was because of specials needs from Isilon, Steven can you 
> comment, explain the uses cases ?
> I'm not opposed to a change as well but I would rather change the way we 
> deal with the system keytab as it sounds pretty logical to have samba 
> managing it when the workstation is a member of AD domain, because as I 
> said before it makes then kerberised services work out of the box.

I agree the system keytab is what we should try to manage.

> How much of the previous kerberos keytab configuration are we ok to drop 
> or change the behavior ?

As much as it make sense form a system integration point of view.

If we are running winbindd, then winbindd should keep it up to date,
otherwise we shouldn't touch it (ie no touching it from smbd).

Simo.

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