2012. október 27., szombat

MIT Kerberos V and NFS4 on Ubuntu 12.04

Last time we solved the problem of LDAP based Kerberos login to our PCs (and as a "satellite project" we solved the synchronisation of the Kerberos, LDAP and Samba passwords). Today we make progress in solving the centrally stored home directory mount of the user logging in to a Linux workstation.
(Ez a cikk magyarul is olvasható)
First we work on the server:
sudo mkdir -p /export/home
We add a new line to the file /etc/fstab :
/home    /export/home   none    bind  0  0
Make it happen:
sudo mount -a
So we preapred the directory our NFS4 server will export.

Let us install the server side components of NFS4:
sudo apt-get install nfs-kernel-server nfs-common
Write a new file called /etc/exports:
/export gss/krb5(rw,fsid=0,no_subtree_check,async,root_squash)
/export/home gss/krb5(rw,no_subtree_check,async,root_squash)
Later you should read man nfs, so you can decide whether you want to replace krb5 with krb5i or krb5p .

Modify the file /etc/default/nfs-kernel-server :
NEED_SVCGSSD=yes
Restart the NFS server:
sudo service nfs-kernel-server restart
Check if everything is okay with the exports:
sudo exportfs -v
A mount check (chek if the mount is high enough) (yes, here on the server, you mount back the directories you've just exported):
sudo mount -t nfs4 -o sec=krb5 ubuserver.itthon.cucc:/home/ /mnt
No-no. Syslog says:
ubuserver kernel: [  198.204101] RPC: AUTH_GSS upcall timed out.
ubuserver kernel: [  198.204104] Please check user daemon is running.
Le us try and help it:
sudo service gssd start
gssd stop/post-stop, process 3061
As the italic text makes it clear it does not work. Edit the file /etc/default/nfs-common :
NEED_GSSD=yes
Maybe now:
sudo service gssd start
gssd start/running, process 3078
Now the GSSD does run. Retry:
sudo mount -t nfs4 -o sec=krb5 ubuserver.itthon.cucc:/home/ /mnt
mount.nfs4: access denied by server while mounting ubuserver.itthon.cucc:/home/
Italic brings bad news again:) And what does our favorite syslog say?:
ubuserver rpc.gssd[3591]: ERROR: Key table file '/etc/krb5.keytab' not found while beginning keytab scan for keytab 'FILE:/etc/krb5.keytab'
 rpc.gssd[3591]: last message repeated 2 times
ubuserver rpc.gssd[3591]: ERROR: gssd_refresh_krb5_machine_credential: no usable keytab entry found in keytab /etc/krb5.keytab for connection with host ubuserver.itthon.cucc
ubuserver rpc.gssd[3591]: ERROR: No credentials found for connection to server ubuserver.itthon.cucc
Let us do something about that. Create a Kerberos-principal. Like man rpc.gssd says it could be something else but we are old-fashioned and choose the nfs/szerver-fqdn (Fully Qualified Domain Name) scheme, since it does not bring any good leaving the tried pathways (and all the sources on the Internet do this like that and that's the way it is). Bold are the commands we issue:
sudo kadmin.local 
Authenticating as principal root/admin@ITTHON.CUCC with password.
kadmin.local:  addprinc -randkey nfs/ubuserver.itthon.cucc
WARNING: no policy specified for nfs/ubuserver.itthon.cucc@ITTHON.CUCC; defaulting to no policy
Principal "nfs/ubuserver.itthon.cucc@ITTHON.CUCC" created.
kadmin.local:  ktadd nfs/ubuserver.itthon.cucc
Entry for principal nfs/ubuserver.itthon.cucc with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal nfs/ubuserver.itthon.cucc with kvno 2, encryption type arcfour-hmac added to keytab FILE:/etc/krb5.keytab.
Entry for principal nfs/ubuserver.itthon.cucc with kvno 2, encryption type des3-cbc-sha1 added to keytab FILE:/etc/krb5.keytab.
Entry for principal nfs/ubuserver.itthon.cucc with kvno 2, encryption type des-cbc-crc added to keytab FILE:/etc/krb5.keytab.
kadmin.local:  quit
Re-issuing the mount you find above the reult is the same but there is nothing in the syslog. Well...:
sudo service nfs-kernel-server restart
And now it is all right! Check:
sudo ls -l /mnt
You should see that the owners and groups of the files are okay. If I understand at leas for some extent what I am doing then on the server they have no chance to be incorrect but this is a computer and therefore unreliable...

Walk over onto the client.
sudo apt-get install nfs-common
Edit the file /etc/default/nfs-common like on the server and
sudo service gssd start
Now:
sudo mount -t nfs4 -o sec=krb5 ubuserver.itthon.cucc:/home/ /mnt
Usual error message, usual  syslog entries. We need to create a kerberos-principal  for the client too and the key goes to the keytab. If you had set up a Kerberos admin user then follow the floowing guidelines:). If you have not then you have the perils of working on the server using kadmin.local and export the keys to a separate file which you have to transfer to the client by some means. I am luck to have a Kerberos admin user (called kerbadmin/admin ) so I can stay on the client.
Instead of using kadmin -p kerbadmin/admin you should use
sudo kadmin -p kerbadmin/admin
or else you will not be able to write into the keytab file of  the client. Bold is what we say. Note that we are using the FQDN of the client:
Authenticating as principal kerbadmin/admin with password.
Password for kerbadmin/admin@ITTHON.CUCC: 
kadmin:  addprinc -randkey nfs/ubuclient.itthon.cucc
WARNING: no policy specified for nfs/ubuclient.itthon.cucc@ITTHON.CUCC; defaulting to no policy
Principal "nfs/ubuclient.itthon.cucc@ITTHON.CUCC" created.
kadmin:  ktadd nfs/ubuclient.itthon.cucc
Entry for principal nfs/ubuclient.itthon.cucc with kvno 3, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal nfs/ubuclient.itthon.cucc with kvno 3, encryption type arcfour-hmac added to keytab FILE:/etc/krb5.keytab.
Entry for principal nfs/ubuclient.itthon.cucc with kvno 3, encryption type des3-cbc-sha1 added to keytab FILE:/etc/krb5.keytab.
Entry for principal nfs/ubuclient.itthon.cucc with kvno 3, encryption type des-cbc-crc added to keytab FILE:/etc/krb5.keytab.
kadmin: quit
Using the mount command form above everything seems to work well. But the command
sudo ls -l /mnt
by chance will say that all files belong to nobody nogroup. Grrr. The syslog is filled with lines like these:
ubuclient rpc.idmapd[2325]: nss_getpwnam: name 'root@itthon.cucc' does not map into domain 'localdomain'
Edit the file /etc/idmapd.conf :
Domain = itthon.cucc
And now a
sudo service idmapd restart
And by now the files found on the server but having an owner with no Kerberos-identity we still get  nobody, nogroup and the syslog says:
rpc.idmapd[2394]: nss_getpwnam: name 'localuser1' not found in domain 'itthon.cucc'
But the rest is okay. I mean after a remount.

So that is ready.

Next time we manage to let the users' home directories automount on logon. Not to forget that this was one of our aims we started working on Kerberos-auth.

Further reading:
http://wiki.debian.org/NFS/Kerberos
http://www.opinsys.fi/en/setting-up-nfsv4kerberos-on-ubuntu-10-04-alpha-2-lucid-part-6 http://www.danbishop.org/2011/10/29/ubuntu-11-10-sbs-small-business-server-setup-part-1-%E2%80%93-dhcp-and-dns/5/#part-5-nfs

Nincsenek megjegyzések: