of keytabs, kerberos and winbindd
idra at samba.org
Thu Jun 14 16:11:58 MDT 2012
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 ?
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