gss_store_cred_into() and gss_acquire_cred_from() on a client specific basis
ghudson at mit.edu
Thu May 23 14:47:02 EDT 2019
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:
>  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().
More information about the krbdev