[EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching
cneberg at sandia.gov
Tue Mar 12 18:46:20 EDT 2013
I've seen the code for mod_auth_kerb-5.4-9.el6.src.rpm which I think is what you are referring to. Is this correct?
Here is the description from the patch
+S4U2Proxy, or constrained delegation, enables a service to use a client's
+ticket to itself to request another ticket for delegation. The KDC
+checks krbAllowedToDelegateTo to decide if it will issue a new ticket.
+If KrbConstrainedDelegation is enabled the server will use its own credentials
+to retrieve a delegated ticket for the user. For this to work the user must
+have a forwardable ticket (though the delegation flag need not be set).
+The server needs a valid credentials cache for this to work.
+The module itself will obtain and manage the necessary credentials.
I looked through the patches and I'm unclear how it is meant to work. I see no new gssapi or krb5 related functions related to http://k5wiki.kerberos.org/wiki/Projects/Services4User. What are the outputs of the code when a user makes an HTTP request? Will a CGI have access to a credentials cache for the user, so it can just call gss-init-sec-context like normal, or will the CGI just have access to a cred cache for the impersonation account - and the CGI must do the heavy lifting to impersonate the user using the Services4User functions mentioned above?
In other words if you have two processes 1) the server which interacts with the user, and 2) a client process on the server which does something on the user's behalf using Kerberos - which process would normally call gss_acquire_cred_impersonate_name? 1 or 2?
Sorry, I'm new to this topic, so I may be missing something fundamental about how it is meant to work.
From: Simo Sorce [mailto:simo at redhat.com]
Sent: Tuesday, March 12, 2013 4:03 PM
To: Nebergall, Christopher
Cc: kerberos at mit.edu
Subject: [EXTERNAL] Re: Kerberos Constrained Delegation and Credential Caching
On Tue, 2013-03-12 at 00:23 +0000, Nebergall, Christopher wrote:
> Does anyone have any tips on copying the credentials created from Kerberos constrained delegation to a credentials cache file and back in again? In the example krb5-1.10.3/src/tests/gssapi/t_s4u.c at near the end of contrainedDelegate function after the gss_init_sec_context tried to copy the delegated_cred_handle to a credentials cache. I've NEVER seen the a service ticket for the end service make to the cache file so I'm not sure which cred cache I should be using.
> I've tried 1) just using the default cache
> 2) with gss_store_cred with
> memset(&elements_stored, 0, sizeof(elements_stored));
> memset(&cred_usage_stored, 0, sizeof(cred_usage_stored)); major =
> gss_store_cred(&minor, delegated_cred_handle, GSS_C_BOTH,
> GSS_C_NULL_OID, 1, 1, &elements_stored, &cred_usage_stored);
> 3) or with gss_krb5_copy_ccache
> Nothing shows a cached the service ticket. I'm not even certain which prinicipal I should initialize the ccache with - the impersonator prinicipal, or the user principal name?
> I've also tried various methods of reading the new cache back in and then re-running constrainedDelegate but I often get a "gss_init_sec_context: Matching credential not found"
> My goal is to put this code into mod_auth_kerb with mod_proxy but I'm unclear how to make it not hit the KDC with every request if I can't get a credential's cache saved, and reloaded between requests.
Red Hat has already sent upstream patches to support s4u2proxy authentication in mod_auth_kerb, you may want to check this thread:
(they are not in the upstream code yet apparently nobody picked them up).
Simo Sorce * Red Hat, Inc * New York
More information about the Kerberos