[39147] in Kerberos
Re: Kerberos protocol transition with unconstrained delegation
daemon@ATHENA.MIT.EDU (Russ Allbery)
Thu Oct 27 12:02:41 2022
From: Russ Allbery <eagle@eyrie.org>
To: Jonathan Calmels via Kerberos <kerberos@mit.edu>
CC: Jonathan Calmels <jcalmels@nvidia.com>
In-Reply-To: <BYAPR12MB2888DAD8E37405BF96B1065CBB339@BYAPR12MB2888.namprd12.prod.outlook.com>
(Jonathan Calmels via Kerberos's message of "Thu, 27 Oct 2022 06:34:28
+0000")
Date: Thu, 27 Oct 2022 08:57:20 -0700
Message-ID: <87y1t1ntsv.fsf@hope.eyrie.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
