NFS Authentication
By Charlie Russel, Microsoft MVP
Author of Microsoft Windows 2000 Server Administrators Companion 2nd Edition (Microsoft Press)
Abstract
Microsoft Services for UNIX version 3.0 uses several mechanisms for identifying which user is requesting access to a resource and then authenticating that request to the appropriate authority. Configuration problems with these mechanisms have led to a number of questions on the public Services for UNIX newsgroups. This paper covers the various mechanisms involved in authentication and identifies some common problems and their resolution.
On This Page
.gif){kind=icon}
Introduction
Components
Installation
User Name Mapping Service
Server for PCNFS
Troubleshooting
Introduction
Microsoft Windows Services for UNIX version 3.0 (SFUv3) includes key filesystem interoperability components that allow Microsoft Windows computers to function effectively in a Network File System (NFS) environment. These include Client for NFS, Server for NFS and Gateway for NFS. To enable these components to work effectively, SFUv3 must be able to accurately identify and authenticate users against both their native operating system and the remote operating system as appropriate. By default, NFS uses the UNIX method of identifying and authenticating users.
Note: Throughout this document, we refer to resources and authentication of UNIX users and computers. This is shorthand for UNIX and Linux users and computers.
Components
There are a number of components to Services for UNIX that are either involved in the authentication, or dependent on it. These include:
User Name Mapping Server – Maps UNIX users to Windows users and vice versa. Even when a user has exactly the same name on both systems, it is not actually the same user, so some mechanism is necessary to let the other components of SFUv3 know that Windows user jdoe is the same as UNIX user johnd.
Server for NFS Authentication – This isn't a server at all, but an authentication component used by Server for NFS. Install this component on any Windows server that might be involved in user authentication.
Server for PCNFS – This server is not used by other components of SFUv3, but can be used by other NFS programs that expect to see PCNFSD, including SFUv1.
Client for NFS – The Windows NFS client component of SFUv3. Client for NFS allows the machine on which it is installed to access and use NFS resources anywhere on the network.
Gateway for NFS – A special NFS client that enables a single Windows Server to provide access to NFS resources for other Windows computers that don't have any SFUv3 components installed at all. (Note: Client for NFS and Gateway for NFS are mutually exclusive – only one or the other may be installed on a machine.)
Server for NFS – The Windows NFS server component of SFUv3. Server for NFS allows the machine on which it is installed to provide file system resources to NFS clients anywhere on the network.
Installation
SFUv3 uses the Microsoft Installer, following the same, familiar conventions as the rest of the Microsoft installation programs. The purpose of this section is not to provide help on using the Microsoft Installer – that can be obtained elsewhere, including in Knowledge Base articles on installing specific portions of SFUv3 from the command line. For more information on installing the specific portions of Services for UNIX covered in this paper, see the following Knowledge Base Articles:
Installation of Windows Services for UNIX 3.0 on Windows 2000
Install the User Name Mapping Service
Install and Set Up Server for NFS
Install and Set Up Gateway for NFS
What Needs To Be Installed?
To use any of the NFS components in SFUv3, you will need to install and configure User Name Mapping Server. This is true whether you are using PCNFS or NIS for authentication. User Name Mapping Server is the core component that is required for any authentication of NFS in SFUv3.
You will also need to install the appropriate client and server components of the Services for UNIX NFS suite. To share files from a Windows server or workstation to UNIX clients, you will need to install Server for NFS on the machine providing the file services. To use files stored on UNIX hosts, you will need to install either Client for NFS or Gateway for NFS on a Windows server or workstation. You cannot install both – they are mutually exclusive. Client for NFS is appropriate for individual workstations or servers and provides access to files on the remote host for that workstation or server only. Gateway for NFS can only be installed on a server class Windows product. It provides access to files on the remote host to all Windows computers on the network, without requiring additional software on the downstream Windows computers.
If you are using Server for NFS, you will need to install the Server for NFS Authentication component on any Server for NFS machines, andon all domain controllers in the domain. If you are running in a multiple domain environment and need to map users from other domains, you will also need to install the Server for NFS Authentication component on all the domain controllers in the other domains.
Finally, Server for PCNFS does not need to be installed unless you are providing PCNFS authentication for Services for UNIX version 1 clients or other NFS products that use PCNFSD. However, if you are not using NIS for authentication of NFS requests, you may find it useful to install Server for PCNFS on the User Name Mapping Server to create the necessary passwd and group files if they aren't available from some other source.
Where Does It Need To Be Installed?
Generally, the NFS components of SFUv3 need to be installed in the location that will use them. There are two exceptions to this rule:
User Name Mapping Server – this can be installed anywhere on the network
The Server for NFS Authentication component – this needs to be installed on all domain controllers if you are running in a Windows Domain environment
User Name Mapping Server can be installed on any machine in the network, but it is generally a good practice to install it on a domain controller if you have large numbers of user maps. The creation of the initial maps requires looking up each users SID, and Server for NFS is blocked until the maps are created. If your User Name Mapping Server needs to connect to the Domain Controller for each map, to look up the Windows users SID, this can take an appreciable time and result in significant network traffic.
Note: SID is an acronym for Security IDentifier, and refers to the globally unique identifier assigned to every Windows user. Unlike UNIX, where a UID/GID pair is used to identify users, and this UID/GID pair is only locally unique, there is a single SID to identify a Windows user, and this SID is not only globally unique, but will never be repeated. So, for example, if you have a Windows user DOMAIN\JDoe, who quits the company and is then rehired, if you deleted his account you can’t re-create it. Even if you create a new account DOMAIN\JDoe, it is not the same account and SID.
User Name Mapping Service
What It Does
The User Name Mapping Service is the core authentication component of SFUv3. Whenever a UNIX user requests access to a Windows resource, or a Windows user requests access to a UNIX resource, User Name Mapping Service must map the UNIX user to the proper Windows user, or vice-versa.
While User Name Mapping Service is at the core of the authentication processes for SFUv3, it doesn't actually do the authentication. The authentication is performed by either the Windows Domain Controller if the access permissions requested are those of a Windows user, or the UNIX authentication mechanism if the access permissions are those of a UNIX user.
What Actually Happens?
When a UNIX user requests access to a file or folder (object) stored on a Windows NFS share, the first step is for the User Name Mapping Service to translate the UNIX user into the mapped Windows user. The request for access to the Windows object is then authenticated against a Windows Domain Controller using the SID of the mapped Windows user. If the mapped Windows user has the appropriate access permissions, the UNIX user who initiated the request is granted access to the object. Conversely, if the Windows user does not have sufficient permission to access the object, access is denied to the UNIX user. If the UNIX user doesn't have a mapped Windows account, or the User Name Mapping Server can’t be reached, the access is not mapped to a Windows user and thus the permissions of an anonymous user are used.
When a Windows user tries to access an object stored on a UNIX computer, the same process is used, in reverse, with one important difference – if User Name Mapping Server is using PCNFS as the authentication mechanism, the local passwd and group files on the User Name Mapping Server are used to obtain the encrypted password and UID/GID pair of the UNIX user.
One other important authentication occurs when a request comes to the User Name Mapping Service. The .maphosts file that resides in the Mapper subdirectory of the SFUv3 installation directory is checked to see if the computer requesting the user mapping is permitted to access the User Name Mapping Service. If it is not, the request for a user map is denied.
As you can see, there are several steps involved in any authentication. Any of the steps could cause an authentication failure; so its important to understand the process in order to effectively troubleshoot it.
Configuration
Configuration of User Name Mapping Server is fairly straightforward. All of the steps can be performed from the command line, but for the purposes of this paper, well stick to the Services for UNIX Administration GUI.
To Configure User Name Mapping
In the following steps, well assume that the local machine is called eng-01 and that it is also the User Name Mapping Server in the domain ENG
Point to the correct User Name Mapping Server, as shown in Figure 1.
.gif)
Figure 1: Services for UNIX Administration GUI
Click Apply to apply any changes, then click User Name Mapping and open the Configuration tab, as shown in Figure 2.
.gif)
Figure 2: Configuring User Name Mapping Server Authentication Mechanism
Select Personal Computer Network File System (PCNFS) or Network Information Service (NIS) as appropriate. For this discussion well use PCNFS, since more users seem to have problems with that.
Type in the location for the passwd and group files. As shown, the default location is %WINDIR%\system32\drivers\etc for both files.
Make any changes necessary to the synchronization refresh interval – the default is one day, and is probably appropriate for most PCNFS installations. Click Apply to make the changes effective.
Click the Maps tab to configure the actual maps. By default, Simple Maps will be checked. Simple maps are maps where the UNIX user name is identical (with the exception of case) to the Windows user name. Select the Windows domain name from the drop-down list. Use the name of the local computer only if you will not be using any domain accounts but only mapping to accounts on the local machine.
Click Show User Map to show the actual maps, as shown in Figure 3. .
Note: Simple maps will not be visible unless you check the Display simple maps in mapped users list box.)
.gif)
Figure 3: Mapping Users in User Name Mapping
To add additional, Advanced, maps, select the domain name, then click the List Windows Users and List UNIX users buttons, as shown in Figure 4.
.gif)
Figure 4: Advanced Mapping of Users
Highlight a Windows user and the corresponding user from the UNIX list, and click Add to create the map.
Where there are multiple Windows users mapped to a single UNIX user, you'll get a dialog like that shown in Figure 5. One of the Windows accounts is considered the primary account and will be the account used for authenticating against Windows resources.
.gif)
Figure 5: Primary map already exists
Repeat this process as required to map the users you need to map. Once you have mapped the users, click Apply to save the changes, then click on Show Group Maps to repeat the process with groups.
.gif)
.gif)
.gif)
.gif)
.gif)
Domain Accounts v. Local Accounts
If you are running in a Domain environment, you should generally only use Domain accounts for your mapping. Remember that local accounts are only valid on the single, local machine where they are located, so you would need to use multiple User Name Mapping Servers, one for each local machine, if you intended to access resources from more than one Windows client machine. And in the case of Gateway for NFS, using local accounts doesn't actually make much sense at all, since the Gateway machine would have one set of local accounts that would be different from any downstream clients.
Simple Maps
Simple maps are maps between accounts with the exact same name in UNIX and Windows. Keep in mind that even though the accounts have the same name, and the exact same spelling, they are not the same account. Until you actually create the maps, the accounts will not line up. For the purposes of User Name Mapping, the account name in Windows is not case sensitive, so Charlie will align with the UNIX account charlie. It would also align with a UNIX account of CHARLIE and one of Charlie, of course.
Advanced Maps
Advanced maps are used to align accounts that have different names. For example, the Windows account of the user Jane H. Doe might be jdoe but the UNIX account could be jhd. Create an Advanced map to align the two accounts. You can also use Advanced maps to map users from different Windows domains, and you can also explicitly map accounts that would generally be mapped by Simple maps, should you choose.
Authorized Hosts
To prevent unauthorized access to the User Name Mapping Server, the file .maphosts is used to explicitly specify which machines may access the server. This file is installed when User Name Mapping Server is installed and it resides in the <SFUDIR>\Mapper directory. By default, the only machine that can access the User Name Mapping Server is the local machine. You need to edit the .maphosts file with a pure ASCII text editor, such as Notepad or vi, and add the hostnames of all the hosts that are permitted to access User Name Mapping. To enable all machines to access the User Name Mapping Server, place a plus sign + on an empty line at the bottom of the file. (For more details on the syntax of entries in .maphosts, see the comments in the file itself.)
PCNFS v. NIS
The Network Information Service (NIS) is a UNIX authentication service that allows a centralized database of user information and authentication across multiple machines. If you are currently running NIS, whether or not you decide to use SFUs Server for NIS, you probably will want to use NIS as your authentication mechanism for User Name Mapping. However, if only a few users need access to UNIX resources, it may be simpler to maintain a simple PCNFS setup, especially if there are only infrequent changes.
Server for PCNFS
The components of SFUv3 do not require Server for PCNFS to be able to access UNIX resources using PCNFS authentication, therefore installation of Server for PCNFS is purely optional. However, if your UNIX machine(s) are using shadow passwords, and there isn't a readily available set of passwd/group files with the encrypted password in them, you will need to install Server for PCNFS on a machine to create the files. Once you have installed Server for PCNFS, you can use it to create the users and groups. You should always create the groups first. Since passwords are generally not an issue in group files, you can get a quick start by copying over the file /etc/group from one of your UNIX machines. Generally, its a good idea to edit the file once you have copied it to remove the special groups that won’t be mapped.
Once you have created the groups, you can then add individual users, using the Services for UNIX Administration GUI.
To Add a User to Server for PCNFS
Open the Services for UNIX Administration MMC and select Server for PCNFS in the left pane.
Select the Users tab in the right pane, and click the Add button, to open the dialog shown in Figure 6.
.gif)
Figure 6: - Using Server for PCNFS to add a user to the passwd file
Fill in the fields for the new user. The User name field corresponds to the users real name, while the User logon name is their actual UNIX account name. Once you have filled in all the fields, click OK to add the user.
Once you have added all the users you wish to add, click Apply to apply the changes, and then click User Name Mapping in the left pane to bring up the User Name Mapping administration. If you get a warning that changes haven't been saved, select Yes to save them.
In the User Name Mapping pane, select the Configuration tab and then click the Synchronize now button to make the new users available for mapping. If you'll be using Advanced maps for the new users, add them now. When you've finished, select Apply to save your changes.
Server for NFS Authentication
In addition to configuration of User Name Mapping Server, Server for NFS requires one additional step before UNIX users can be properly authenticated to access files stored on Windows servers. The Server for NFS Authentication component must be installed on the local Windows machine sharing the files, and on all domain controllers in the local domain and any domain that has mapped users. This has been the source of a good deal of confusion to users and administrators, if the messages on the microsoft.public.servicesforunix.general
newsgroup are any indication.
Verifying Installation
The Server for NFS Authentication component needs to be installed on all domain controllers in the local domain and on any other domain where there are mapped users. To verify installation check for the presence of the file %WINDIR%\system32\nfssa.dll. Server for NFS Authentication does not install any new service on a machine and its presence is not shown on the Add/Remove Programs list.
Installation of
You can easily install just the Server for NFS Authentication component using the command line, allowing for easy scripting across multiple domain controllers. The command line to silently install Server for NFS Authentication is:
msiexec /I D:\sfusetup.msi /q addlocal="NFSServerAuth"
where D: is the CD-ROM drive containing the SFUv3 installation CD. Please note that the addlocal parameter is case sensitive. And also note that this command will remove any other components of Services for UNIX v3 except Server for NFS Authentication. If you are installing multiple components from the command line, you must use a comma separated list within the quotes of the addlocal parameter. Thus, to install both Server for NFS and Server for NFS Authentication you would use:
msiexec /I D:\sfusetup.msi /q addlocal="NFSServer,NFSServerAuth" pidkey="key"
where key is the 25 character product key, without spaces or hyphens, and where this was all entered on a single line.
Licensing
The Microsoft Software License Terms for Services for UNIX version 3.0 explicitly allows for Server for NFS Authentication to be installed on all Domain Controllers without purchasing additional licenses.
Troubleshooting
Troubleshooting problems with authentication in Services for UNIX requires carefully verifying each step of the process. The two most common missed steps, from posts on the newsgroup, are forgetting to install Server for NFS Authentication on all the domain controllers, and failure to configure the .maphosts file.
Server for NFS Authentication
If you don't install Server for NFS Authentication on all domain controllers, but only on some of them, you will have unreliable authentication. Sometimes a UNIX user will be able to authenticate and access the NFS share with the proper credentials, and at other times, they will not be authenticated and only have the access of an anonymous user. If you experience this kind of erratic NFS authentication, verify that Server for NFS Authentication is installed on all domain controllers, and on the server that is hosting the share.
.maphosts
If NFS authentication of client or server requests is erratic and appears to be machine specific, the most likely cause is a configuration problem with the .maphosts file on the User Name Mapping Server. Verify that the machines where authentication problems are occurring are entered correctly in the .maphosts file. If problems persist, edit the .maphosts file to remove all uncommented entries except a single + (without the quotes) as the first entry in the last line of the file. If this resolves the problem, then carefully add the entries back in and comment out the line with the plus sign by itself.
Another possible source of problems is a DNS failure – if the User Name Mapping Server has any DNS resolution problems with some of the computers, it will cause the entries in the .maphosts file to be unresolved.
Problems with PCNFS Files
If you are using PCNFS for authentication, you need to ensure that the files are present and have the correct format. The two files are passwd and group and they should be in the %WINDIR%\system32\drivers\etc directory. Use Server for PCNFS to create the files if you are experiencing problems.
If the files are present and formatted correctly, you should be able to pull up a list of UNIX users in the Maps tab of the Services for UNIX Administration GUI under User Name Mapping. This does not, however, ensure that the encrypted passwords are present or correct.
Different UIDs on Different Machines
Another problem that can occur is that different UNIX machines may have different UIDs for the same user. On one machine, the user would map correctly, but on another machine, the user would be unmapped or map to the wrong user. This requires that the UNIX system administrator align his user accounts so that the same user has the same UID and GID across all machines.