CODEWITHSUNDEEP
kerberosnfsfreeipaautomountidm
Ravi OpenSource
Ravi OpenSource

Reputation: 71

why do we need to add a nfs principal for the client mounting the NFS?

To create a kerberized NFS server in an IDM/IPA environment, why do we need to add a nfs principal for the client mounting the NFS?

I am trying to setup a kerberized nfs server with a Dell unity NAS server as NFS device. Here are the steps we followed. :

  1. Create a nfs service principal on IDM/IPA (kinit admin; ipa service-add nfs/nfsserver.example.com)
  2. Download the nfs service keytab and uploaded to the DELL unity NAS device. configured the DELL unity box to share the file location with krb5p opton
  3. Log in to the client, do a kinit with admin, showmount -e nfs_server name shows the mount paths.
  4. Add the entries in the /etc/fstab for nfs with "vers=4" option. Mount works.
  5. We create folders inside the mount path with ACL entries for other users. The users even after doing a kinit with their names are not able to access the folders inside the mount path.
  6. Once we create a nfs service principal for the nfs client in IDM and add to the client keytab, the setup starts working. The question is why do we need a nfs client principal to be created and added to the client keytab. I had an understanding that service principal are needed only for the servers providing services.

Upvotes: 1

Views: 1109

Answers (1)

grawity_u1686
grawity_u1686

Reputation: 16612

Once we create a nfs service principal for the nfs client in IDM and add to the client keytab, the setup starts working. The question is why do we need a nfs client principal to be created and added to the client keytab. I had an understanding that service principal are needed only for the servers providing services.

Service principals can also act as client principals (machine-to-machine authentication). It's similar to mTLS with a client certificate.

In this case the keytab just acts as the client's "client" credentials for authenticating to the NFS server, as the mount is done before any real user credentials are available, so the "nfs/<client>" principal represents uid 0 (root) on the client system.

(On-demand mounts probably could be done with just user credentials – if those are available – but with NFSv4 there are also some state-management operations such as SETCLIENTID that are "system-wide" and require a machine principal.)

That being said, NFS doesn't require clients to use "nfs/<name>" principals – if your machine already happens to have a "host/<name>" service principal, at least the Linux rpc.gssd should be able to use that. (In fact see the rpc.gssd manual page for "Machine credentials".)

Upvotes: 2

Related Questions