of keytabs, kerberos and winbindd

[Matthieu Patou]

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