Strange (klist) behaviour

[Kevin Coffman]

2011/5/26 Greg Hudson <ghudson at mit.edu>:
> On Thu, 2011-05-26 at 04:58 -0400, Bjørge Solli wrote:
>> I have a situation when testing our brand new NetApp (NAS) as NFS4+krb5
>> home dirs. Tickets from our KDC dissapears, but seems to have no affect
>> on usage, and then appears again by itself after some time. We don't do
>> anything active to get the ticket back, but I gather something is
>> triggering it. The strange thing is that I was expecting the lack of
>> ticket to shut the user out from his home dir.
>
> Everything other than the krbtgt ticket is just a performance
> optimization; service tickets are obtained from the KDC when necessary.
> The lack of a service ticket in the ccache does not generally result in
> denial of service.
>
> I suspect the service ticket is "disappearing" when tickets are obtained
> or renewed, and reappearing when rpc.gssd needs to establish a new
> security context with the NFS server.  I can't say for sure, though.

[Assuming the NFS client is Linux.] This is pretty accurate.

The service ticket in the credentials cache is created as necessary
when rpc.gssd is asked by the kernel to negotiate a new context with
the NFS server.  After the context is created (in user space), it is
transferred to the kernel.  The kernel caches the context and keeps
using it regardless of whether the user does a kdestroy.  I believe
the NetApp server throws out its cached contexts every 10 minutes or
so (I may be mis-remembering that).  When it does that, the next
access of NFS on the client will trigger the Linux kernel to ask
rpc.gssd to negotiate a new context.  As long as credentials with a
valid TGT are available, a new service ticket will be obtained (if
necessary) and a new context is created.

Let me know if you have any other questions.

K.C.