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

[moore moore]

 Yes, absolutely, the same process is handling the gss_store_cred_into() and the latergss_acquire_cred_from().

What is strange is that, (alluding to my original message),When the store is initialised with: MEMORY:MY_CRED_STORE
[28396] 1558699329.882132: Initializing MEMORY:MY_CRED_STORE with default princ clientuser1 at TEST.COM[28396] 1558699329.882133: Storing clientuser1 at TEST.COM -> http/server1.test.com at TEST.COM in MEMORY:MY_CRED_STORE[28396] 1558699329.882134: Storing clientuser1 at TEST.COM -> proxyuser at TEST.COM in MEMORY:MY_CRED_STORE[28396] 1558699329.882135: Storing clientuser1 at TEST.COM -> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: in MEMORY:MY_CRED_STORE[28396] 1558699329.882136: Storing proxyuser at TEST.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM at X-CACHECONF: in MEMORY:MY_CRED_STORE[28396] 1558699329.882137: Storing proxyuser at TEST.COM -> krbtgt/TEST.COM at TEST.COM in MEMORY:MY_CRED_STORE
The process pid is 28396
Subsequently (only a second later) a call to gss_acquire_cred_from() will result in:
[28396] 1558699330.991814: Getting credentials clientuser1 at TEST.COM -> http/server1.test.com at TEST.COM using ccache MEMORY:MY_CRED_STORE[28396] 1558699330.991815: Retrieving clientuser1 at TEST.COM -> http/server1.test.com at TEST.COM from MEMORY:MY_CRED_STORE with result: 0/Success[28396] 1558699330.991817: Creating authenticator for clientuser1 at TEST.COM -> http/server1.test.com at TEST.COM, seqnum 362610509, subkey aes256-cts/D0D8, session key aes256-cts/F87B

So that appears to work exactly as I require. Until a another user logs in. and I guess there is a behind the scenes use of the MEMORY:MY_CRED_STORE??



So when I change the cache name to be unique to the clientuserie. like this: MEMORY:clientuser1 at TEST.COM
The store init still looks OK.

[10940] 1558700394.80052: Initializing MEMORY:clientuser1 at TEST.COM with default princ clientuser1 at TEST.COM[10940] 1558700394.80053: Storing clientuser1 at TEST.COM -> http/server1.test.com at TEST.COM in MEMORY:clientuser1 at TEST.COM[10940] 1558700394.80054: Storing clientuser1 at TEST.COM -> proxyuser at TEST.COM in MEMORY:clientuser1 at TEST.COM[10940] 1558700394.80055: Storing clientuser1 at TEST.COM -> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: in MEMORY:clientuser1 at TEST.COM[10940] 1558700394.80056: 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[10940] 1558700394.80057: Storing proxyuser at TEST.COM -> krbtgt/TEST.COM at TEST.COM in MEMORY:clientuser1 at TEST.COM

But the subsequent call to gss_acquire_cred_from() ( same code path as above ) fails with:

[10940] 1558700394.80066: 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
You can see is it same process pid also: 10940 for that test. 

This is the call to store_into is like:
        store->count = 1;        store->elements = elem;        elem->key = "ccache";        elem->value = ccname;

major = gss_store_cred_into(&minor,                            cred,                            GSS_C_INITIATE,                                                                                                                                &mech_krb5,                                  1, //overwrite                                0, //default cred                                 store, // pointer to a gss_key_value_set_desc                            NULL,                            NULL);

And acquire:
gss_name_t gss_name;
gss_name = import_name(name); // name like u:clientuser1 at TEST.COM

major = gss_acquire_cred_from(&minor,                                      gss_name,                                                                                                                                                0,                                      mechs,                                        //&mechset_krb5,                                           //&mechset_spnego,                                       GSS_C_INITIATE, //cred_usage,                                                   &store,                                      &delegated_cred_handle,                                      NULL,                                      NULL);

With mech as "&mech_krb5", I get nothing in the trace.
But the following local logs from check_gsserr()gss_acquire_cred_from: An unsupported mechanism was requested gss_acquire_cred_from: Unknown error gss_acquire_cred_from error major :65536, minor:0
With mechset_spnego, I get:[10940] 1558700394.80066: 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
and check_gsserr()gss_acquire_cred_from: Unspecified GSS failure.  Minor code may provide more information gss_acquire_cred_from: SPNEGO cannot find mechanisms to negotiate gss_acquire_cred_from error major :851968, minor:100005



So why is the there a difference on gss_acquire_cred_from() betweenMEMORY:MY_CRED_STORE with a ccname of "clientuser1 at TEST.COM"
andMEMORY:clientuser1 at TEST.COM with a ccname of  "clientuser1 at TEST.COM"

There are process restarts between the tests of course so every test is a clean base. Same test - only difference is in the naming of the ccache. And gss_acquire_cred_from() uses desired_name of "clientuser1 at TEST.COM"  ( used as "u:clientuser1 at TEST.COM" as input to import_name() utility)

Thanks again Greg. 








    On Thursday 23 May 2019, 23:30:49 GMT+1, Greg Hudson <ghudson at mit.edu> wrote:  
 
 On 5/23/19 5:36 PM, moore moore wrote:
> 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.

It's normal for gss_acquire_cred() to check the client keytab if it
doesn't find credentials in the ccache, so this trace message isn't the
reason why the operation is failing.  Look for ccache operations earlier
in the trace output.

> gss_store_cred_into() uses:
[...]
> [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? 

Yes.

The same process is handling the gss_store_cred_into() and the later
gss_acquire_cred_from(), right?

> I do have cred usage on the gss_store_cred_into() as BOTH also, but I
> also tried with GSS_C_INITIATE 

GSS_C_INITIATE is correct, but in the current implementation there isn't
a behavior difference.

> 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 

That's GSS_S_NO_CRED.  By my reading of the code, gss_store_cred_into()
only returns that if its input_cred_handle is null (aka
GSS_C_NO_CREDENTIAL).  Can you double-check that you aren't passing a
null handle when you get this error?