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

[moore moore]

Hello,I'm using kerberos lib 1.16.1
I have a intermediary process acting as a proxy between clients and kerberized services.High level outline of the processing is as follows:- TGT is granted for impersonator representing the proxy. This principal is configured for delegation on KDC. - gss_acquire_cred() is used to acquire handle to impersonator- gss_acquire_cred_impersonate_name() is used to get "proxy credential" for Constrained delegation (S4U)- this is all very similar to the test code in t_s4u.c which ends up calling constrained_delegate()and gss_init_sec_context() with delegated_cred_handle 
All this works good and I can see in log:Creating authenticator for clientuser1 at test.com -> http/server1.test.com at TEST.COM, seqnum 341751283, subkey aes256-cts/143B, session key aes256-cts/99D6
I can see that the authenticator is built from call to krb5_mk_req_extended()The AP request is then sent from proxy to the service over SPNEGO.
I want to cache credential so that I can reuse for reauthentication 401 challenges from the service.

So I used: gss_store_cred_into() to store the delegated_cred_handle.When I do test (after the gss_store_cred_into()), with gss_acquire_cred_from() and then check_ticket_count(), it tells me I have the 3 creds.I think that this is correct.
"store" and "elem" are handles that I store in an application level session cache on a per clientuser basis.So each client SHOULD have their own to reference.
ccname is something like clientuser1 at TEST.COMcred is the "delegated_cred_handle" as in the code associated with constrained_delegate() function. (like in  t_s4u.c) 

        store->count = 1;        store->elements = elem;        elem->key = "ccache";        elem->value = ccname;
        major = gss_store_cred_into(&minor,                                    cred,                                    GSS_C_BOTH /*GSS_C_INITIATE*/,                                                                                                                                            &mech_krb5,                                                                                                                                                1, //overwrite                                                                                                                                                    0,                                    store,                                    NULL,                                    NULL);

And based on below, I can see the MEMORY:MY_CRED_STORE store being initialised.  [24024] 1558607679.670443: TGS reply is for clientuser1 at test.com -> http/server1.test.com at TEST.COM with session key aes256-cts/BFA1[24024] 1558607679.670444: TGS request result: 0/Success[24024] 1558607679.670445: Received creds for desired service http/server1.test.com at TEST.COM[24024] 1558607679.670446: Storing clientuser1 at test.com -> http/server1.test.com at TEST.COM in MEMORY:lFUNvFV[24024] 1558607679.670448: Creating authenticator for clientuser1 at test.com -> http/server1.test.com at TEST.COM, seqnum 455078816, subkey aes256-cts/190C, session key aes256-cts/BFA1[24024] 1558607679.670454: Initializing MEMORY:MY_CRED_STORE with default princ clientuser1 at test.com[24024] 1558607679.670455: Storing clientuser1 at test.com -> http/server1.test.com at TEST.COM in MEMORY:MY_CRED_STORE[24024] 1558607679.670456: Storing clientuser1 at test.com -> proxyuser at TEST.COM in MEMORY:MY_CRED_STORE[24024] 1558607679.670457: Storing clientuser1 at test.com -> krb5_ccache_conf_data/proxy_impersonator at X-CACHECONF: in MEMORY:MY_CRED_STORE[24024] 1558607679.670458: Storing proxyuser at TEST.COM -> krb5_ccache_conf_data/pa_type/krbtgt\/TEST.COM\@TEST.COM at X-CACHECONF: in MEMORY:MY_CRED_STORE[24024] 1558607679.670459: Storing proxyuser at TEST.COM -> krbtgt/TEST.COM at TEST.COM in MEMORY:MY_CRED_STORE[24024] 1558607679.670462: Destroying ccache MEMORY:lFUNvFV[24024] 1558607679.670464: Destroying ccache MEMORY:we3p14b

When a 401 reauthentication comes back from the kerberised server - I do the following:
major = gss_acquire_cred_from(&minor,                              bname,                              0,                              mechs,                              cred_usage,                              &store,   // store used in the call to gss_store_cred_into() above.                               &delegated_cred_handle,                              NULL,                              NULL);if(check_gsserr("gss_acquire_cred_from", major, minor)){                printf("gss_acquire_cred_from error major :%d, minor:%d",major, minor);}else{ constrained_delegate(delegated_cred_handle, impersonator_cred_handle, target, &ticket_desc);}
And this generates new authenticator so that I can use over SPNEGO between proxy and server. 
[24024] 1558607699.14566: Getting credentials clientuser1 at test.com -> http/server1.test.com at TEST.COM using ccache MEMORY:MY_CRED_STORE[24024] 1558607699.14567: Retrieving clientuser1 at test.com -> http/server1.test.com at TEST.COM from MEMORY:MY_CRED_STORE with result: 0/Success[24024] 1558607699.14569: Creating authenticator for clientuser1 at test.com -> http/server1.test.com at TEST.COM, seqnum 8453532, subkey aes256-cts/94CE, session key aes256-cts/BFA1[24024] 1558607699.14589: Getting credentials clientuser1 at test.com -> http/server1.test.com at TEST.COM using ccache MEMORY:MY_CRED_STORE[24024] 1558607699.14590: Retrieving clientuser1 at test.com -> http/server1.test.com at TEST.COM from MEMORY:MY_CRED_STORE with result: 0/Success[24024] 1558607699.14592: Creating authenticator for clientuser1 at test.com -> http/server1.test.com at TEST.COM, seqnum 690537534, subkey aes256-cts/EF50, session key aes256-cts/BFA1

So all this is good and avoids TGS round trips to the KDC.

However, when a different client logs in, clientuser2, the service tickets get polluted.Where clientuser1 can get access to clientuser2 backend server session.
I then noticed that the way I imported bname ( desired_name ) input parameter to gss_acquire_cred_from() was wrong.
So I tried import_name() with "u:clientuser1 at test.com" which should give nametype of GSS_C_NT_USER_NAME for gss_import_name.But that makes gss_acquire_cred_from() fail with:
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

I think I need to be able to hold a fleet of credentials that are specific to the clients, which is what I have.ie. store and elem in an application level client specific session cache, so that I can reuse that specific cred to generate new authenticator for the clientuser to the service.But somehow it seems that the "store" is not exclusive? 
Am I creating the store at the correct level, storing the correct cred? ie. delegated_cred_handle  Why does it get polluted with credential for different user?
I have tried to create store with clientuser specific name also.like : MEMORY:clientuser1 at TEST.COMAnd while the store into still worked, acquire_from failed with:gss_acquire_cred_from: SPNEGO cannot find mechanisms to negotiate gss_acquire_cred_from error major :851968, minor:100005
But I dont see a way to use ccache name anyways to reference the store subsequently?
Any thoughts most welcome on what the recommended/best approach would be?
Thank you kindly.