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