How can I set up centralized home directories and user authentication using LDAP and NFS?

Question

I am trying to configure my server to authenticate users using LDAP and save their home directories on a NFS-Directory, also located on the server.

i.e.: I share a directory on my server:

/nfsexport      10.0.2.0/24(rw,async,no_subtree_check,fsid=0,crossmnt)\
            *.em(rw,async,no_subtree_check,fsid=0,crossmnt)
/nfsexport/homes    10.0.2.0/24(rw,async,no_subtree_check)\
            *.em(rw,async,no_subtree_check)

mount it on my client by editing /etc/fstab:

server1:/homes      /home/users nfs4    bg  0   0

and append at the end of the files /etc/pam.d/login and /etc/pam.d/lightdm following line:

session required pam_mkhomedir.so skel=/etc/skel umask=0022

Now the home directory should be created at login under /home/users/ldapuser. But I cannot login and there is no home directory created on the server. I tried following approaches:

1. Create the home directory locally and not on the NFS. It works, owner and group are correct. But it is not centralized.
2. Change the permissions of /home/users on the server to 777. It works also with NFS, but it is not the optimal solution... I also tried to change the permission afterwards to 755, but then the user cannot write on his home directory because the owner and group are set to nobody and nogroup

So how can I make openLDAP automatically create home directories under /home/users with the according user- and group-ownership at first login? Or at least change it afterwards, after first logging in, while the rights are changed to 777?

Or: Is there an alternative method to have centralized home directories and user authentication?

Solution

This is a problem with user identification in the NFS protocol. How that works depends on which version of NFS you're using.

In NFSv3, user names and passwords are not part of the protocol; instead, the UID and GID numbers are. If a user with UID=1000 on machine a is called bart, and a user with the same uid on machine b is called homer, then bart can read files created by user homer on machine b. This is one reason why UID synchronisation is generally a good idea when using NFS.

However, NFSv4 changed much of this. Rather than just UID numbers, in NFSv4 the user and group name are sent over the wire. In order for this to work properly, the NFSv4 protocol changed several things significantly:

• The protocol requires that all user names exist on all machines. That is, if the client has a user bart, the server must also have a user bart (their UIDs may differ). If either one of them lacks the said user, then things will fall back to the nobody and/or nogroup user and group.
• The protocol has a concept of a "domain". This is by default based on the domain name (i.e., the FQDN of the machine on which you're running, minus the host name), but can be an arbitrary string. Domains are used to separate machines that have different sets of users. If the domain on the client does not match the domain on the server, then the system assumes that user bart on machine a is a completely different bart from the one on machine b.

For more details, read the rpc.idmapd(8) man page (which documents the Linux implementation of the ID mapping protocol).

Until recently, most Linux distributions used to default to NFSv3 if you did not explicitly request otherwise. Since a few years, however, the defaults are changing to NFSv4.

To get things to work, you have two options:

1. Revert to NFSv3. You can do this by way of the nfsvers=3 mount option.
2. Figure out why rpc.idmapd isn't doing what you expect, and fiddle with it until it does.

The path of least resistance is, clearly, 1. However, NFSv4 does have a number of useful features over the feature set of NFSv3, and you would lose those by ditching it.