Constrained Delegation and PAC : Realm crossover

[Rick van Rein]

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