The Storage Team Blog about file services and storage features in Windows and Windows Server.
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.
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):
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:
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).
In the example above, share named “share” is configured with
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:
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:
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.
Server for NFS implemented a collection of PowerShell cmdlets to manage Server for NFS shares.
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:
Grant-NfsSharePermission –Name share –Permission readonly –ClientName nfsclient.contoso.com –ClientType Host
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:
nfsshare share –o ro=nfsclient.contoso.com
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.
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.
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.
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.
Set-NfsServerConfiguration –NetgroupCacheTimeoutSec 30
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:
server.contoso domain1 domain2
server.contoso.* domain1 domain2
We will try both to see if it matches.
Please send feedback you might have to email@example.com