Multiple KDC's realm heuristic for KRB5CCNAME=DIR:/tmp/mydir/ ccache not working

[Martin Gee]

Greg, I have something working :)  I had to set both KRB5_KTNAME and KRB5_CLIENT_KTNAME to my desired keytab file.  
Can you plz help me confirm my understanding of why both env variables are necessary?

e.g. where t_getImpSecurityToken does what t_s4u w/ ccache creation
        setenv("KRB5CCNAME", "/tmp/krb5cc_v_icsynergy_net", 1);        setenv("KRB5_KTNAME", "/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab", 1);        setenv("KRB5_CLIENT_KTNAME", "/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab", 1);        const char* service_name = "host/gw.icsynergy.info at ICSYNERGY.NET";        const char* user_name = "tuser1 at ICSYNERGY.NET";        const char* host_name =  "HTTP at ics-dc-1.icsynergy.net";        t_getImpSecurityToken(service_name, user_name,  host_name);
KRB_KTNAME is logged:[2606] 1532615727.367867: Retrieving host/gw.icsynergy.info at ICSYNERGY.NET from FILE:/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab (vno 0, enctype 0) with result: 0/Success

KRB5_CLIENT_KTNAME is logged:
[4694] 1532615787.103586: Retrieving host/gw.icsynergy.info at ICSYNERGY.NET from FILE:/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab (vno 0, enctype 0) with result: 0/Success
Here is my gss_acquire_cred (seems to be all rooted in this call):gss_acquire_cred(minor, gss_spn_name, GSS_C_INDEFINITE, &mechset_krb5, GSS_C_BOTH, &impersonator_cred, NULL, &time_rec);
GSS_C_BOTH - (acquire_cred.c) acquire_accept_cred uses KRB_KTNAME(acquire_cred.c) acquire_init_cred uses KRB5_CLIENT_KTNAME which overrides:
/etc/krb5.conf[libdefaults]
default_client_keytab_name = /etc/krb5.keytab

The main diff from t_s4u is; gss_spn_name (host/gw.icsynergy.info at ICSYNERGY.NET) is being used instead of GSS_C_NO_NAME

I'm assuming gss_spn_name + GSS_C_BOTH is exercising both env variables?







 

    On Wednesday, July 25, 2018 3:45 PM, Martin Gee <geemang_2000 at yahoo.com> wrote:
 

 
krb5_gss_register_acceptor_identity("../file.keytab");
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:

http://web.mit.edu.ezproxyberklee.flo.org/kerberos/krb5-latest/doc/basic/keytab_def.html#default-client-keytab

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:
> export 
> KRB5_KTNAME=/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab
> setenv("KRB5_KTNAME", 
> "/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab", 
> 1)
> krb5_gss_register_acceptor_identity("/opt/development/spgw/spgw-gssapi/GSSAPIMemory/spgateway_icsynergy_net.keytab");

These all set the server keytab location.