freeipa-client not receiving kerberos ticket for NFS home directories

[Philippe Clérié]

- freeipa-client 4.7.0~pre1+git20180411-2ubuntu2
- ubuntu 18.04 fully updated
- freeipa-server 4.6.4 10.el7.centos.3
- home directory is on Debian NFS server. The NFS server is a member of the IPA domain.
- home directory is automounted from automount definition on IPA domain.
- IPA automount key: * : -fstype=nfs4,nfsvers=4.2,sec=krb5,rw,sync alioth.logisys.ht:/users/&

The following is what I am observing. I can't be sure it's replicable. I mean it happens on my network but I have yet to see a similar description on Google.

- Turn on the client machine. Login. Work.

- At this point, klist will show 2 kerberos tickets:

Default principal: <email address hidden>

Valid starting Expires Service principal
09/10/2019 06:44:26 09/11/2019 06:44:26 <email address hidden>
09/10/2019 06:44:27 09/11/2019 06:44:27 <email address hidden>

- Logout.

- Login as admin user, then issue:

sudo -u philippe klist

for the same result as above.

- After a few hours, login.

- The login is successful but my home directory is unreachable and not mounted.

- Logout and login again as an admin user, then issue:

sudo -u philippe klist

Default principal: <email address hidden>

Valid starting Expires Service principal
09/10/2019 11:54:32 09/11/2019 11:54:32 <email address hidden>

There is no ticket for the NFS server. I have verified that those tickets are issued with 24 hours validity. The tickets are supposedly not destroyed by the system in case the user has CRON jobs to run. So the NFS ticket is expired by the system but the TGT is kept around. My expectations would be on that login, the client would request a new NFS ticket. I think it does but the server denies it.

What I have tried:

- kdestroy on logout does not work. A new login will not connect to the home directory.
- Restart autofs, sssd, kerberos on the client.
- I changed the Kerberos keyring location on the client to a FILE.
- Between logins, restart the NFS server processes.
- Between logins, reboot the NFS server.
- Between logins, reboot the IPA server (including the backup).

So far the only thing that works reliably is rebooting the client machine.

Please note that as far as I can tell, the absence of the NFS ticket may not be an issue. It's just that it's too much of a coincidence. But I don't know nearly enough about kerberos and sssd to dive in that rabbit hole.

I hope this is clear enough. Anyway, just holler for more info.

Thanks in advance,
Philippe

[Timo Aaltonen (tjaalton)]

should be rpc.gssd responsible for that

[Philippe Clérié (pclerie)]

Following up on the move to nfs-utils I am attaching a tar with partial logs of both client and server, filtered on rpc.gssd, nfsidmap, automount on the client side, and rpc.svcgssd, rpc.idmapd on the server side.

The main takeaway at this stage is that every successful mount is associated with some log lines from nfsimapd on the client and from rpc.idmapd on the server. These lines are conspicuously absent for unsuccessful mounts.

For context:

(Note: user 131 is GMD and user 1000 is ladmin, the host admin user)

@15:17:35 A reboot is in progress
@15:17:48 A successful mount after two consecutive failures.
@15:19:47 4 user home directories are mounted. None of the uses are logged in by the way.
@15:26:02 automount expires 4 user home directories.
@15:26:51 User philippe logs in and home directory is successfully mounted.
@15:25:52 automount attempts to mount home directory of user (offline) sarah and succeeds.
-15:33 My notes show I logged out at that time.
@15:38:34 /users/{philippe,sarah} are expired.
@16:05:29 /users/{philippe,sarah} are mounted. Neither user logged in.
@17:38:04 Attempt to mount /users/{philippe,sarah} fails. So does every subsequent attempt.

From 18:12 on to the next day 05:46 no attempts to mount were made. I am pretty sure I logged out around that 18:12 yesterday, and I'm quite sure I logged in @05:45 this morning. But that's another story. Anyway, I don't see any sign of something that changed.

Looking at the server side logs, there too, I see no indication of a problem that could explain the behavior I'm observing.

Hope that helps someone come up with a hint.

Best
Philippe

[Philippe Clérié (pclerie)]

Please close.

I can't reliably reproduce this bug nor can I find what's cause it. And it does not seem to be a problem for anyone. So we might as well close it.