Thanks. That is actually one of the other instances I had trouble with a very similar type of experience. I felt I was constantly resetting gssproxy, rpc-gssd services but it would never automatically pick up the keytab. Left for the day and the very next day ran kinit to pick up where I left off and it had picked up they keytab and was showing it expires in like the year 2999.
Granted half the time I don't even know how to begin to "reproduce" the problem because it's so sporadic. I just constantly tweak, try to reset and start over, and eventually it ends up working. I never find the "root cause", it just magically starts working and it works until I have to update something and then rinse and repeat. Prime example: I dread touching our EMC Unity system with updates because without fail it always breaks the kerberos authentication, but we had to update it for patches this past week. We haven't touched this thing in 6+ months and it was working properly before the update. Literally no configuration to the LDAP/Kerberos settings. We simply uploaded the new updated OS and applied its patch. Sure enough after the reboot all of the Kerberos stuff is failing saying it can't reach the LDAP servers. Looking at the logs shows
```
1681140357: LDAP: 6: LdapService::connect: Connection to Ldap server X.X.X.X SUCCEEDED IP[0/1]=X.X.X.X port=389
1681140357: LDAP: 3: LdapGssAuthenticator::evaluate: gss_unwrap failed - GSS-API major error: A token had an invalid signature
1681140357: LDAP: 3: LdapGssAuthenticator::evaluate: gss_unwrap failed - GSS-API minor error: No error
```
I changed it from Kerberos authentication to "Simple" rather than Kerberos using a DN e.g. (uid=testuser,cn=users,cn=accounts,dc=example,dc=com). On Friday it kept failing on my client, with "mount.nfs4: access denied by server", (wouldn't even mount). Randomly tried it on a different client not changing a thing and that client mounted it successfully. Left on Friday, came back on Monday tried the mount and sure enough my client worked (I was kdestroying on my client, albeit wasn't restarting gssproxy or rpc-gssd but had restarted the machine that day after I changed it to Simple). Literally could see the last command I ran on Friday was the "mount" command and it failed, hit up on command prompt and ran it again, and it succeeded.
Most of the clients are Ubuntu, so I'm not sure if this has anything to do with their packages versus RH based distros and how they interoperate.
If kdestroy, gssproxy, rpc-gssd, sssd indeed are the _only_ things caching anything and a restart of those services should refresh those caches, the next time I set one of these systems up, I'm going to document what I can. I always dread making any changes to kerberos because of how temperamental it is. Are there any other services I should be looking at restarting/resetting when dealing with this topic?