Multiple KDC's realm heuristic for KRB5CCNAME=DIR:/tmp/mydir/ ccache not working
geemang_2000 at yahoo.com
Wed Jul 25 16:45:38 EDT 2018
gss_acquire_cred(minor, gss_spn_name, GSS_C_INDEFINITE, &mechset_krb5, GSS_C_BOTH, &impersonator_cred, NULL, &time_rec);
gss_acquire_cred_impersonate_name(minor, impersonator_cred, gss_user_name, GSS_C_INDEFINITE, &mechset_krb5, GSS_C_INITIATE, &user_cred, NULL, &time_rec);
gss_init_sec_context(minor, user_cred, &ictx, gss_spn_name, &mech_krb5, GSS_C_REPLAY_FLAG | GSS_C_SEQUENCE_FLAG, GSS_C_INDEFINITE, GSS_C_NO_CHANNEL_BINDINGS, &atok, NULL, &itok, NULL, NULL);
gss_accept_sec_context(minor, &actx, impersonator_cred, &itok, GSS_C_NO_CHANNEL_BINDINGS, &source_name, &mech, &atok, NULL, NULL, &delegated_cred);
On Wednesday, July 25, 2018 3:23 PM, Greg Hudson <ghudson at mit.edu> wrote:
On 07/25/2018 03:04 PM, Martin Gee wrote:
> I'd like to use the automatic ccache creation that
> gss_acquire_cred_* does. gss_acquire_cred is failing with a custom
> keytab location/name.
Have a look at:
The client keytab is located separately from the server keytab.
> Seems gss_acquire_cred only works when /etc/krb5.keytab is present.
I wouldn't expect gss_acquire_cred() to use /etc/krb5.keytab unless one
of the locators for the client keytab was explicitly set to point to it.
So this and the corresponding attempts to use /etc/krb5.keytab in the
trace logs are confusing to me. Precisely what GSS calls are being traced?
> I've tried these:
These all set the server keytab location.
More information about the krbdev