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

[moore moore]

 So, if I simply change the cred_usage to GSS_C_INITIATE ( it was BOTH),I get a slightly different error from gss_acquire_cred_from()
Retrieving clientuser1 at TEST.COM from FILE:/krb5/dest/var/krb5/user/0/client.keytab (vno 0, enctype 0) with result: 2/Key table file '/krb5/dest/var/krb5/user/0/client.keytab' not found
So it is still looking for a keytab and I'm not sure how or why.
gss_store_cred_into() uses:

store->count = 1;store->elements = elem;elem->key = "ccache";elem->value = ccname;
where ccname is: MEMORY:clientuser1 at TEST.COM
Is that correct? 
This the output from log:[18869] 1558646982.419337: Initializing MEMORY:clientuser1 at TEST.COM with default princ clientuser1 at TEST.COM[18869] 1558646982.419338: Storing clientuser1 at TEST.COM -> http/server1.test.com at TEST.COM in MEMORY:clientuser1 at TEST.COM[18869] 1558646982.419339: Storing clientuser1 at TEST.COM -> proxyuser at TEST.COM in MEMORY:clientuser1 at TEST.COM[18869] 1558646982.419340: Storing clientuser1 at TEST.COM -> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: in MEMORY:clientuser1 at TEST.COM[18869] 1558646982.419341: Storing proxyuser at TEST.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM at X-CACHECONF: in MEMORY:clientuser1 at TEST.COM[18869] 1558646982.419342: Storing proxyuser at TEST.COM -> krbtgt/TEST.COM at TEST.COM in MEMORY:clientuser1 at TEST.COM
Does that prove it is going into a MEMORY ccache? 
I do have cred usage on the gss_store_cred_into() as BOTH also, but I also tried with GSS_C_INITIATE 
and the gss_acquire_cred_from() failed with the same error as above ( looking for a keytab)



On the second point, I tried to store the "user_cred_handle" which is the output the call to gss_acquire_cred_impersonate_name() but that would not go into the store either.
There is nothing in the trace but the local logging error gives:
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
So the only cred handle that that will store for me is the "delegated_cred_handle"!

Thanks for your help. 
    On Thursday 23 May 2019, 19:47:07 GMT+1, Greg Hudson <ghudson at mit.edu> wrote:  
 
 On 5/23/19 1:15 PM, moore moore wrote:
> 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()?

That's not a ccache, that's a keytab.  Make sure you are passing
GSS_C_INITIATE as the cred_usage to gss_acquire_cred_from() for this
call, not GSS_C_ACCEPT or GSS_C_BOTH.

> 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?

In t_s4u.c, the call to init_accept_sec_context() is unnecessary -- it
helps with test coverage and allows some extra information to be
displayed, but you can just use the proxy cred (user_cred_handle in
t_s4u.c) as input to the constrained delegation gss_init_sec_context() call.

If you do the init/accept round trip after the S4U2Self request, there
is functionally, there is no difference between storing or using the
proxy cred or delegated cred handles.

> Based on what you are saying, it should be the impersonator_cred_handle?

No, the impersonator_cred_handle represents the intermediate service.
You need the output of gss_acquire_cred_impersonate_name().