On credential cache separation between service ticket and TGT

Arpit Srivastava arpit.orb at gmail.com
Mon Mar 24 14:23:50 EDT 2014


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/EXAMPLE.COM at EXAMPLE.COM
HTTP/homepage.example.com@
HTTP/homepage.example.com at EXAMPLE.COM

KerberosApp.trace:

[12780] 1395683631.292486: Retrieving user at EXAMPLE.COM -> 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 user at EXAMPLE.COM  ->
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/homepage.example.com at EXAMPLE.COM

KerberosApp.trace:

[18330] 1395683780.742066: Retrieving user at EXAMPLE.COM -> HTTP\/
homepage.example.com/example.com@ from
FILE:/etc/local/kerberos/ccache/krb5cc with result: -1765328243/Matching
credential not found
Retrying user at EXAMPLE.COM -> HTTP\/
homepage.example.com/example.com at EXAMPLE.COM with result:
-1765328243/Matching credential not found
[18330] 1395683780.742475: Server has referral realm; starting with  HTTP\/
homepage.example.com/example.com at EXAMPLE.COM

----------------------------------------------------------------------------------------------------------------------
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 <ghudson at mit.edu> 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.
>


More information about the Kerberos mailing list