[39149] in Kerberos
Re: Kerberos protocol transition with unconstrained delegation (i.e.
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Thu Oct 27 12:42:14 2022
MIME-Version: 1.0
In-Reply-To: <87y1t1ntsv.fsf@hope.eyrie.org>
From: Jeffrey Hutzelman <jhutz@cmu.edu>
Date: Thu, 27 Oct 2022 12:36:43 -0400
Message-ID: <CALF+FNxW4gXTuS6iBPKaFeLLRoD1Y+-n-Nd-G7-V=W30AOg9eg@mail.gmail.com>
To: Russ Allbery <eagle@eyrie.org>
Cc: Jonathan Calmels via Kerberos <kerberos@mit.edu>,
Jonathan Calmels <jcalmels@nvidia.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
You don't need libkadm5 for any of this -- all you need to print a service
ticket (even a TGT) is the service's key. Heimdal comes with a program,
kimpersonate, which does this and could easily be used as a basis for your
impersonation service. Naturally, you should be cautious about giving an
application the key for the TGS (even a cross-realm TGS); as Russ points
out, this makes that application equivalent to a KDC.
-- Jeff
On Thu, Oct 27, 2022 at 11:59 AM Russ Allbery <eagle@eyrie.org> wrote:
> Jonathan Calmels via Kerberos <kerberos@mit.edu> writes:
>
> > So far, the only hack we can think of is replicating the AD users into
> > the MIT KDC and writing some kind of GSS service that would issue TGTs
> > for those (given the proper service ticket). Something like:
>
> > 1. The scheduler does protocol transition with the AD UPN it got from
> > the CI/CD
> > 2. The scheduler contacts this GSS service with the resulting service
> > ticket
> > 3. The GSS service converts the UPN from the AD realm to its MIT
> > realm counterpart
> > 4. If everything checks out, it sends back a TGT for the user (this
> > might involve some unconventional calls to libkadm5)
> > 5. The scheduler forwards this TGT as usual
>
> Yup, this is also what I would do given your constraints. (You have a
> fairly weird security corner case that requires arbitrary user
> impersonation with no chain of authentication back to the user being
> impersonated, which Kerberos doesn't really natively support for somewhat
> obvious reasons.)
>
> > Is there a cleaner alternative? Ideally, one that doesn't involve
> > replicating users.
>
> You possibly could cheat by giving the GSS service access to the
> cross-realm key so that it can forge TGTs that look to the MIT Kerberos
> KDC as if they were issued by AD. I think this would be roughly
> equivalent from a security standpoint (either way, the GSS service is
> essentially a KDC and has full access to the entirety of your MIT realm),
> but would avoid the need to create principals in your KDC database for
> every user.
>
> The drawback of this approach is that you're likely to need to write some
> low-level Kerberos code to forge the tickets, whereas in your plan above
> you can just generate keytab files for every user and store them on disk
> (again, the GSS service is functionally equivalent to a KDC, so this is
> just the KDC database in another format), and then your GSS service can
> generate TGTs through normal libkrb5 calls using the keytab and doesn't
> have to do anything special.
>
> --
> Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
