- 1 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 2 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 3 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 4 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
- 5 Docker Reaches Across Universes at Dockercon EU
Win 2003 High Availability Solutions, NFS Share Implementation
In the previous installment of our series dedicated to Windows Server 2003 High Availability Solutions, we described cross-platform authentication mechanisms incorporated into Windows Services for Unix (focusing on the version included in Windows Server 2003 R2). The information we provided was necessary to introduce concepts critical to understanding clustered implementation of Network File System shares, the focus of this article.
|Deploying a clustered implementation of Network File System shares is a complex process. Getting a handle on the basics is critical.|
To summarize, we have outlined three options that offer user, computer and group account integration between Unix and Windows environments. The first one is based on Active Directory lookup functionality, dependent on schema extensions (implemented via ldf files located on Windows Server 2003 R2 installation media) and the NIS component included with Windows Server 2003 R2. Obviously, in this case, target servers must reside in an Active Directory domain. The second option eliminates these dependencies by leveraging User Name Mapping service (built into Windows Services for Unix), which allows for simple (automatic and based on name matches) and advanced (arbitrary but manual) associations between Windows domain and Unix (NIS or passwd/group files-based) accounts. Lastly, it is possible to employ Server for NFS Authentication component, also included in Windows Server 2003 R2, if local Windows credentials must be used, which is not relevant in the context of our series, since authorization of clustered resources occurs on the domain level.
The NFS Implementation
The NFS Implementation
Equipped with basic understanding of these options, let's take a closer look at an actual NFS implementation. This involves installing Microsoft Services for NFS on a Windows Server 2003 R2 computer hosting NFS shares accessible to Unix clients. To initiate this process, log on to its console session, launch Add or Remove Programs Control Panel applet, and select Other Network File and Print Services from the list of its entries. Click on the Details ... command button to display its subcomponents:
- Client for NFS: Allows access to resources hosted on NFS Unix servers.
- Microsoft Services for NFS Administration: Intended for managing configuration of Client for NFS, Server for NFS and User Name Mapping subcomponents (locally and remotely).
- RPC External Data Representation: Provides RPC data services, which is required by Client for NFS, Server for NFS, and User Name Mapping subcomponents.
- RPC Port Mapper: Required by Server for NFS component (since NFS is a RPC-based protocol).
- Server for NFS: Allowing Unix computers (or, in general, any NFS clients version 2 and 3) to access file share resources, including clustered ones, residing on Windows systems.
- Server for NFS Authentication: As mentioned earlier, enables Unix clients to connect to NFS Shares located on stand-alone Windows computers running Server for NFS, based on mappings between Unix and local Windows accounts.
- User Name Mapping: Responsible for associating Unix and Windows user accounts (with potentially dissimilar names), which facilitates resource sharing between users and groups accounts defined on one platform and resources residing on the other. This way, a Unix server is capable of recognizing Windows users accessing its file system via Client for NFS software as their Unix equivalents, along with their group membership. Alternatively, a Windows server running Server for NFS treats requests from native Unix users connecting to its NFS shares as those coming from its Windows clients.
For the purpose of this discussion, we will select the Microsoft Services for NFS Administration, RPC External Data Representation, RPC Port Mapper and Server for NFS. We will rely on Active Directory lookups to retrieve mappings between Unix and Windows user and group accounts. Before proceeding, make sure your Windows 2003 R2 Disk 2 is handy, since you will be prompted for it during the installation. Once the process completes, launch Microsoft Services for NFS console from the Administrative Tools menu and locate the Server for NFS subnode that appears under the root node in the tree window pane.
Its Properties dialog box is activated via its context-sensitive menu. It allows you to configure such parameters as NFS V3 and transport protocol (TCP and UDP) support, authentication renewal interval (determining how frequently NFS clients must resend their credentials), character translation options (helping maintain consistent display of NFS shares content presented to Unix and Windows clients), audit logging and lock handling (including the ability to release individual locks).
However, the most relevant attributes from our point of view are the authentication settings that enable Active Directory lookups. To configure them, switch to the top-level node in the console (labeled Microsoft Services for NFS) and invoke its Properties dialog box. On the General Settings tab, select the "Active Directory Lookup" checkbox, and type in the name of Active Directory domain that contains users and group accounts to which respective Unix user IDs and GIDs are mapped. Assuming you are using Unix NIS and that you installed and properly configured Microsoft Server for NIS (which was described in the previous article), your Unix NFS clients should be able to obtain appropriate credentials when accessing NFS shares hosted on the target server. Another possible arrangement, which also involves Active Directory lookups, relies on manually entered UID and GID values on the Unix Attributes tab of the Properties dialog box for each user and group account that must to map to a corresponding security principal on the Unix side. This approach, however, introduces additional maintenance overhead.
If for some reason taking advantage of Active Directory lookups is not feasible (e.g., you might encounter resistance to extending AD forest schema or some of your NFS shares might be hosted on pre-Windows Server 2003 R2 platform), you can resort to functionality offered by the User Name Mapping component. Its installation is performed via Windows Component Wizard. You will find its entry under Other Network File and Print Services container on the initial page of the wizard. By default, Server for NFS uses the localhost as its User Name Mapping server, although you can change this setting by specifying a remote UNM server name on the General Settings tab of the Microsoft Services for NFS Properties dialog box in the management console. This requires modifying %windir%msnfs.maphosts file on the target server, where you identify names of authorized remote systems allowed to retrieve mapping information.
In the same console, you will find User Name Mapping node, with User Maps and Group Maps subnodes. After you select the Properties item from its context sensitive menu, you will be able to designate the Unix User source on the Unix User Source tab. This can be either Network Information Service or User Password and Group files, locations you must then specify in two text boxes below.
In addition, you will also need to decide whether to enable simple maps (on the Simple Mapping tab) that apply whenever there is a match between names of Windows and Unix security principals (users or groups). Such mappings will appear under the User Maps and Group Maps subnodes (with Simple entry in the Type column) in the details pane of Microsoft Services for NFS console. Advanced maps, which are needed if Unix and Windows naming conventions do not match, are created via Create Maps item from the context-sensitive menu of User Maps subnode in the Microsoft Services for NFS console.
In the resulting dialog box, displaying Windows and Unix accounts from your authentication sources (these can be Active Directory and NIS domains, local SAM database, or local passwd/group files, depending on earlier configuration choices) in two listboxes positioned side by side, pick the ones you intend to map, and click on the Add command button. These pairs will appear under the same User Maps subnode, in the management console, as simple maps. You can then distinguish them by the Advanced entry in the Type column.
As soon as the NFS component is present on at least one member of a cluster, the NFS Share entry will appear under Resource Types node in the Cluster Administrator console. Be sure to repeat the installation on remaining cluster nodes to allow them to become possible owners, facilitating resource failover. Once this step is completed, you are ready to create a new NFS Share instance. To accomplish this, select a group containing a Physical Disk, IP Address and Network name resources, and launch a New Resource wizard. Next, provide an arbitrary name and select NFS Share option in the Resource type listbox. Designate nodes that will function as possible owners, add dependencies if appropriate (they are not enforced), and specify share parameters. Assigning its name and a path pointing to an existing folder on the Physical Disk resource located in the same group is straightforward, but other settings warrants additional explanation:
- "Share Sub-directories Only" (vs. "Share Root Only") similarly to "Share subdirectories" option in Advanced File Share Properties dialog box allows you to automatically share all of subdirectories of a designated folder.
- Encoding (with possible choices including ANSI, BIG5 - Chinese, EUC-JP - Japanese, EUC-KR - Korean, EUC-TW - Chinese, GB2312-80 - Simplified Chinese, KSC5601 - Korean, Shift-JIS - Japanese) specifies encoding applied when creating files and directories. Typically, its value would need to be adjusted according to internationalization settings of NFS clients.
- Allow anonymous access (with default UID and GID set to -2) provides NFS share-level access to Unix users who do not have established mappings to Windows accounts. the ability to read, change or delete file system objects within the share depends on their individual permissions. If you decide to use this setting (it is disabled by default), you will need to modify Windows Group Policy on the target server by enabling "Network access: Let Everyone permissions apply to anonymous users" setting (located under
Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Optionsnode) and grant sufficient NTFS permissions to the Everyone group on content of the NFS share. Any files or folders created based on this arrangement will have ANONYMOUS LOGON security principal as their owner with NULL SID as their primary group. This can be verified by checking the Security tab in the Properties dialog box within Windows Explorer).
- Permissions must also be considered. Unlike standard Windows-based shares, access to NFS share is determined based on NFS client computer, rather than user accounts. For each one, you can designate permission level (No Access, Read-Only, or Read-Write), Encoding (as listed earlier), and specify whether root access should be allowed. That last parameter facilitates scenarios where Unix administrators connected via NFS client software must be able to perform actions requiring root level privileges (such as using chown and chgrp utilities to alter user and group ownership of shared files and folders although using them on Windows-hosted NFS shares is not recommended). Keep in mind that this also requires creating a mapping between the root UID/GID and a Windows account that has equivalent privileges on the target share.
By default, the only entry that appears in the NFS Share Permissions box is the ubiquitous ALL MACHINES, which grants every client Read-Only permissions, assigns ANSI Encoding and disallows root access. Although it is not possible to remove it, you might want to modify it to the minimum level of permissions desired and explicitly specify all NFS client computers from which elevated access will be permitted. Keep in mind that each of the names added must be resolvable to a valid IP address, albeit one that is not necessarily reachable.
This concludes our overview of Windows Server 2003 based clustered resources related to disks, volumes and file system. The next article, will begin the exploration of other clustered resource types that deal with more esoteric concepts related to highly available services and applications.