[Freeipa-users] Kerberos clients, service tickets, and client to KDC interaction

[Christopher Lamb]

Hi All

Is the following statement correct?

"If a kerberos client (e.g. a FreeIPA client) holds a service ticket to a
service principal in its credentials cache, it no longer needs to interact
with the KDC to access the service (assuming the ticket is still valid).
i.e. if a kerberos client is not caching service tickets, each interaction
with the service principal will require getting a new ticket from the KDC."

Are there logs on my FreeIPA-Server I can use to track ticket requests from
clients, and prove or disprove my statement above?

Cheers

Chris

[Simo Sorce]

Post by Christopher Lamb
Hi All
Is the following statement correct?
"If a kerberos client (e.g. a FreeIPA client) holds a service ticket
to a service principal in its credentials cache, it no longer needs
to interact with the KDC to access the service (assuming the ticket
is still valid). i.e. if a kerberos client is not caching service
tickets, each interaction with the service principal will require
getting a new ticket from the KDC."

Yes this statement is correct.

Post by Christopher Lamb
Are there logs on my FreeIPA-Server I can use to track ticket
requests from clients, and prove or disprove my statement above?

On each KDC you can check /var/log/krb5kdc.log which contains a log of
all requests received, if you have multiple IPa servers, you may need
to collect all server's logs to see a complete picture as a service may
request a ticket from any of the KDCs (although normally an ipa client
sticks to the same KDC via a locator plugin for libkrb5 and only falls
back to other KDCs if the preferred KDC is unreachable).

Simo.

[Christopher Lamb]

Hi Simo

Thanks, I was hoping you would throw your hat in the ring!

The background to the question, is that I have a throwaway Python Kerberos
Client using the GSS-API that caches service tickets, an a non-throwaway
Java Kerberos Client, also using the GSS-API that does not (yet) cache
service tickets. This implies the Java Client could be hammering the KDC
with requests. I should now be able to confirm this with
/var/log/krb5kdc.log on my KDC.

On the issue of the Java Client non-caching service tickets I posted a
Stack Overflow question last night.

http://stackoverflow.com/questions/43786908/java-gss-api-service-ticket-not-saved-in-credentials-cache-using-java

thanks

Chris



From: Simo Sorce <***@redhat.com>
To: Christopher Lamb/Switzerland/***@IBMCH,
freeipa-***@redhat.com
Date: 05/05/2017 11:40
Subject: Re: [Freeipa-users] Kerberos clients, service tickets, and
client to KDC interaction

Post by Christopher Lamb
Hi All
Is the following statement correct?
"If a kerberos client (e.g. a FreeIPA client) holds a service ticket
to a service principal in its credentials cache, it no longer needs
to interact with the KDC to access the service (assuming the ticket
is still valid). i.e. if a kerberos client is not caching service
tickets, each interaction with the service principal will require
getting a new ticket from the KDC."

Yes this statement is correct.

Post by Christopher Lamb
Are there logs on my FreeIPA-Server I can use to track ticket
requests from clients, and prove or disprove my statement above?

On each KDC you can check /var/log/krb5kdc.log which contains a log of
all requests received, if you have multiple IPa servers, you may need
to collect all server's logs to see a complete picture as a service may
request a ticket from any of the KDCs (although normally an ipa client
sticks to the same KDC via a locator plugin for libkrb5 and only falls
back to other KDCs if the preferred KDC is unreachable).

Simo.