On 09/20/2015 07:46 AM, Martin Gee wrote:
> Version: 1.14I'm attempting to cache some impersonated credentials by using
> gss_store_cred with the output cred from gss_acquire_cred_impersonate_name.I
> see the credential via klist after my program runs.
[...]
> Major gss_acquire_cred_impersonate_name:851968 - Unspecified GSS failure.
> Minor code may provide more information
> Minor gss_acquire_cred_impersonate_name:-2045022969 - Credential usage type
> is unknown
> But the call seems to error out as shown. I am using GSS_C_INITIATE as the
> usage type.Am I missing something?
I can reproduce this problem and have opened a ticket:
http://krbdev.mit.edu/rt/Ticket/Display.html?id=8248
Unfortunately, the only current way to do what you want is to make your
application manage a fleet of credential caches for each impersonated
credential. The outline of your code would be:
1. Choose a ccache name based on the subject name.
2. Try to read the chosen ccache name using gss_acquire_cred_from(). On
success, stop and use that cred directly for the subsequent operation
(which I assume is S4U2Proxy using gss_init_sec_context()). On failure,
continue to step 3.
3. Acquire a service TGT cred from the default cache using
gss_acquire_cred(). (Or from a separately chosen cache name for the
service TGT using gss_acquire_cred_from(), if you want.)
4. Make an S4U2Self request using gss_acquire_cred_impersonate_name(),
using the service TGT cred object as the impersonator cred.
5. Store the result into the chosen ccache name using gss_store_cred_into().
gss_acquire_cred_from() and gss_store_cred_into() are GSS extensions
added in MIT krb5 release 1.11.
> I'm using the latest kerb build. I believe this used to work with 10.1.13
I'm not sure if you mean 1.10 or 1.13, but either way, this scenario
never worked as far as I can tell. In 1.11 and later, it fails for the
reasons described in the ticket; in 1.10, gss_store_cred() fails with:
gss_store_cred: Invalid credential was supplied
gss_store_cred: Principal in credential cache does not match desired
name
There is a variant scenario which sort of works in 1.11 and later. If
the service ccache does not contain forwardable tickets,
gss_acquire_cred_impersonate_name() does not construct a proxy cred
object; instead it just creates a memory cache containing the
subject-to-service ticket. This credential object cannot be used for
S4U2Proxy, but it does store and retrieve successfully. Even in this
limited scenario, repeated runs of the program each store a copy of the
subject-to-service ticket, causing the cache to grow without bound.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
