[PATCH] Implement a more abstracted kpasswd service

Simo simo at samba.org
Wed Sep 14 18:49:50 UTC 2016


On Tue, 2016-09-13 at 22:06 +1200, Andrew Bartlett wrote:
> On Mon, 2016-09-12 at 09:32 +0200, Andreas Schneider wrote:
> > 
> > On Saturday, 10 September 2016 13:21:59 CEST Andrew Bartlett wrote:
> > > 
> > > 
> > > I see Jeremy is doing a careful review, but I've also given this
> > > a
> > > quick look over, and it certainly seems reasonable.
> > > 
> > > I also wish to give an apology to you and your team for some
> > > historical
> > > bad advise:  I recall suggesting you could avoid gensec_krb5 if
> > > you
> > > avoided implementing the kpasswd server, both of which you have
> > > now
> > > needed to do.
> > 
> > The reason for implementing the kpasswd server is that the kadmind
> > from MIT 
> > Kerberos doesn't provide a way to check ACLs using the KDB plugin.
> 
> Yep.  
> 
> > 
> > Why do we have/need gensec_krb5?
> 
> kpasswd is a krb5 wrapped service, not a gssapi service, so we need
> it.
> 
> > 
> > Each GSSAPI functions creates a new krb5_context and throws it away
> > when the 
> > function is done.
> > 
> > However we need to load the HDB/KDB plugin we have so we can access
> > the keytab 
> > to decrypt tickets. Registering the plugin is done on the
> > krb5_context but we 
> > are not able to use that as GSSAPI is creating a new context for
> > each
> > call.
> > 
> > To fix that MIT Kerberos has a call krb5_ktkdb_set_context(). It is
> > used to 
> > set a different context for ktkdb_get_entry(). GSSAPI has its own
> > context but 
> > to access the KDB we need a context with the KDB keytab operations
> > registered. 
> > This functions allows it. The function is not public but we could
> > look into it 
> > and check if we can do something similar in Heimdal.
> > 
> > We should get rid of the gensec_krb5 module at least in production.
> 
> We can't, because the wrapping of the kpasswd protocol is not gssapi.

Why are we trying to wrap it in gensec then ?

kpasswd (like NTLM password changing) are not secure channel
establishment protocols and should not be mixed with those.
Password changing really is a separate thing with very specific and
narrow interfaces and should be treated as its own separate facility
IMO.
This would simplify matters greatly.

Simo.



More information about the samba-technical mailing list