NFSv4 with UCS 3.1

This howto is outdated. To mount NFS shares between UCS 4.x server instances please use the existing LDAP Policy, see also Univention Corporate Server.

Creation of a “virtual root” folder

NFSv4 needs a virtual root folder to export all other files and folders. You can create the folder with the command

mkdir /exports

Afterwards the root has to be entered into the “/etc/exports” configuration file by adding the following line:

/exports gss/krb5(rw,sync,fsid=0,insecure,crossmnt,no_subtree_check)

Adding a share

Multiple steps are needed to add a share, especially if you want to manage it using the UMC.

Inclusion of the Directory in the Exports Directory

In the first step you should link the share into your export directory. Therefore you should first create the target directory within your exports directory

mkdir /exports/<target>

Afterwards you need to add a link definition in “/etc/fstab” where you bind the original directory to the target directory in the exports folder:

/<original folder> /exports/<target> none bind 0 0

Afterwards the directory will be bound on every reboot. To bind it without a reboot you can issue the following command as root

mount /exports/<target>

Creating the share in the UMC

You should first create the NFSv3-Share in the respective UMC module which later will be turned into an NFSv4 share. The share should thereby be added with the original path “/”. Additionally you should restrict the access to the IP Adress 0.0.0.0/32. This ensures that no client can mount the NFSv3 share.

You only need this step, if you want to auto-mount the home folder using NFSv4. Otherwise you can also proceed manually.

Adding the share in NFSv4

There are 4 different encryption and authentication types supported by NFSv4 which are described below. From those one has to be chosen one and copy the respective line inside “/etc/exports”, without the comment in the end. Afterwards the line has to be edited according to the following:

Host based Authentication

Similar to NFSv3 host based authentication is also supported in NFSv4. For allowing all hosts add:

/exports/<target> *(rw,nohide,insecure,no_subtree_check,async)

For a specific host, here 10.10.10.10 or master.test.local, the export looks like the following. Please note that not all host client combinations support DNS based restrictions

/exports/<target> 10.10.10.10(rw,nohide,insecure,no_subtree_check,async)
/exports/<target 2> master.test.local(rw,nohide,insecure,no_subtree_check,async)

You can also offer access to your shares based on a subnet

/exports/<target> 10.0.0.0/8(rw,nohide,insecure,no_subtree_check,async)

IPv6 is possible in the same manner.

Kerberos Authentication

To authenticate the users using Kerberos use the gss/krb5 as security option. The result is the following

/exports/<target> gss/krb5(rw,nohide,insecure,no_subtree_check,async)

Data integrity

If you want to provide data integrity on top of Kerberos user authentication replace the security option with gss/krb5i, resulting in

/exports/<target> gss/krb5i(rw,nohide,insecure,no_subtree_check,async)

Encryption

The most secure but also most processor intensive security mechanism adds encryption on top of authentication and data integrity. If you are planning to use the storage for high volume throughput with possible many users it might be a good investment to by a dedicated appliance with hardware encryption support for NFSv4 and Kerberos. To create a share on a server cange the export line as the following:

/exports/<target> gss/krb5p(rw,nohide,insecure,no_subtree_check,async)

Kerberos Keys

The roll-out of the Kerberos keys differs for Samba 3 and Samba 4 Domains. When updating from Samba 3 to Samba 4 you will have to redo the Key creation.

Samba 4 Domain

Samba 4 has a different way of managing Service Principles in UCS 3.1 they can be managed using the samba-tools on any Samba DC.

samba-tool spn add nfs/<nfs-server or client host>.$(hostname -d)/$(hostname -d) <nfs-server or client host>\$

On the respective Servers you can then enlarge the keytab by the following comands:

kvno=$(ldapsearch -D $(ucr get ldap/hostdn) -w $(cat /etc/machine.secret ) -h $(ucr get ldap/master) cn=$(hostname) -p 7389 krb5KeyVersionNumber | grep krb5KeyVersionNumber: | cut -d" " -f2)
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e aes256-cts-hmac-sha1-96
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e aes128-cts-hmac-sha1-96
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e des-cbc-md5
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e des-cbc-crc

To automatically change the keys whenever the server changes its password create a file “/usr/lib/univention-server/server_password_change.d/nfs_keytab_change” with the following content:

#!/bin/bash
if [ "$1" = "postchange" ] ; then
kvno=$(ldapsearch -D $(ucr get ldap/hostdn) -w $(cat /etc/machine.secret ) -h $(ucr get ldap/master) cn=$(hostname) -p 7389 krb5KeyVersionNumber | grep krb5KeyVersionNumber: | cut -d" " -f2)
lkvno=$(($kvno - 1))
ktutil remove -V $lkvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e aes256-cts-hmac-sha1-96 >> /var/log/univention/server_password_change.log
ktutil remove -V $lkvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e aes128-cts-hmac-sha1-96 >> /var/log/univention/server_password_change.log
ktutil remove -V $lkvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e des-cbc-md5 >> /var/log/univention/server_password_change.log
ktutil remove -V $lkvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e des-cbc-crc >> /var/log/univention/server_password_change.log

ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e aes256-cts-hmac-sha1-96 >> /var/log/univention/server_password_change.log
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e aes128-cts-hmac-sha1-96 >> /var/log/univention/server_password_change.log
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e des-cbc-md5 >> /var/log/univention/server_password_change.log
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e des-cbc-crc >> /var/log/univention/server_password_change.log
fi

and make it excecutable

chmod +x /usr/lib/univention-server/server_password_change.d/nfs_keytab_change

Samba 3 - Heimdal Domain

In a Heimdal Kerberos Domain you first need to initialize the Password for the Kerberos administrative account kadmin/admin. Later you might want to change it back to a long random password as the account can modify all other passwords.

To change it use the following commands on your DC-Master

kadmin -l passwd
kadmin/admin
exit

On the DC Master you then have to create the Kerberos keys for each server and client:

kinit kadmin/admin 
kadmin add -r nfs/nfs-server.domain
kadmin add -r nfs/nfs-client1.domain

On the server you can then load the keys with the following

kinit kadmin/admin
ktutil get nfs/nfs-server.domain

and in the same manner on the client

kinit kadmin/admin
ktutil get nfs/nfs-client1.domain

Adapting the Configuration Files

On the NFS-Server open the UCR Template “/etc/univention/templates/files/etc/default/nfs-kernel-server” in your favorite editor and replace

NEED_SVCGSSD=

with

NEED_SVCGSSD=yes

and commit the file

ucr commit /etc/default/nfs-kernel-server

Likewise open the UCR Template “/etc/univention/templates/files/etc/default/nfs-common” and replace the lines:

NEED_IDMAPD= NEED_GSSD=

with

NEED_IDMAPD=yes NEED_GSSD=yes

respectively. If you also want to disable NFSv3 change

NEED_STATD=

to

NEED_STATD=no

Afterwards you can commit the changes to the real configuration files with the command

ucr commit /etc/default/nfs-common

From UCS 3.0 and above the following option needs to be set

ucr set nfs/nfsd/nfs4=true

Finally restart the server and common services on the NFS-Server

/etc/init.d/nfs-common restart
/etc/init.d/nfs-kernel-server restart

On the client repeat the changes by directly editing “/etc/default/nfs-common”.

Testing your setup

With the following command you can mount a directory using kerberos authentication. Please note that “sec=” should be the same as used in the exports file on the server, also ensure that you use the full domain name of the server not just the hostname.

mount -t nfs4 nfs-server.domain:/<nfs target> /<local target> -o sec=krb5

Note: If the mount command fails, make sure that “/sbin/mount.nfs4” is available on your client. If mount.nfs4 is missing, you can install it through nfs-common:

apt-get install nfs-common

After successfully mounting the share a user with a Kerberos Ticket should be able to access the directory. To obtain a Kerberos Ticket you can either login as a domain user or issue

kinit <Username>

as root. Please note that you will only be able to access directories the Kerberos user could access on the server themselves.

Automatic Mount

After a successful test you can automatically mount it using “/etc/fstab”. It is sufficient to add the following line to /etc/fstab:

nfs-server.domain:/<nfs target> /<local target> nfs4 sec=krb5 0 0

The above mentioned restrictions apply as well.

This topic was automatically closed after 24 hours. New replies are no longer allowed.

Mastodon