Windows Server Summit 2024
Mar 26 2024 08:00 AM - Mar 28 2024 03:30 PM (PDT)
Microsoft Tech Community
LIVE
How to: NFS Kerberos Configuration with Linux Client
Published Apr 10 2019 02:46 AM 23.6K Views
Iron Contributor
First published on TECHNET on Oct 08, 2012

In this tutorial, we will provision NFS server provided by “Server for NFS” role in Windows Server 2012 for use with Linux based client with Kerberos security with RPCSEC_GSS.


Background


Traditionally NFS clients and servers use AUTH_SYS security. This essentially allows the clients to send authentication information by specifying the UID/GID of the UNIX user to an NFS Server. Each NFS request has the UID/GID of the UNIX user specified in the incoming request. This method of authentication provides minimal security as the client can spoof the request by specifying the UID/GID of a different user. This method of authentication is also vulnerable to tampering of the NFS request by some third party between the client and server on the network.


RPCSEC_GSS provides a generic mechanism to use multiple security mechanisms with ONCRPC on which NFS requests are built (GSS mechanism is described in RFC 2203 ). It introduces three levels of security service: None (authentication at the RPC level), Integrity (protects the NFS payload from tampering), and Privacy (encrypts the entire NFS payload which protects the whole content from eavesdropping).


Server for NFS server role (can be found within server role “File And Storage Services” under path “File And Storage Services /File and iSCSI Services/Server for NFS”) provides NFS server functionality that ships with Windows Server 2012. Server for NFS supports RPCSEC_GSS with Kerberos authentication, including all three levels of RPCSEC_GSS security service: krb5 (for RPCSEC_GSS None), krb5i (for RPCSEC_GSS Integrity), and krb5p (for RPCSEC_GSS Privacy) respectively.


Explaining how to set up Kerberos security between a Linux client and a Windows server running Server for NFS can best be accomplished by way of a simple example. In this tutorial we'll consider the following infrastructure scenario:



  • Windows domain called CONTOSO.COM running Active Directory on a domain controller (DC) named contoso-dc.contoso.com.

  • Windows server running Server for NFS with host name: windowsnfsserver. contoso.com

  • Linux client machine running Fedora 16 with host name: linuxclient. contoso.com

  • Linux user on Fedora 16 client machine: linuxuser

  • Windows user that mapped Linux user on Fedora 16 client machine: CONTOSO\linuxclientuser-nfs

  • Kerberos encryption: AES256-CTS-HMAC-SHA1-96


For the purpose of configuration, we assume that the Linux client is running Fedora 16 with kernel version 3.3.1. Windows server is running Windows Server 2012 with server for NFS role installed. DC is running Windows Server 2012 with DNS Manager, Active Directory Administrative Center and “setspn” command line tool installed.


Configuration Steps


In this section, we will go through 3 steps for the purpose of enable NFS with Kerberos authentication:



  1. Basics

  2. Set up Linux machine with Kerberos authentication.

  3. Provision NFS share on Windows Server 2012 with Kerberos authentication.


In step 1, we are going to check DNS and make sure that both NFS and RPCGSS are installed on Linux machine. In step 2, we are going to set up the Linux machine to join Windows domain.  After that, we will configure service principal name (SPN) for Kerberos and distribute SPN generated key to Linux machine for authentication.


Step 1: Basics


First, make sure that DNS name resolution is working properly using between the DC, the Windows NFS Server, and the Linux client. One caveat for the Linux client is that the hostname should be set to its fully qualified domain name (FQDN) in the Windows domain. Running “hostname” on Linux machine and check whether host name is correct. (In command boxes, bold text is the command we type in and its result shows in normal style without bold.):




[root@linuclient]# hostname


linuxclient.contoso.com





Details of setting hostname for Fedora 16 machine can be found in Fedora 16 Doc with URL: http://docs.fedoraproject.org/en-US/Fedora/16/html/System_Administrators_Guide/ch-The_sysconfig... .


Also make sure that NFS and RPCGSS module are successfully installed and started up in this Linux machine. Following example shows how to use “yum” patching tool to install NFS on Fedora 16 client machine:





[root@linuxclient]# yum install nfs-utils






and load Kerberos 5 by run:






[root@linuxclient]# modprobe rpcsec_gss_krb5







and start rpcgss service by run:







[root@linuxclient]# rpc.gssd start










Step 2: Set up Linux machine with Kerberos authentication


Step 2.1: Add Linux machine to DNS in DC


In this step, we need to log into the DC and add an entry to the DNS Manager as follows:




Figure 1


The IP address of Linux client can be found by running “ifconfig” command in Linux terminal. In our case, we stick to Ipv4 address, the IP address of our Linux client machine is “10.123.180.146”.


Reverse DNS mapping can be verified by command “dig –x 10.123.180.146” from Linux side, where “10.123.180.146” should be replaced with the actual IP address of your Linux machine. DNS settings may need time to propagating among DNS servers. Please wait a while until dig command returns the right answer.


Step 2.2: Join Linux machine to the domain


Now we're going to configure Linux client to get Kerberos tickets from the Windows domain it is going to join (in our case “CONTOSO.COM”). This is done by editing the “/etc/krb5.conf” file. There should be an existing file with some placeholders which can be edited. We're going to add two lines under “[libdefaults]” for “default_realm” and “default_tkt_enctypes”. We're also going to add a realm in “[realms]” filling in the following fields: “kdc”, “admin_server”. Moreover, we are going to add two lines in the “[domain_realm]” section.


The end result should look something like (text we added is marked in Italic ):









[libdefaults]


default_realm = CONTOSO.COM


dns_lookup_realm = false


dns_lookup_kdc = false


ticket_lifetime = 24h


renew_lifetime = 7d


forwardable = true


default_tkt_enctypes = aes256-cts-hmac-sha1-96



[realms]


CONTOSO.COM = {


kdc =
contoso-dc.contoso.com


admin_server = contoso-dc.contoso.com


}



[domain_realm]


.contoso.com = CONTOSO.COM


contoso.com = CONTOSO.COM









Step 2.3: Configure Kerberos service principal name


I'll explain a bit how authentication works from the NFS standpoint. When a Linux client wants to authenticate with Windows NFS server by Kerberos, it needs some other "user" (called a "service principal name" or SPN in Kerberos) to authenticate with. In other words, when a NFS share is mounted, the Linux client tries to authenticate itself with a particular SPN structured as “nfs/FQDN@domain_realm”, where “FQDN” is the fully qualified domain name of the NFS server and “domain_realm” is the domain where both Linux client and Windows NFS have already joined.


In our case, Linux client is going to look for “nfs/windowsnfsserver. contoso.com@CONTOSO.COM”. For this SPN, we're just going to create it and link it to the existing “machine” account of our NFS as an alias for that machine account. We run the “setspn” command from command prompt on DC to create SPN:








setspn –A nfs/windowsnfsserver windowsnfsserver


setspn –A nfs/windowsnfsserver.contoso.com windowsnfsserver









You can refer following articles to know more about SPN and “setspn” command.


http://msdn.microsoft.com/en-us/library/aa480609.aspx


User on Linux client will use the same style (i.e. nfs/FQDN@domain_realm where “FQDN” is the FQDN of the Linux client itself) as its own principal to authenticate with DC. In our case, principal for Linux client user is “nfs/linuxclient.contoso.com@CONTOSO.COM”. We're going to create some user in AD representing this principal, but “/” is not a valid character for AD account names and we cannot directly create an account which looks like “nfs/FQDN”. What we are going to do is to pick a different name as account and link it to that principal.  On DC, we create a new user account in Active Directory Administrative Center (Figure 2) and set up a link between this account and Kerberos SPN through “setspn” tool as we did for NFS server SPN.




Figure 2


In our case, both first name and full name are set to “linuxclientuser-nfs”. User UPN logon is “nfs/linuxclient.contoso.com@CONTOSO.COM”. User SamAccountName is set to contoso\linuxclientuser-nfs. Be sure to choose the correct encryption options, namely “Kerberos AES 256 bit encryption” and “Do not require Kerberos pre-authentication”, to make sure AES encryption works for GSS Kerberos. (Figure 3)




Figure 3


Now, we're going to set the SPNs on this account by running the following command in DC’s command prompt:









setspn –A nfs/linuxclient linuxclient-nfs


setspn –A nfs/linuxclient.contoso.com linuxclient-nfs










Fedora 16 Linux client needs to use the SPN without actually typing in a password for that account when doing mount operation. This is accomplished with a "keytab" file.


We're going to export keytab files for these accounts. On DC run following command from command prompt:









ktpass –princ nfs/linuxclient.contoso.com@CONTOSO.COM –mapuser linuxclientuser -nfs –pass [ITSPASSWORD] –crypto All –out nfs.keytab










“[ITSPASSWORD]” needs to be replaced by a real password chosen by us. Then copy nfs.keytab to Linux client machine. On Linux client machine we're going to merge these files in the keytab file. From the directory where the files were copied, we run "ktutil" to merge keytabs. In this interactive tool run the following commands:









[root@linuxclient]# ktutil


rkt nfs.keytab


wkt /etc/krb5.keytab


q










Great, now Linux client should be able to get tickets for this account without typing any passwords. Test this out:











kinit –k nfs/linuxclient.contoso.com











Note that Linux client will try three different SPNs (namely host/linuxclient, root/linuxclient, and nfs/linuxclinet) to connect to NFS server.  Fedora 16 will go through keytab file we generated from DC and find those SPNs one by one until the first valid SPN is found, so it is enough for us to just configure “nfs/linuxclient” principal. As a backup plan, you may try to configure other SPNs if “nfs/linuxclient” does not work.


Step 3: Provision NFS share on Windows Server 2012 with Kerberos authentication and Test NFS Kerberos v5 from Linux


Now we can create windows share with Kerberos v5 authentication and mount that share from Linux client. We can approach this by run PowerShell command:












New-NfsShare –Name share –Path C:\share –Authentication krb5,krb5i,krb5p -EnableAnonymousAccess 0 –EnableUnmappedAccess 0 –Permission readwrite













More details about how to setup NFS share could be found in blog post “Server for Network File System First Share End-to-End” at http://blogs.technet.com/b/filecab/archive/2012/10/08/server-for-network-file-system-first-shar... .


Now we are going to mount that share from Linux machine through NFS V4.1 protocol. On Linux client run:












[root@linuxclient]# mount –o sec=krb5,vers=4,minorversion=1 windowsnfsserver:/share  /mnt/share













In “sec” option, we can choose different quality of service (QOP) from “krb5”, “krb5i”, and “krb5p”. In “vers” option, we can choose to mount the share through NFS V2/3 protocol by replacing “vers=4,minorversion=1” to “vers=3” for NFSv3 or “vers=2” for NFSv2. In our case, “/mnt/share” is the mount point we choose for NFS share. You may modify it to meet your need.


After that, we can get access to mounted position from a normal linux client user by requiring the Kerberos ticket for that user. In our case, we run kinit from linuxuser user on Linux machine:













[linuxuser@linuxclient]# kinit nfs/linuxclient.contoso.com














Note that we do not need keytab to visit mounted directory, so we do not need to specify “-k” option for kinit. That linux user we run “kinit” should have privilege to read key tab file “krb5.keytab” under path “/etc”. All actions performed by linuxuser will then be treated as the domain user linuxclientuser-nfs on Windows NFS server.


Notes


RPCGSS Kerberos with privacy


RPCGSS Kerberos with privacy does not work with current release of Fedora 16 because of a bug reported here:


https://bugzilla.redhat.com/show_bug.cgi?id=796992


You can refer it to find the patch in Fedora patch database to make it work after they fix it.


NFS Kerberos with DES Encryption


Windows domain uses AES by default. If you choose to use DES encryption, you need to configure the whole domain with DES enabled. Here are two articles telling you how to do that:


http://support.microsoft.com/kb/977321


http://support.microsoft.com/kb/961302/en-us


The Windows machine must also set the local security policy to allow all supported Kerberos security mechanisms. Here is an article talking about how to configure Windows for Kerberos Supported Encryption as well as what encryption types we have for Kerberos:


http://blogs.msdn.com/b/openspecification/archive/2011/05/31/windows-configurations-for-kerbero...


After enabling DES on domain/machines/accounts passwords on accounts must be reset to generate DES keys. After that, we can follow the same configuration steps in previous section to mount NFS share with Kerberos. There is one exception that we need to add one additional line to “[libdefaults]” section of “/etc/krb5.conf” to enable “weak crypto” just like DES:













allow_weak_crypto= true














Troubleshooting


DNS look up failure


DNS server need time to propagate Linux client host names, especially for complicate subnet with multi-layers of domains. We can do some trick by specifying DNS lookup server priority on Linux client by modifying /etc/resolv.conf:














# Generated by NetworkManager


domain contoso.com


search contoso.com


nameserver: your preferred DNS server IP















Kerberos does not work properly


The Linux kernel's implementation of rpcsec_gss depends on the user space daemon rpc.gssd to establish security contexts. If Linux fails to establish GSS context, this daemon is the first place for troubleshooting.


First, make sure that rpcsec_gss is running. Run “rpc.gssd –f –vvv”
















[root@linuxclient]# rpc.gssd –f –vvv


beginning poll


















Ideally, the terminal will be blocked and polling GSS requests. If it stops right after running that command, you’d better reboot Linux. rpc.gssd itself is also a source of debugging Kerberos context switch. It will print out result of each Kerberos authentication steps and their results.


NFS Access Denial


The most error message from mounting NFS share from Linux is access denial. Unfortunately, Linux terminal does not provide additional clue of what causes failure. Wireshark is a nice tool to decode NFS packets. We can use it to find out error code from server replay message of compounds.


Feedback


Please send feedback you might have to nfsfeed@microsoft.com

1 Comment
Version history
Last update:
‎Apr 10 2019 02:46 AM
Updated by: