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.




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

On Thu, 2017-05-04 at 18:02 +0200, Christopher Lamb wrote:
> 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.

> 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).


Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to