Can't acquire stored impersonated creds from cache

[Greg Hudson]

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.