Hi Simo / others, >>> What I'm left wondering is, if the client's KDC knows what delegations >>> are permitted, as is the case with FreeIPA, is it not simpler to pass on >>> the additional tickets for smtp/ and imap/ in an AD structure in the >>> webmail ticket? >> This is a potential optimization I have been thinking about before, but >> requires clients that understand how to extract these tickets and put >> them in their ccache. Perfectly doable though.
I worked out a solution to be configured / implemented in the client's KDC, and not needing any involvement from the client's libkrb5. It's the service that would need to unpack the credentials in the name of the client. It's not very pretty, but possible. It's easy enough to add a KRB-CRED structure into a Ticket using a new ad-type AD-BACKEND-TICKETS. These tickets can be requested by the client's KDC by producing a TGT on behalf of the client, and using that to send TGS-REQ for the backend services. This can even be done recursively (backend services have their own backend services). What I think is not pretty, is that the client's KDC must AFAIK respond with the annotated ticket falling under its own realm [1]. So a service ticket is obtained by the client's KDC and renamed to one under the client's realm. The client will not see the service's realm, because the KDC renames the ticket. The server must then re-rename the ticket to its own realm before it can do its local keytab lookup. [1] or it might first redirect, but not to the service's realm, as that is not to be trusted in general. Still, it's better than sending over a FORWARDED TGT plus its session key as is done with S4U2Proxy. This approach offers much more control, and requires no client changes. Only the KDC and service must be setup to match each other's expectations. -Rick ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos