Hi Greg, 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. Pls see the klist output of each cache file and corresponding Kerberos trace log below.
---------------------------------------------------------------------------------------------------------------- With TGT + Service Ticket cache -> (SUCCESS CASE) 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 ------------------------------------------------------------------------------------------------------------------- With only Service Ticket cache -> (FAILURE CASE) klist output: Service principal HTTP/homepage.example.com@ HTTP/[email protected] KerberosApp.trace: [18330] 1395683780.742066: Retrieving [email protected] -> HTTP\/ homepage.example.com/example.com@ from FILE:/etc/local/kerberos/ccache/krb5cc with result: -1765328243/Matching credential not found Retrying [email protected] -> HTTP\/ homepage.example.com/[email protected] with result: -1765328243/Matching credential not found [18330] 1395683780.742475: Server has referral realm; starting with HTTP\/ homepage.example.com/[email protected] ---------------------------------------------------------------------------------------------------------------------- Could it be because session keys not being there in krb5cc file (I think authenticator is generated using session keys) ? Please advise what could be the problem here. Regards, Arpit On Wed, Mar 5, 2014 at 10:12 PM, Greg Hudson <[email protected]> wrote: > On 03/05/2014 10:55 AM, Arpit Srivastava wrote: > > That is the problem now. How to separate service tickets from the TGT so > > as to copy it (only) to the different cache ? It would be great if you > > can give some pointers. > > 1. Open the original ccache with krb5_cc_resolve. > 2. Retrieve the service cred with krb5_cc_retrieve_cred. > 3. Close the original ccache with krb5_cc_close. > 4. Open the new ccache with krb5_cc_resolve. > 5. Initialize the new ccache with krb5_cc_initialize. > 6. Store the previously obtained cred with krb5_cc_store_cred. > 7. Close the new ccache with krb5_cc_close. > 8. Release the service cred with krb5_free_cred_contents. > > Documentation for these functions is at: > > http://web.mit.edu/kerberos/krb5-latest/doc/appdev/refs/api/index.html > > If you have to iterate over the source ccache to find the service ticket > because krb5_cc_retrieve_cred won't work for you, use > krb5_cc_start_seq_get, krb5_cc_next_cred, and krb5_cc_end_seq_get. > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
