Re: A Local KDC

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 would be happy to have socket activation support in the KDC and 
kadmind, but will probably not do the work myself.

> 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.

> 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.
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev