Kerberos protocol transition with unconstrained delegation (i.e. TGT impersonation)
Jeffrey Hutzelman
jhutz at cmu.edu
Thu Oct 27 12:36:43 EDT 2022
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
>
More information about the Kerberos
mailing list