gss_store_cred_into() and gss_acquire_cred_from() on a client specific basis

[moore moore]

 Thanks for the reply and info Greg
Looks like the error in the trace on call to gss_acquire_cred_from() is:[31361] 1558626925.414958: Retrieving clientuser1 at TEST.COM from FILE:/etc/krb5.keytab (vno 0, enctype 0) with result: -1765328203/No key table entry found for clientuser1 at TEST.COM
Why would it be looking in FILE: cache? when using the "store" handle input that was used for gss_store_cred_into()? 
Also when you say, proxy cred is the correct cred to cache, I have been caching the "delegated_cred_handle" as I wanted to retrieve that and use as the delegated_cred_handle input into next call of gss_init_sec_context(). Is that thinking wrong? and it just works by accident in single clientuser case?
Based on what you are saying, it should be the impersonator_cred_handle?
I quickly tried a call to gss_store_cred_into() with the impersonator_cred_handle and it failed with:
gss_store_cred_into: No credentials were supplied, or the credentials were unavailable or inaccessible gss_store_cred_into: Unknown error gss_store_cred_into failed with major:458752 and minor:0 
All that is in the trace for that specific all to gss_store_cred_into() with the impersonator_cred_handle is:[23610] 1558630947.630858: Destroying ccache MEMORY:6EupW9M[23610] 1558630947.630860: Destroying ccache MEMORY:P3uB2zU
The handle should be still valid. Basically calling in the same place as storing the delegated_cred_handle.After the successfull initial call to constrained_delegate() and before calling the release routines.        gss_release_cred(&minor, &impersonator_cred_handle);        gss_release_cred(&minor, &delegated_cred_handle);        gss_release_cred(&minor, &user_cred_handle);
I;m a bit handicapped with debug as there is no debugging gdb capabilities on the run time machine :-(So really appreciate your insight.












    On Thursday 23 May 2019, 16:27:06 GMT+1, Greg Hudson <ghudson at mit.edu> wrote:  
 
 On 5/23/19 8:04 AM, moore moore wrote:
> I have tried to create store with clientuser specific name also.like : MEMORY:clientuser1 at TEST.COM
> And while the store into still worked, acquire_from failed with:
> gss_acquire_cred_from: SPNEGO cannot find mechanisms to negotiate
> But I dont see a way to use ccache name anyways to reference the store subsequently?

This is the right approach; you need client-specific ccache names to
store the proxy creds.

gss_acquire_cred_from() accepts a cred_store parameter just like
gss_store_cred_into(), and it must contain the same (per-client) ccache
value to find the correct creds.

The SPNEGO error message isn't very specific.  You could use trace logs
to try to figure out why acquiring krb5 creds doesn't work, or you could
(temporarily, for debugging purposes) try acquiring krb5 creds instead
of SPNEGO creds.