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

[Greg Hudson]

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().