Hi,
We have a Linux cluster fully kerberized including its own MIT Kerberos KDC which we control.
Users authenticate to it through a one-way trust with an Active Directory. After being authenticated, users submit their workload with their TGT and the scheduler will forward it to the nodes it allocated (i.e. unconstrained delegation).
So far everything is working as expected.
Now the problem is that we need to support the same workflow from a CI/CD webservice.
Users authenticate to the CI/CD webservice through SAML and will trigger some kind of job to be scheduled. The scheduler knows the user's principal but doesn't have a TGT associated with it.
Basically, the scheduler needs a way to impersonate users' TGTs to start their workload.
How does one go about that? given that:
- We can't use SPNEGO on the CI/CD webservice or request anything from the user there. It has to be regular SAML and we don't control user interactions.
- We can't use constrained delegation (aka. S4U) because the scheduler needs the user's TGT not a service ticket. Users are free to use their TGT however they want from the allocated nodes.
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
Is there a cleaner alternative? Ideally, one that doesn't involve replicating users.
If not, is libgssapi and likadm5 the best way to implement it or would something like a plugin module be better suited?
Thanks for any insight
________________________________________________
Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
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
Is there a cleaner alternative? Ideally, one that doesn't involve
replicating users.
Jonathan Calmels via Kerberos <[email protected]> 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 ([email protected]) <https://www.eyrie.org/~eagle/> ________________________________________________
Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
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@REALM e
*/ci@REALM".
Forging a cross-realm TGT would definitely be preferable, although I'm
not sure if it's doable with libkrb5.
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.
On 10/27/22 12:36, Jeffrey Hutzelman wrote:
You don't need libkadm5 for any of this -- all you need to print aservice
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 foryour
impersonation service.
MIT krb5 has a sort-of equivalent: "kinit -k -t KDB: username". The KDC
is still in the loop, but no password or keytab for the user is
required. (Add "-S krbtgt/OTHERREALM" for a cross-realm TGT.)
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 160:00:23 |
| Calls: | 12,094 |
| Calls today: | 2 |
| Files: | 15,000 |
| Messages: | 6,517,761 |