On 03/24/2014 02:23 PM, Arpit Srivastava wrote: > I followed the steps you described in your previous mail, however, what > I observed is that if TGT is not present in cache file - > gss_init_sec_context fails with min_status KRB5_CC_NOTFOUND.
If I create a ccache with only a service ticket using kinit -S, I can successfully run ssh or the GSS sample application. So there is no general restriction of this kind. > klist output: > > Service principal > krbtgt/[email protected] > HTTP/homepage.example.com@ > HTTP/[email protected] > > KerberosApp.trace: > > [12780] 1395683631.292486: Retrieving [email protected] -> HTTP\/ > homepage.example.com/example.com@ from > FILE:/etc/local/kerberos/ccache/krb5cc with result: 0/Unknown code 0 > [12780] 1395683631.294109: Creating authenticator for [email protected] -> > HTTP\/homepage.example.com/example.com@, seqnum 1032037665, subkey > aes256-cts/2942, session key aes256-cts/904D That doesn't look right at all. "HTTP\/homepage.example.com/example.com@" is not the same as "HTTP/homepage.example.com" and does not appear as the service entry in the ccache. I don't see how this lookup could succeed. That principal name looks like the result of misusing gss_import_name by specifying GSS_C_NT_HOSTBASED and the string form of a Kerberos principal instead of a host-based name ("service@host"). Since I don't understand why the lookup is succeeding in the successful case, I also have no idea why the lookup is failing in the failure case. > Could it be because session keys not being there in krb5cc file (I think > authenticator is generated using session keys) ? Each entry in the ccache contains a ticket session key; a TGT is not special this regard. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
