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

Russ Allbery eagle at eyrie.org
Thu Oct 27 21:39:54 EDT 2022


Jonathan Calmels <jcalmels at nvidia.com> writes:

> Thank you for the suggestions, I didn't know about kimpersonate and this
> would indeed solve part of the problem.  The reason why I mentioned
> libkadm5 is because we were thinking of relying on
> "kadm5_get_principal_keys" instead of keytabs.  This way we could also
> reuse the kadm ACLs and have a rule like "gsshostservice at REALM e
> */ci at REALM".

You can certainly do that, but just be aware that there's not much in the
way of a security difference between that and keytabs.  In theory it means
the GSS service doesn't have access to all the user's keys at once but has
to ask for them on demand, but if I were you I'd just colocate the GSS
service with the KDC since the security model is essentially the same, at
which point the KDC database is right there and there's really no
particularly meaningful distinction.

(I have implemented something akin to this before, and that's how I did
it.)

> Forging a cross-realm TGT would definitely be preferable, although I'm
> not sure if it's doable with libkrb5.

It should be doable, but you may have to use really low-level functions to
duplicate what kimpersonate is doing.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>


More information about the Kerberos mailing list