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 <ea...@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 (ea...@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