1

I'm setting up NFS with Kerberos and following various guides, like NFSv4 with Kerberos on Ubuntu Wiki and How To Use Kerberos to Control Access to NFS Network Shares, amongst others. All guides follow the same basic pattern:

  • Set up a KDC
  • Create a key-based principal for nfs/nfs-server and make sure that these keys are in the /etc/krb5.keytab file of the NFS server
  • Create a key-based principal for nfs/nfs-client and make sure that these keys are in the /etc/krb5.keytab file of the NFS client

The next step is what's confusing me. Once /etc/exports on the NFS server is changed to some variation of...

/nfs/some-dir    [ip-address](rw,sec=krb5p,all_squash,sync)

... how does the NFS server know which Kerberos principal has been assigned to itself? Even more basic - how does the NFS server know which Kerberos realm is has been added to? Further, how does the NFS server know which Kerberos principals to allow access to? There could be a number of Kerberos users/principals in the realm and not all should be allowed access to a particular NFS export.

In a similar vein, once the following is executed on the NFS client...

mount -t nfs4 -o sec=krb5p [ip-address]:/nfs/some-dir /mnt/some-dir

...how does the NFS client know which Kerberos principal/key to use when talking to the NFS server?

Is there some implicit magic going on in the /etc/krb5.keytab and /etc/krb5.conf files?

Saurabh Nanda
  • 449
  • 1
  • 7
  • 17

1 Answers1

1

There are couple of discovery options used by kerberized NFS (of in general any kerberized service) to find out which kerberos realm to use. The number one place is /etc/krb5.conf where you can explicitly specify default realm to be used:

[libdefaults]
...
default_realm = YOUR.REALM

If nothing is specified, then client can query DNS server for kerberos service record. At the end, the domain name is used. The NFS server will scan /etc/krb5.keytab file for appropriate host principal to use for gss handshake.

When end-users accessing NFS server, for each client a dedicated GSS context is established. On the server side, you need a mapping service, typically nfsidmapd, which based on system configuration uses LDAP server of local password file to map kerberos principals to local uid/gids. The authorization happens based on unix permissions or ACLs, if configured.

kofemann
  • 4,308
  • 1
  • 21
  • 27
  • wow - this seems way more complicated than I originally thought! I guess, I'll have to give-up on Kerberos and simply go with IP-based NFS restrictions. – Saurabh Nanda Jan 02 '19 at 12:16