[20492] in Kerberos_V5_Development
Re: A Local KDC
daemon@ATHENA.MIT.EDU (Andreas Schneider via krbdev)
Wed Jun 26 01:58:46 2024
To: krbdev@mit.edu, Greg Hudson <ghudson@mit.edu>
Cc: ab@samba.org
Date: Wed, 26 Jun 2024 07:58:24 +0200
Message-ID: <2781191.QOukoFCf94@magrathea>
In-Reply-To: <1eaa7f06-6eec-4ece-8060-ef1b0987ebfe@mit.edu>
MIME-Version: 1.0
From: Andreas Schneider via krbdev <krbdev@mit.edu>
Reply-To: Andreas Schneider <asn@samba.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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 asn@samba.org
Samba Team www.samba.org
GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
