3

I'm setting up kerberized NFSv4 for personal use

  • manually configured NFS, KDC
  • no nameservers (using /etc/hosts instead), no LDAP
  • same users on all machines (not necessarily the same id) and using id mapping for all security modes (nfs4_disable_idmapping set to 'N')

I've got two machines, both running Ubuntu 20.04 LTS

  • arhiv.pecar (local address 192.168.56.200) has the NFS server and the KDC
  • client.pecar (local address 192.158.56.100) is the client

All plumbing seems to work and I can mount the share just fine, but

  • if the share is exported with sec=sys

    server exportfs -v output

    /srv/export <world>(rw,async,wdelay,no_root_squash,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)

    client mount output

    arhiv.pecar:/srv/export on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=192.168.56.100,local_lock=none,addr=192.168.56.200)
    • root has full read / write access
    • other users can read / write files if sufficient privileges are set up
    • nfsidmap is active, listing files on the client properly translates usernames / groups
    • chown from client is possible, and properly translates usernames / groups

    Files are created under the uid/gid of the client, which means they are created with the wrong uid / gid on the server

    It gets mapped to the wrong owner if the server happens to have a user with the same uid, otherwise the owner is nobody:4294967294

    The effective user seems to be user specified by the clients uid.

    I suppose this is a known drawback when using sec=sys

  • if the share is exported with sec=krb5

    server exportfs -v output

    /srv/export <world>(rw,async,wdelay,no_root_squash,no_subtree_check,sec=krb5p:krb5,rw,secure,no_root_squash,no_all_squash)

    client mount output

    arhiv.pecar:/srv/export on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.56.100,local_lock=none,addr=192.168.56.200)
    • all users have read access, no user (including root) has write access on files / folders owned by them
    • creating files in o+w folders will create them under the anonymous user (nobody:nogroup or anonuid:anongid if specified in exports entry)
    • nfsidmap is active, listing files on the client properly translates usernames / groups
    • chown from client fails with Operation not permitted.

    The effective user seems to be the anonymous user.

I'm at a loss on what could be wrong here, so I'd appreciate the communities insight.

I can provide the relevant configuration files (/etc/hosts, /etc/krb5.conf, /etc/idmapd.conf, /etc/default/nfs-common, service, kernel module list) upon request.

Improve this question

2 Answers 2

Reset to default
5

Well, I've figured out that it's worthwhile to understand how NFS and Kerberos deal with users, and how principal names come to play here - topics that are frequently left out in most guides.

In kerberized NFS, one needs to be aware of the difference between

  • the effective user executing the file operation

    The effective (server-local) user of the file operation is determined by Kerberos' local authorization interface, which is configured via auth_to_local tag, and if none given, defaults to auth_to_local = DEFAULT, the operation for which is defined as

    The principal name will be used as the local user name. If the principal has more than one component or is not in the default realm, this rule is not applicable and the conversion will fail.

    In the case of conversion failure it assumes the anonymous user (nobody:nogroup or anonuid:anongid if specified in exports entry)

    Related discussion that provides a good explanation.

  • the parameters / results of this file operation

    When the NFS server performs the file operation

    1. parameters need to be mapped from client-provided users to server-local users (chown command)
    2. results need to be mapped back to client-local users (ls command)

    This is handled by the id_resolver upcall program specified in /etc/request-key.conf or /etc/request-key.d/* (usually nfsidmap).

    Usernames are transferred between hosts as user@dns_domain strings and are mapped to local uid/gid on each side.

The effective user performing the file operation is derived from the ticket (thus it matters under which principal we authentecate), and NOT from the uid of the locally running process requesting the file operation (which one might naively expect).

So, in order for the effective user mapping to work, one needs to create a username principal (effectively username@REALM) or, if a more complex principal name is used, provide an appropriate auth_to_local mapping in /etc/krb5.conf, as described here

Each user should have its own default principal (user/client-fqdn), which is used for mapping to server-local user.

Service principals are used & authorized by the services themselves and presumably there is no need for users to have access to them (they should be retained in /etc/krb5.keytab but not in user keytabs)

User keytab locaton varies between distributions - use krb5-config to figure out what is expected by your build

USER_KEYTAB=$(euid=$EUID; eval echo $(krb5-config --defcktname | tr % $ | sed 's/FILE://'))

Below is quick demo on how to properly configure mapping for a user over kerberized NFS.

The following configuration was tested on CentOS systems configured via this guide (guide intended for Centos 7, tested on 8, minor additions were needed)

https://www.linuxhelp.com/how-to-set-up-nfs-server-with-kerberos-based-authentication

# Start kadmin on client machine (I assume that you have the root/admin principal already set up) # [root@nfsclient ~]# kadmin -p root/admin Authenticating as principal root/admin with password. Password for root/[email protected]: kadmin: addprinc -randkey -clearpolicy host/nfsclient Principal "host/[email protected]" created. kadmin: addprinc -randkey -clearpolicy nfs/nfsclient Principal "nfs/[email protected]" created. kadmin: ktadd -k /tmp/krb5.keytab host/nfsclient Entry for principal host/nfsclient with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/krb5.keytab. ... kadmin: ktadd -k /tmp/krb5.keytab nfs/nfsclient Entry for principal nfs/nfsclient with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/krb5.keytab. ... kadmin: addprinc -randkey -clearpolicy testuser Principal "[email protected]" created. kadmin: ktadd -k /tmp/client.keytab testuser Entry for principal testuser with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/client.keytab. ... kadmin: quit # Set up the default keytab (service principals) [root@nfsclient ~]# mv /tmp/krb5.keytab /etc/krb5.keytab [root@nfsclient ~]# chown root:root /etc/krb5.keytab # Set up user keytab [root@nfsclient ~]# mv /tmp/client.keytab /var/kerberos/krb5/user/$(id -u testuser)/client.keytab [root@nfsclient ~]# chown testuser:testuser /var/kerberos/krb5/user/$(id -u testuser)/client.keytab # Mount the filesystem mount nfsserver.kdc.com:/kerberos /mnt # Test the user [root@nfsclient ~]# sudo -i -u testuser # Check that the users client.keytab, is being picked up # (can access nfs share) # # and that the correct effective user is now used for file operation # (derived from default principal and mapped to server-local user) # - the server should also have a `testuser` user # [testuser@nfsclient ~]$ touch /mnt/testfile [testuser@nfsclient ~]$ ls -la /mnt/testfile -rw-rw-r--. 1 testuser testuser 0 Jun 23 16:31 /mnt/testfile # After accesses one can check the keys that have been retrieved on [testuser@nfsclient ~]$ klist Ticket cache: KCM:1051:17737 Default principal: [email protected] Valid starting Expires Service principal 06/23/2021 16:06:12 06/24/2021 16:06:12 krbtgt/[email protected] renew until 06/23/2021 16:06:12 06/23/2021 16:06:12 06/24/2021 16:06:12 nfs/[email protected] renew until 06/23/2021 16:06:12
Improve this answer
1
0

One of the causes for this might be, for those authenticating with winbind, is the samba (smb.conf) configuration of winbind use default domain = no.

This default configuration makes authentication expect user names to appear with the DOMAIN\ prefix (ex: DOMAIN\alice).

See: https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#winbindusedefaultdomain

You should configure this parameter to yes (in both client and server) in order to be able to login simply as su - alice and not as su - DOMAIN\\alice.

The names nfs server will compare against kerberos tickets will be the shorter one. With the default longer version, gss fails to find the user and so squashes it to be "nobody".

As for the answer of @tpecar : Myself, I got the client keytab created properly with a simple kinit call by the user. Didn't need anything else.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.