In this article, we will talk about how we evaluate client fencing for Server for NFS role in Windows Server 2012, from targeting client permission to calculating combined permission result. We will also cover the caching strategy we implemented and lookup mechanism for netgroups. Lookup data are located in local cache, Network Information Service (NIS), Lightweight Directory Access Protocol (LDAP) store, Active Directory Domain Services (AD DS), Active Directory Light Weight Directory Services (AD LDS) or any third party LDAP store.  

Client Fencing Setup

A Server for NFS share is a share that is exported by the Windows Server 2012. It contains information like share name and share path. Here is a sample of an NFS share named “share” by running PowerShell cmdlet Get-NfsShare:

The result may look like below (Figure 1):

Figure 1

Client fencing is a mechanism which authorizes access rights of a machine (we call it a host or remote host) or a group of machines for this share. Server for NFS supports two types of groups:

• clientgroup: Set of client machines as a group which is configured locally on the NFS server, and they all have similar permissions.
• netgroup: Set of client machines as a group configured on NIS or LDAP, makes configuration accessible across servers and platforms within same subnet. A netgroup is identified by its full qualified domain name (FQDN).

Client fencing is evaluated by means of calculating set of client permissions for this particular share. A particular client permission defines the read/write access right of a client (a host or a group of hosts). Moreover, it contains information about whether users of client can act as a Linux root user, i.e. be assigned administrator privilege (controlled by AllowRootAccess field) and what is the language encoding of this client. PowerShell cmdlet Get-NfsSharePermission shows the share permission settings of a share:

The result may look like below (Figure 2).

Figure 2

In the example above, share named “share” is configured with

• an individual host permission (machine with IP 10.123.180.162) to allow read/write permission and root access,
• a clientgroup permission (for client group “ClientGroup”) to allow read/write permission,
• a netgroup permission (for netgroup “Group1”) to allow only read permission,
• and deny all other machine access by configures “All Machines” permission to deny access.

Windows NFS server provides several tools to configure client fencing. In this document, we will demonstrate three of them: NFS management UI, PowerShell cmdlet, and NFS command line tools.  This can best be accomplished by way of a simple example. In the following section, we will configure the “read” permission of a share following infrastructure scenario:

• Client (FQDN: nfsclient.contoso.com)
• Windows server 2012 running Server for NFS (FQDN: nfsserver.contoso.com)
• Server for NFS share (export path: “NFSSERVER:/share”)

NFS management UI

From server manager on NFS server choose share “share” from a list of shares from “File and Storage Services” tab, then right click it and select properties to open share Properties. Then choose Share Permissions and click Add button. A pop-up window will show up as in Figure 3 below:

Figure 3

We select the Host radio button and type in the host name (or IP address) of the client and then select Read Only share permission. Click Add button to add permission for this share. Note that configuring netgroup or clientgroup instead of hosts follows the same UI. Just select “Netgroup” or “Client group” radio button instead of Host to add permission for Netgroup or client groups.

PowerShell cmdlet

Server for NFS implemented a collection of PowerShell cmdlets to manage Server for NFS shares.

• Grant-NfsSharePermission: Grant a particular permission to a Server for NFS share
• Get-NfsSharePermission: Retrieve the permissions that have been configured for a given Server for NFS share
• Revoke-NfsSharePermission: Revoke existing permissions that have been granted to a Server for NFS share

Server for NFS PowerShell cmdlet should be loaded when Server for NFS role is enabled. Type the following command to grant read permission for the client:

NFS command line tools

NFS command line tools use existing WMIv2 provider that ships with Windows server 2012. We can use nfsshare.exe executable to manage Server for NFS shares. For granting share permission, run following command from command prompt:

More options can be set to list current share permissions as well as revoke previous assigned permissions. Details of this tool can be found using the URL: http://msdn.microsoft.com/en-us/library/cc753529.

Client Fencing Evaluation

When a host sends a request to a Server for NFS share, Windows Server 2012 will evaluate the client permissions of this host on this share, following steps shown in Figure 4.

Figure 4

Server will first check whether client individual host permission of this share includes this incoming host. This task parses Server for NFS share’s individual host permission list and looks for a match. If it succeeds, the matching individual host permission is returned. Otherwise, server will check clientgroup permission configured for this Server for NFS share. Given IP address of this host, server looks through local client group list and finds any client group this host belongs to.  Permissions from all hit clientgroups are combined and then returned.  Note that, we only support IPv4 address as input of clientgroup lookup. All IPv6 addresses are treated as not match. If neither individual host permission nor clientgroup finds a match, we give it another try by searching all netgroups this host belongs to and comparing with netgroup list of this share. For performance consideration, we cache netgroup per host data to avoid frequently downloading netgroup data from NIS or LDAP. I will talk about our caching strategy in latter section. Given a list of netgroups this host belongs to, we query existing setup for any of them in this share and return the permission of the first matching netgroup. If none of previous steps finds an eligible permission setting, we return the global permission of this NFS share as the permission of this host.

Caching Strategy

In Server for NFS implementation, we cache netgroup per host for the purpose of looking up netgroup permissions for a particular remote host machine. It is a first-in-first-out (FIFO) queue of remote hosts and each host maintains a list of netgroups this host belongs to.

When querying netgroup permission for a given host, we first look through the netgroup per host cache. During cache miss (or) cache expiration conditions, the cache is updated by querying and downloading data from NIS or LDAP We keep netgroup per host cache up-to-date by setting a creation time stamp and an expiration time for it. This expiration time can be configured through PowerShell cmdlet. Here is an example to configure cache timeout to be 30 seconds.

Format Issue for Netgroup Lookup

Before doing the query for netgroup, the IP address of the host we are looking for will be translated into FQDN via reverse DNS lookup. If it fails to find one, the lookup mechanism will look for the corresponding entry with KEY as "*.*" for wildcard group. We then query NIS or LDAP for netgroups given FQDN. Depending different NIS Configuration (domain field in /etc/netgroup), the format of netgroup by host data might be the one of the followings:

We will try both to see if it matches.

Feedback

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