Kerberos protocol transition with unconstrained delegation (i.e. TGT impersonation)

[Jeffrey Hutzelman]

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 at eyrie.org> wrote:

> Jonathan Calmels via Kerberos <kerberos at 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 at eyrie.org)             <https://www.eyrie.org/~eagle/>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>