of keytabs, kerberos and winbindd

[Matthieu PATOU-2]

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 ?

Also I already discussed about the possibility for winbindd to accept a
kerberos ticket for doing the authentication and group membership
"lookup", the idea is that a user has already a kerberos ticket with PAC
information it can used to authenticate and get the groups of the user
without having winbindd doing a netlogon request to the DC, this is
similar to what WINBINDD_PAM_AUTH do except that you specify a ticket
instead of user and a password.

Any comments ?

Matthieu.

[simo]

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.

I think we should strongly consider this option in future, it just makes
things a lot simpler on many angles and will allow us to avoid having
some code depend on the secrets code which is a plus as it streamlines
some dependencies (only for Krb5 for now I know, but it's a start).


> Also I already discussed about the possibility for winbindd to accept a
> kerberos ticket for doing the authentication and group membership
> "lookup", the idea is that a user has already a kerberos ticket with PAC
> information it can used to authenticate and get the groups of the user
> without having winbindd doing a netlogon request to the DC, this is
> similar to what WINBINDD_PAM_AUTH do except that you specify a ticket
> instead of user and a password.

Yes we could be more aggressive with caching, and have the PAC stuff
dumped in the winbind cache is winbind is in use.

> Any comments ?

HTH,
Simo.

--
Simo Sorce
Samba Team GPL Compliance Officer <[hidden email]>
Principal Software Engineer at Red Hat, Inc. <[hidden email]>

[Andrew Bartlett]

On Thu, 2012-06-14 at 18:11 -0400, simo wrote:

> > Also I already discussed about the possibility for winbindd to accept a
> > kerberos ticket for doing the authentication and group membership
> > "lookup", the idea is that a user has already a kerberos ticket with PAC
> > information it can used to authenticate and get the groups of the user
> > without having winbindd doing a netlogon request to the DC, this is
> > similar to what WINBINDD_PAM_AUTH do except that you specify a ticket
> > instead of user and a password.
>
> Yes we could be more aggressive with caching, and have the PAC stuff
> dumped in the winbind cache is winbind is in use.

I've had a fellow developer ask if we could implement a PAC -> xids
function (return the list of unix IDs given an unparsed PAC).  That
could certainly use this, or the approach dlz_bind9 uses (bind9 does a
normal GSSAPI authentication, the dlz module replays it and extracts the
PAC).

The primary issue is that for the direct 'offload the authentication to
winbind' case, you can't do a subsequent sign/seal, as you don't have
the session keys.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

[Ondrej Valousek]

On 06/15/2012 12:11 AM, simo wrote:
> I think we should strongly consider this option in future, it just makes
> things a lot simpler on many angles and will allow us to avoid having
> some code depend on the secrets code which is a plus as it streamlines
> some dependencies (only for Krb5 for now I know, but it's a start).
I strongly agree here as well - I did not know Samba has to maintain its own secrets.tdb. It would be nice if samba could really maintain
system Kerberos database (I see it as another big benefit) so that other services (sshd, http, nfs) can make use of it.
Hopefully this idea will not be forgotten (as well as the idea of gss-proxy).

Ondrej

[simo]

On Fri, 2012-06-15 at 09:50 +0200, Ondrej Valousek wrote:
> On 06/15/2012 12:11 AM, simo wrote:
> > I think we should strongly consider this option in future, it just makes
> > things a lot simpler on many angles and will allow us to avoid having
> > some code depend on the secrets code which is a plus as it streamlines
> > some dependencies (only for Krb5 for now I know, but it's a start).
> I strongly agree here as well - I did not know Samba has to maintain its own secrets.tdb. It would be nice if samba could really maintain
> system Kerberos database (I see it as another big benefit) so that other services (sshd, http, nfs) can make use of it.
> Hopefully this idea will not be forgotten (as well as the idea of gss-proxy).

I am still working on gss-proxy, I have kernel patches posted to use it
with nfsd and I am working on the mechglue layer in MIT libs to get the
interposer in. Stay tuned.

Simo.

--
Simo Sorce
Samba Team GPL Compliance Officer <[hidden email]>
Principal Software Engineer at Red Hat, Inc. <[hidden email]>

[Matthieu Patou-7]

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 ?
Matthieu

--
Matthieu Patou
Samba Team
http://samba.org

[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 <[hidden email]>
Principal Software Engineer at Red Hat, Inc. <[hidden email]>

[Matthieu Patou-7]

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.

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

Matthieu.

--
Matthieu Patou
Samba Team
http://samba.org

[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 <[hidden email]>
Principal Software Engineer at Red Hat, Inc. <[hidden email]>

[Steven Danneman]

> 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 ?

Hey Matthieu,

Being over 3 years ago my memory is a little fuzzy, but it was probably
an Isilon specific need.

At the time we were creating a machine account on every node in our
cluster each with a different password, and each of these nodes had a
separate name like foo-1, foo-2, foo-3, etc.  Yet, the entire cluster
could be accessed via a DNS round-robin resolver with a single name like
foo.company.com.

So I think we needed custom logic to accept service tickets encrypted
with the password for the foo principal, but lookup foo-1 in the keytab
or vice versa.

-Steven