Once we have Linux computers joined to AD domain and running, we can also enable Kerberized NFS, Let’s assume AD domain ‘EXAMPLE.COM’:
- On all computers enable ‘secure nfs’ – on RHEL-6 and older we do so in config file /etc/sysconfig/nfs (enable ‘SECURE=yes’), on RHEL-7 and newer enable nfs-client target (systemctl enable nfs.client)
- Make sure clock is in sync with Windows DC, also make sure Kerberos library is properly configured – but since we are running SSSD, this should be done already, anyway…
- On server additionally configure exports, i.e.:
/export *(rw,sec=sys:krb5:krb5i:krb5p)
- server needs NFS keytab (“net ads keytab add nfs”) – this populates ServicePrincipalName (SPN) computer attribute in AD
- Addionally load nfs server (“service nfs start” resp “systemctl enable nfs-server”)
- Servers running RH-6 or older can suffer from a nasty problem affecting users who are members of too many groups
- Verify all daemons (i.e. rpc.gssd on the client and rpc.svcgssd or gssproxy on the server) are running
- If your NFS server is Netapp NAS, configure Kerberos simply by running “nfs setup” wizard and select option 2 (use Microsoft KDC)
- If using NFSv4, make sure you have properly configured Idmapper (see file /etc/idmap.conf)
Now you have everything configured, you should be able to mount the share:
mount -o sec=krb5 server_name:/ /mnt
Important Note: On the NFS client, you actually need two TGT Kerberos principals:
- Machine principal – that’s the one stored in the system Kerberos database (usually /etc/krb5.keytab). In this database, we are interested in principal of form `hostname -s`$ – or, using AD syntax, it is the sAMAccountName attribute of the client machine in AD. This principal is needed to perform the mount of the remote filesystem.
- User principal – usually stored in user’s Kerberos cache – which is either a small file in /tmp (see the output of command klist) or kernel ring space. This ticket is actually prove of user’s identity – it enables him to actually access the mounted filesystem. Without a valid ticket, user is usually denied access to the mounted filesystem.
Troubleshooting
if you are unable to mount the share then:
- make sure it is Kerberos problem, i.e. you can mount with system authentication just fine
- make sure GSSD has a working principal to work with – the easiest test is to obtain a TGT using machine credentials (should return with no errors):
# kinit -k `hostname -s`$
- Make sure that your NFS server name is resolvable in DNS – including reverse DNS lookup. Note that newer systems running nfs-utils version 1.2.8 and newer (like RHEL-7) are not so picky regarding reverse DNS, If this is your case and you do not want to rely on reverse DNS, make sure you use FQDN in your mount command, i.e. “mount server.example.com:/vol/vol0 /mnt”
- In all cases the nfs server’s FQDN must exist in SPN attribute (see above), i.e. (“nfs/server.example.com”)
- If FQDN of your linux client and server box does not match the AD domain (i.e. for example server’s FQDN is “filer.unix.example.com”, not “filer.example.com”), you are not lost – you only have to add the correct SPN to the server manually using (for example) ADSI edit – so say you add “nfs/filer.unix.example.com” to the SPN list
- If you have reverse DNS configured, make sure just one PTR record is returned for the server. If DNS resolves multiple PTR records for your NFS server, rpc.gssd might fail miserably on the client.
It is also useful to enable debugging (run GSSD with argument -vvv).
Myths
DNS/rDNS records of the client machine are not so important. Make sure all records (see above) for the server are ok. Also, nowadays you do not have to enable weak_crypto in krb5 library. With modern kernel, Kerberized NFS will work even with strong ciphers.
ovalousek 