of keytabs, kerberos and winbindd

[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 <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>