Re: A Local KDC

On Wednesday, 26 June 2024 00:18:51 GMT+2 Greg Hudson wrote:
> On 6/25/24 02:39, Andreas Schneider via krbdev wrote:
> > MIT Kerberos allows KDC and kadmind daemons to run bound to a particular
> > set of network addresses. This allows isolating a configuration to a
> > localhost, for example (127.0.0.0/24) but still makes the KDC running all
> > the time. For local KDC configurations an amount of principals stored in
> > the KDC database and number of requests to be handled would probably be
> > very low. It would be great to allow KDC daemons to operate over UNIX
> > domain sockets and handle its startup on demand with tools like systemd
> > socket activation or similar methods.
> 
> I would like to see Unix domain socket support, and may do the work
> myself at some point (but can't commit to a specific schedule).

I've looked into it and it is much more complex to do than I anticipated. 
However I could try to start working on this and open an MR.
 
> I would be happy to have socket activation support in the KDC and
> kadmind, but will probably not do the work myself.

systemd supports it, all we need is a unix domain socket :-)
 
> > If there could be a way to overlay individual callbacks on top of
> > an existing KDB driver, we could at least have something that would keep
> > user and service principals in lmdb and handle PAC issuance using SIDs
> > and account details from Samba databases.
> 
> I am open to changes which would allow this, though I am probably not
> the best person to do the work.  I can see two basic categories of
> designs: make the KDB interface stackable, or add a new interface
> specifically for PAC issuance.  It is probably easier to do the second;
> the kdcpolicy interface provides an example.

We fully understand this. We just need an agreement how to go forward. Your 
input is much appreciated.

> > IAKerb is only available over GSSAPI and one cannot use GSSAPI to
> > handle initial authentication for anything but password and keytab based
> > credentials.
> 
> The hard way to solve this problem is to define a GSS initial creds
> acquisition that can handle prompting via key/value sequences, and
> rearchitect the preauth system (including the clpreauth pluggable
> interface) to work with it--meaning, no more synchronous responder and
> prompter callbacks.  Such a design would be proxiable,
> mechanism-neutral, implementation-neutral, and friendly to language
> bindings, but it would take a lot of work to get there.
> 
> The easy way is to create a hybrid libkrb5/GSS extension API
> (gss_krb5_import_cred() is an example of an API in this category).  A
> design I had in mind is to convert a krb5_init_creds_context into a GSS
> credential handle which could then be used with an IAKERB
> gss_init_sec_context().  This design would have none of the benefits I
> listed above for the hard way, but would be a comparatively trivial
> amount of work.

Thanks for the ideas. We will discuss this.


Best regards


	Andreas

-- 
Andreas Schneider                      [email protected]
Samba Team                             www.samba.org
GPG-ID:     8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D


_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev