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.