Multiple KDC's realm heuristic for KRB5CCNAME=DIR:/tmp/mydir/ ccache not working

Greg Hudson ghudson at mit.edu
Tue Jul 24 14:47:38 EDT 2018


On 07/24/2018 01:56 PM, Martin Gee wrote:
> Added:  krbdev at mit.edu

Please pick one list or the other.  I've left the message to 
kerberos at mit.edu in the moderation queue and omitted it from the to line 
here.

> 2. If the realm of the target service is known via a [domain_realm]
> mapping in krb5.conf, a client principal in that realm will be selected.

> Do the mechanisms you list work for constrained delegation?

They do not.

Constrained delegation (S4U2Proxy) requires an evidence ticket.  MIT's 
library supports two ways of getting an evidence ticket: either by using 
protocol transition (S4U2Self) via a call to 
gss_acquire_cred_impersonate_name(), or by receiving the evidence ticket 
from a Kerberos-using client via gss_accept_sec_context().

In the first case (which is what t_s4u does), 
gss_acquire_cred_impersonate_name() has no idea what the constrained 
delegation target server will be, so it has to resolve the 
impersonator_cred_handle with no target name, which means picking the 
primary cache.  The TGT from that same cache will be used for the 
constrained delegation step.

In the second case, gss_accept_sec_context() constructs an evidence cred 
containing the TGT from the verifier cred handle and the ticket 
presented by the client.  Again, gss_accept_sec_context() has no idea 
what the constrained delegation target server will be, so it picks the 
TGT from the primary cache.  This could possibly be improved by looking 
for a TGT which matches the server key the client authenticated to, but 
that is not implemented.

To make S4U2Self+S4U2Proxy work with credential cache selection, I think 
we would need a way to do it in one step.  I can't think of an easy way 
to express that with current GSS function signatures.


More information about the krbdev mailing list