of keytabs, kerberos and winbindd
idra at samba.org
Mon Jun 18 14:10:25 MDT 2012
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).
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>
More information about the samba-technical