of keytabs, kerberos and winbindd

[Matthieu Patou]

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