[PATCH] Implement a more abstracted kpasswd service

[Andrew Bartlett]

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.

> > 
> > I think this is the right choice, it is much easier to ensure we
> > get
> > the correct protocol semantics this way, but I know your team spent
> > quite some resources on the attempt to use the MIT kpasswd server.
> 
> gensec_krb5 is used in testing to verify that some old Samba client
> behavior 
> still works against the current Samba AD KDC. I don't know which
> version had 
> this strange behavior it would be great to know which versions that
> really 
> are.
> 
> > 
> > Thanks for all the hard work on this, it is critical work and
> > really
> > important to the long term viability of Samba.
> 
> Thanks, I hope we can work on some things during the Samba IO Lab and
> find and 
> fix some bugs.

I very much look forward to it.

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba