[EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching

Simo Sorce simo at redhat.com
Wed Mar 13 12:08:19 EDT 2013

On Wed, 2013-03-13 at 15:10 +0000, Nebergall, Christopher wrote:
> Thank you for your response it helped a great deal.     
> >The fact is that there are a few ways in which this work, when
> mod_auth_kerb is used, the action of exporting a ccache file with the
> received >credentials is basically equivalent to calling
> gss_acquire_cred_impersonate_name
> Ok, so the gss_accept_sec context in mod_auth_kerb can do restricted
> delegation/S4U2Proxy almost transparently if its creds are acquired
> using usage = GSS_C_BOTH, and it has TGT for its own creds available.
> Correct?
> My use case also requires the use of S4U2Self in mod_auth_kerb - so a
> Kerberos cred cache is available even if mod_auth_kerb didn't do the
> authentication - it instead was done by a different apache module such
> as mod_auth_radius or shibboleth.   So I would need to modify
> mod_auth_kerb so it supports doing S4U2Self and manage the cache, when
> it itself didn't authenticate the user - it just gets the identity
> from the apache request rec.  Does that make sense? 

I don't see a technical problem in this, however it is not clear to me
why you would do all of this in mod_auth_kerb given you are doing no
authentication there at this point.

Is the connecting client doing any kerb auth at all?
If not you may be better off (as in it being more flexible for you)
doing the whole s4u2self+s4u2proxy dance within your application.


Simo Sorce * Red Hat, Inc * New York

More information about the Kerberos mailing list