User Name Mapping and Services for UNIX NFS Support
Technical Walkthrough
Abstract
Microsoft® Windows® Services for UNIX 2.0 includes User Name Mapping. This is a component that maps user names between Windows and UNIX name spaces.
On This Page
.gif){kind=icon}
Introduction
Installing User Name Mapping
Configuring User Name Mapping
Frequently Asked Questions
Summary
Introduction
The Windows and UNIX operating systems use different mechanisms for user identification, authentication, and resource access control. In a heterogeneous network, users have separate accounts in UNIX and Windows networks. Since Windows and UNIX user identifications and user names are stored and used differently, there is no association between the two sets even though the users in the two networks are the same.
Separate name spaces with different user names and different identification mechanisms pose problems for services that provide cross-domain resource access. For such services to work correctly, they need user identifications in their own name space. On the other hand, users like to use the name space they are accustomed to.
This Technical Walkthrough describes how to map Windows-based network user names to UNIX-based network user names and vice versa.
User Identification in NFS
By default, NFS protocol uses UNIX user identification, typically consisting of User Identifier (UID) and Group Identifier (GID), for access control. Windows-based NFS servers have to identify the requesting users, in the Windows name space, from NFS requests. Since Windows-based computers and domains do not use UIDs and GIDs for identification, a mapping is needed from UIDs and GIDs contained in the NFS requests to Windows user names. Windows based NFS clients need to map the requesting Windows user name to UID/GID before forwarding an NFS request.
For a windows user to access UNIX-based NFS resources need to provide UNIX identification (UID/GID). This requires Windows users to authenticate themselves on UNIX networks using their UNIX user name and password.
Administrative Problem
Many Windows based NFS products (or other services that provide cross domain resource access) create a mapping on each computer providing NFS services for cross platform identifications. Maintaining these mappings on each computer or server is difficult and time-consuming since they must be kept consistent when there are account additions, deletions, and changes. All servers that provide these services must have consistent mappings to provide resource access from anywhere in the network.
User Name Mapping
The User Name Mapping is a component of Services for UNIX. This provides the functionality of mapping Windows-based network user names to UNIX-based network user names and vice versa. This is a means to associate user names in two networks for users who have different identities in Windows-based and UNIX-based domains. It is designed with the following objectives:
Share a single set of user name mappings across the network. Multiple instances of Client for NFS, Server for NFS and Gateway for NFS should be able to use just one set of mappings. This should allow consistent access for users while using any of the NFS products from any computer.
Ease the administrative task of maintaining maps on all Windows computers providing NFS services or Remote Shell Service.
Provide Windows users access to their UNIX-based NFS resources with single sign-on. The users do not have to remember two sets of user names and passwords, or sign on separately to the two operating systems.
User Name Mapping creates mappings between Windows and UNIX user names. These mappings are maintained as a table, as shown in Table 1.
Table 1 User Name Mappings Between Windows and UNIX.
Windows user name |
Windows domain |
UNIX user name |
UNIX domain |
UID/GID |
|---|---|---|---|---|
JohnDoe |
Indwindows |
Johnd |
Indunix |
1090/201 |
Maryjane |
Indwindows |
Maryj |
Indunix |
1223/201 |
All Services for UNIX Network File Service (NFS) components—Server for NFS, Client for NFS, and Gateway for NFS—use the User Name Mapping for NFS identification and access to NFS resources.
Benefits of User Name Mapping
Central Mapping Server
User Name Mapping can be deployed on a single node in the organization and all NFS components in the network can access this server for mapping. This allows consistent NFS access from all computers. A central server also helps reduce costs of administration.
Allows Simple and Advanced Mapping
User Name Mapping can easily map between users whose user names are the same in Windows-based and UNIX-based networks. With simple mapping, users with identical user names in UNIX and Windows networks are mapped automatically and administrators need no intervention, Users with different user names can also be mapped using the advanced options of User Name Mapping.
Supports Multiple Windows-Based and NIS-Based Domains
User Name Mapping can establish advanced mappings between user names from any NIS domains to a user name from any Windows-based domain. This allows the mapping server to be shared between multiple domains.
Maps Users and Groups
The User Name Mapping service includes the capability to map user names as well as group names between the two name spaces.
Refreshes NIS, PCNFS, and Windows User Names Periodically
The User Name Mapping periodically refreshes user names from Windows domain controllers, and NIS-based servers or PCNFS. Whenever a user gets added or deleted from either UNIX or windows domains, a mapping can be added or deleted automatically. The key advantage of this feature is that administrative intervention is not required for changes to users in UNIX and Windows name spaces.
Provides Command Line, Graphical and Remote Administration Capability
The user name maps can be created, maintained, and managed using graphical user interface (GUI) or command line utilities. This allows simplicity in administration of user name mappings.
Supports Backup and Restoration of Mappings
User Name Mapping can save already-created mappings to a file or load them from a file and populate the mapping server. This feature is particularly useful to back up the mappings to address failures of User Name Mapping servers.
Allows Mapping of Multiple Windows Users to One UNIX User
User Name Mapping has the facility to map multiple Windows user names to a single UNIX user name. This is useful when there is no one-to-one correspondence between UNIX and Windows users. It may be used when access to a UNIX-based file server has to be provided according to different classes of access privileges.
Authenticates UNIX User Names and Passwords
User Name Mapping authenticates a UNIX user name and password using a UNIX 'crypt' algorithm and provides UNIX identification. This is useful where the Windows user requires access to UNIX resources using a UNIX account to which the user is not mapped.
Installing User Name Mapping
Installing User Name Mapping
User Name Mapping can be installed as a part of Services for UNIX on any computer running either Windows NT4.0 or Windows 2000. However, in order to use it as a central server, it should be installed on a Windows NT4.0 server or Windows 2000 server on a server class computer. It is not selected by default and must be selected using custom installation. User Name Mapping may be installed using either a GUI tool or a command line tool.
Configuring NFS Components
Services for UNIX NFS components, Server for NFS, Client for NFS and Gateway for NFS, can all be configured to use a particular User Name Mapping server. The name of the User Name Mapping server can also be configured during the installation of Services for UNIX. In addition, you may set a particular User Name Mapping server for using Services for UNIX administration. You may select a User Name Mapping server to be used for each NFS component.
.gif)
Figure 1: Example of Services for UNIX Administration-Server for NFS screen.
Installing Server for NFS Authentication
In order for Server for NFS to work correctly, you must also install Server for NFS Authentication. The Services for UNIX requires that Server for NFS Authentication be installed on a computer where Server for NFS is installed. This is necessary if the UNIX user names are mapped to local Windows user names using User Name Mapping. Server for NFS Authentication running on local server facilitates NFS access using local Windows user accounts.
To facilitate NFS access on Server for NFS using credentials of Windows domain users, Server for NFS Authentication must be installed on all domain controllers in the Windows domain. This is necessary if the UNIX user names are mapped to Windows domain user names using User Name Mapping. Further, it must be installed on domain controllers of all domains to which UNIX users are mapped.
For example, consider that a UNIX user with user name paul is the same as Windows user paulv in domain ntphyslab (ntphyslab\paulv). When paul accesses NFS files residing on Windows server using UNIX client, Server for NFS needs to access files using the credentials of ntphyslab\paulv. For this to succeed, Server for NFS Authentication must be installed on all domain controllers of domain ntphyslab.
Configuring User Name Mapping
Before you configure User Name Mapping, you need to have certain information available to you.
Determine whether your UNIX-based network uses NIS or uses /etc/passwd and /etc/group files. Also determine whether you use PCNFS for authenticating Windows based NFS clients.
Determine the primary Windows domain and the primary UNIX NIS server, if you use NIS, between which the user names must be mapped. Most of the users will have accounts in both of these domains.
If you use PCNFS server, you must use a Windows based PCNFS server to be able to use it with User Name Mapping. You should know the location of the password and group files that are used by Windows PCNFS server.
For most users, user names in both Windows and UNIX domains will be identical. Such users can be mapped using Simple Mapping provided by User Name Mapping. For those that do not have identical user names, these users must be mapped using Advanced Mapping. You should compile a list of users whose user names are not identical.
Simple Mapping allows only one mapping between a Windows domain and another UNIX NIS domain (or PCNFS). For users from other Windows or UNIX domains, you must use Advanced Mapping.
If you need to either deny some users access or provide them the "anonymous" privileges, you need to map them using Advanced Mapping.
If you need to map multiple Windows users to one UNIX user, you must use Advanced Mapping. This is applicable primarily for Client for NFS or Gateway for NFS. This is useful when a number of Windows users must be provided NFS access using a smaller number of "classes of access".
Simple Mapping
Consider an organization with a number of Windows and UNIX NIS domains. See Figure 2. The organization wants to setup Server for NFS on a computer in a Windows domain called ntphyslab. In an organization with both UNIX and Windows computers, if users have accounts on both UNIX and Windows domains, Simple Mapping provides an easy way to map such users. If most of the UNIX users that want to access this NFS server have accounts in this Windows domain and also in another UNIX domain, simple mapping will provide the simplest way for mapping. Consider that most NFS users have accounts in UNIX domain called uxphyslab.
.gif)
Figure 2: Mapping between ntphyslab and uxphyslab.
In such a case, you should use simple mapping to map user names between ntphyslab and uxphyslab.
Consider that there are users with accounts in both UNIX and Windows-based domains. Once Simple Mapping between these two domains is enabled, these users will be mapped to each other's domains automatically and the administrator will not have to map these user names individually.
Both ntphyslab and uxphyslab domains have a number of common users as well as groups. We have configured the User Name Mapping to create simple mappings between the two domains.
Figure 3 shows that UNIX domain uxphyslab and Windows domain ntphyslab are mapped to each other. All users who have identical user names in the two domains are mapped to each other. For example, it associates Windows user john with a UNIX user john.
.gif)
Figure 3: Example of Services for UNIX Administration-User Name Mapping screen.
NFS Access on Client for NFS
Consider connecting to UNIX NFS server using Client for NFS from a Windows 2000 computer. In this example, mary working on a Windows computer wants to mount a UNIX NFS share (\\157.60.253.91\y). As shown below ntphyslab\mary is mapped to uxphyslab\mary. On UNIX domain, mary's UID / GID are 627/200.
Mary uses her own Windows credentials to connect to a UNIX share using net command, see Figure 4. Client for NFS maps ntphyslab\mary to uxphyslab\mary using, User Name Mapping. Since Mary has already been authenticated in the ntphyslab domain, Client for NFS does not require authentication in the UNIX uxphyslab domain. It uses the UID and GID of uxphyslab\mary provided by the User Name Mapping in the NFS requests. This allows users to access UNIX NFS shares with single signon1. Note that the UID/GID used to mount and access the NFS share (via 'i:' drive) is 627/200 that belongs to uxphyslab\mary.
.gif)
Figure 4: Example of a Windows command session run as ntphyslab\mary.
Client for NFS also allows connection to an NFS share using UNIX user name and password. It does not use the User Name Mapping to map the user names. It uses the UNIX user name and password to authenticate the user in the UNIX domain using User Name Mapping. User Name Mapping uses either NIS or PCNFS to authenticate the user name and passwords.
Figure 5 shows the output of 'ls' on the UNIX computer. Note that UID and GID of the file are those of the mapped user, namely, uxphyslab\mary.
.gif)
Figure 5: Example, output of 'ls' on the UNIX computer.
File Access on Server for NFS
Once mappings are set via User Name Mapping, UNIX users can mount and access NFS shares on Server for NFS. A UNIX user accessing files will be provided access according to credentials of the mapped user on the Windows computer. Access to files from UNIX computers is consistent with the permission bits on that file. The following example shows how a UNIX root can mount an NFS share exported by a Server for NFS computer. It also shows how a UNIX user can create a file or a directory on the computer. You can see that the UID and GID of a file created by the user are correct.
[root@tpilx2 /root]# showmount -e vivekn02 Export list for vivekn02: /nfstest (everyone) [root@tpilx2 /root]# mount vivekn02:/nfstest /mnt/sfunfs [root@tpilx2 /root]# cd /mnt/sfunfs [root@tpilx2 sfunfs]# ls [root@tpilx2 sfunfs]# su mary [mary@tpilx2 sfunfs]$ touch mary.file.1 [mary@tpilx2 sfunfs]$ mkdir mary.dir.1 [mary@tpilx2 sfunfs]$ ls -al total 3 d------rwx 2 root root 64 Apr 25 15:11 ./ drwxrwxrwx 18 root root 1024 Apr 25 12:43 ../ drwxr-xr-x 2 mary theory 64 Apr 25 15:11 mary.dir.1/ -rw-r--r-- 1 mary theory 0 Apr 25 15:11 mary.file.1 [mary@tpilx2 sfunfs]$ [root@tpilx2 sfunfs]# su joshua [joshua@tpilx2 sfunfs]$ touch joshua.file.1 [joshua@tpilx2 sfunfs]$ ls -al total 3 d------rwx 2 root root 64 Apr 25 15:11 ./ drwxrwxrwx 18 root root 1024 Apr 25 12:43 ../ -rw-r--r-- 1 joshua nuclear 0 Apr 25 15:12 joshua.file.1 drwxr-xr-x 2 mary theory 64 Apr 25 15:11 mary.dir.1/ -rw-r--r-- 1 mary theory 0 Apr 25 15:11 mary.file.1 [joshua@tpilx2 sfunfs]$ touch mary.file.1 touch: mary.file.1: Permission denied
A file created by a UNIX user on the Windows computer is created using the credentials of the mapped Windows user. The file ownership, primary group of the file and the DACLs of the file on the Windows computer are set according to the mappings. For example, consider the file mary.file.1 that was created by uxphyslab\mary. This UNIX user is mapped Windows user ntphyslab\mary that consequently is the file on the Windows computer. The ACLs for the file are as follows:
C:\nfstest>cacls mary.file.1 C:\nfstest\mary.file.1 NTPHYSLAB\mary:(special access:) DELETE READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES NTPHYSLAB\theory:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_READ_DATA FILE_READ_EA FILE_READ_ATTRIBUTES Everyone:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_READ_DATA FILE_READ_EA FILE_READ_ATTRIBUTES
The ownership and primary group membership of the file are set as follows in the security descriptor of mary.file.1 file are set as follows:
Owner: NTPHYSLAB\administrator (User) : (S-1-5-21-339783794-3065341851-447533925-500) PrimaryGroup: NTPHYSLAB\theory (Group) : (S-1-5-21-339783794-3065341851-447533925-1120)
Advanced Mapping
User Name Mapping provides Advanced Mapping where a Windows user from any domain may be mapped to a UNIX user. See Figure 6.
Mapping users who have different user names in Windows and UNIX domains. Consider that Peter Johnson has a Windows user name as pete_Johnson and UNIX user name as peterj. In order to map these users, we use advanced mapping. With this mapping, a file created on a UNIX NFS server by Peter using pete_Johnson account will be marked as owned by peterj. Similarly, a file owned by pete_johnson can be accessed by peterj from UNIX NFS client.
.gif)
Figure 6: Example of Services for UNIX Administration-User Name Mapping screen showing Advanced Mapping.
In the following example, Peter creates a file on a UNIX NFS server while logged in as pete_johnson on a Windows computer:
.gif)
c:\sectools>net use * \192.168.238.17\UITests1 /u:ntphyslab\pete_johnson The password is invalid for \192.168.238.17\UITests1.
Type the password for \192.168.238.17\UITests1: Drive L: is now connected to \192.168.238.17\UITests1.
The command completed successfully.
C:\sectools>mount
Local Remote Properties
L: \192.168.238.17\UITests1 UID=755, GID=147 rsize=32768, wsize=32768 mount=soft, timeout=0.8 retry=5, locking=yes lang=euc-jp
C:>touch l:\pete.file.1 The following output shows the listing of this file on the UNIX computer:
ls -al pete*
-rwxr-xr-x 1 peterj particle 0 Apr 29 06:13 pete.file.1
The user mapping created on User Name Mapping also works for NFS access from UNIX NFS clients to Server for NFS shares. In the following example, Peter creates a file on a Server for NFS share from a UNIX NFS client while logged in as peterj.
<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">
mount 157.60.253.92:/nfstest /mnt/nfstest
su peterj
$ cd nfstest $ cat > peterj.file.2 This is a file $ ls -al pet* -rw-r--r-- 1 peterj particle 15 Apr 29 07:05 peterj.file.2
The owner, group and DACLs of this file on the Windows computer, shows that the file is owned by the intended Windows user.
<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">
Owner: NTPHYSLAB\pete_johnson (User) : (S-1-5-21-339783794-3065341851-447533925-1122) PrimaryGroup: NTPHYSLAB\particle (Group) : (S-1-5-21-339783794-3065341851-447533925-1118)
Mapping users from domains that are different from the domains in the simple mapping. This is useful if users from different domains access NFS resources or users who are mobile. In the previous example (see Figure 6), we have mapped ntphyslab\pradeeps to nfslab\pradeeps since pradeeps has account in nfslab NIS domain.
Mapping multiple Windows users to a single UNIX user. Consider that UNIX has account called spec, which has certain permissions on files. Both yench and zoe from Windows domain ntphyslab need to access this account to update these files. This can be accomplished by mapping both zoe and yench to nfslab\spec which will allow both of them to access files owned by user account spec. Note that only multiple Windows user names may be mapped to one UNIX account and not vice versa. Similarly, a UNIX user may also be mapped to <anonymous> Windows user. This provides a way to change UNIX users to anonymous for NFS access on Server for NFS.
In the following example, ntphsylab\yench creates a file on the UNIX NFS share. After mounting it creates a file on the mounted share called, yench.spec.file.
C:\sectools>net use * \192.168.238.17\UITests1 /u:ntphyslab\yench The password is invalid for \192.168.238.17\UITests1. Type the password for \192.168.238.17\UITests1: Drive I: is now connected to \192.168.238.17\UITests1. The command completed successfully. C:\sectools>touch i:\touch yench.spec.file
Subsequently, ntphyslab\\zoe also mounts the same NFS share. From the output of mount, you will notice that both mounts are created as UID=100 and GID=101 which are the UID/GID of nfslab\\spec. This user also creates a file on the mounted share called, yench.spec.file.
<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">
C:\sectools>net use * \192.168.238.17\UITests1 /u:ntphyslab\zoe The password is invalid for \192.168.238.17\UITests1. Type the password for \192.168.238.17\UITests1: Drive L: is now connected to \192.168.238.17\UITests1. The command completed successfully. C:\sectools>mount Local Remote Properties
I: \192.168.238.17\UITests1 UID=100, GID=101 rsize=32768,wsize=32768 mount=soft, timeout=0.8 retry=5, locking=yes lang=euc-jp L: \192.168.238.17\UITests1 UID=100, GID=101 rsize=32768, size=32768 mount=soft, timeout=0.8 retry=5, locking=yes lang=euc-jp c:\sectools>touch l:\zoe.spec.file
The listing of both these files on the NFS server shows that the files are owned by user spec.
<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">
$ grep spec /etc/passwd spec:x:100:101::/home1/spec:/bin/sh $ ls -al spec -rwxr-xr-x 1 spec indiadev 0 Apr 29 07:28 yench.spec.file -rwxr-xr-x 1 spec indiadev 0 Apr 29 07:30 zoe.spec.file
Providing anonymous access by unmapping users. In certain circumstances, you may need to disallow or provide anonymous access to NFS resources for certain users. You can use Advanced Mapping to map users to <unmapped> user. This changes Windows users to anonymous users on UNIX NFS servers. In the example below, both janetn and jbr are mapped to <unmapped> providing them with the default UID / GID or –2 and –1 respectively.
This is illustrated in the following example where NFS share is mounted by janetn.
c:>net use * \157.60.253.91\UITests1 /u:ntphyslab\janetn * Type the password for \157.60.253.91\UITests1: Drive L: is now connected to \157.60.253.91\UITests1. The command completed successfully. C:>mount Local Remote Properties
L: \157.60.253.91\UITests1 UID=-2, GID=-1 rsize=8192, wsize=8192 mount=soft, timeout=0.8 retry=5, locking=no lang=euc-jp L:>copy con janet.file This file is created by Janet ^Z 1 file(s) copied.
This file is created as anonymous on the UNIX NFS server. The directory listing of this file is shown below.
<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">
[root@tpilx2 /UITests1]# ls -al janet* -rwxr-xr-x 1 nobody nobody 31 Apr 29 19:30 janet.file*
User Name Mapping also allows UNIX user names to be mapped to \<unmapped\> Windows user names. This can be used to change certain UNIX user accounts to anonymous for Server for NFS. In the example, UNIX user john is mapped to anonymous by mapping him to \<unmapped\>. In addition, we have also mapped his primary group, nfstest to \<unmapped\>. The entire set of mappings is shown below.
<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">
C:\nfstest>mapadmin list all Advanced User Mappings: Windows user UNIX user Uid Primary Gid
- ntphyslab\yench nfslab\spec 100 101 ^ ntphyslab\zoe nfslab\spec 100 101 ^ ntphyslab\pradeeps nfslab\pradeeps 1021 1 ^ ntphyslab\jbr nfslab<unmapped> -2 -1 ^ ntphyslab\janetn nfslab<unmapped> -2 -1 ^ <unmapped> uxphyslab\john 1041 202 Advanced Group Mappings: Windows group UNIX group Gid
ntphyslab\nuclear uxphyslab\indiadev 101 ^ <unmapped> uxphyslab\nfstest 205
Subsequently, John connects to the Server for NFS and creates a file on the Windows computer.
root@tpilx2 /UITests1]# mount vivekn02:/nfstest /mnt/nfstest root@tpilx2 /UITests1]# su john john@tpilx2 /UITests1]$ cd /mnt/nfstest [john@tpilx2 nfstest]$ grep john /etc/passwd john:x:1041:205::/home/john:/bin/bash [john@tpilx2 nfstest]$ grep nfstest /etc/group nfstest:x:205:john [john@tpilx2 nfstest]$ cat > john.file This file is created by John from a Unix NFS client on Server for NFS [john@tpilx2 nfstest]$ ls -al john.file -rw-r--r-- 1 65534 65535 70 Apr 29 20:05 john.file
Primary Mappings
In the example, we have mapped two users ntphyslab\yench and ntphyslab\zoe to the same UNIX user (spec). When either of these users access UNIX NFS share, the UID and GID of UNIX user spec is used for file access and creation.
However, when the UNIX user spec connects to Server for NFS, there are two possible Windows user accounts whose credentials may be used to fulfill the NFS requests. User Name Mapping provides a way to resolve this conflict by allowing the administrator to mark one of them to be the primary mapping. In the example, mapping between ntphyslab\yench and uxphyslab\spec is marked to be the primary mapping, marked by a '*' in the User Name Mapping administration tool.
C:\nfstest>mapadmin list advanced Advanced User Mappings: Windows user UNIX user Uid Primary Gid ------------------------------------------------------------------------- * ntphyslab\yench nfslab\spec 100 101 ^ ntphyslab\zoe nfslab\spec 100 101 ^ ntphyslab\pradeeps nfslab\pradeeps 1021 1 ^ ntphyslab\jbr nfslab\<unmapped> -2 -1 ^ ntphyslab\janetn nfslab\<unmapped> -2 -1 ^ <unmapped> uxphyslab\john 1041 202 Advanced Group Mappings: Windows group UNIX group Gid ------------------------------------------------------------------------- * ntphyslab\nuclear uxphyslab\indiadev 101
The following example shows the effects of the primary mapping. When user spec, creates a file called spec.file on the Server for NFS, it shows up correctly as owned by UID=spec and GID = indiadev.
# mount 157.60.253.92:/nfstest /mnt/nfstest # su spec $ cd /mnt/nfstest $ cat > spec.file This is a file created by spec. $ ls -al spec.file -rw-r--r-- 1 spec indiadev 32 Apr 29 07:53 spec.file
However, on the Windows computer, the owner and primary group of the file are marked as ntphyslab\yench and ntphyslab\nuclear.
Owner: NTPHYSLAB\yench (User) : (S-1-5-21-339783794-3065341851-447533925-1116) PrimaryGroup: NTPHYSLAB\nuclear (Group) : (S-1-5-21-339783794-3065341851-447533925-1121)
Root Access
If you need to provide root access to Windows NFS server, you have to enable root access to the UNIX NFS clients that should have root access, to the NFS server. In addition, you also need to create a mapping between the root and another account on the Windows domain. The natural mapping to create is to map root to administrator and vice versa.
The following example shows how root access can be provided. You need to map the UNIX root user to domain administrator (or the local administrator). You should also map the primary group of UNIX root to Windows "domain admins" group if you are mapping domain account or "administrators" group if you are mapping local accounts. In the following example, root (nfslab\root) is mapped to domain administrator (ntphyslab\administrator) and the primary group of root other (nfslab\other) is mapped to domain admins group (ntphyslab\domain admins).
Advanced User Mappings: Windows user UNIX user Uid Primary Gid ------------------------------------------------------------------------- ^ ntphyslab\administrator nfslab\root 0 1 Advanced Group Mappings: Windows group UNIX group Gid ------------------------------------------------------------------------- ^ ntphyslab\domain admins nfslab\other 1
In addition, you also need to provide root access to computers that should have root permissions on the NFS server.
C:\>nfsshare roottest=c:\roottest -o root=192.168.238.17 roottest was shared successfully
Once the root permission is provided, root from specified Unix NFS client can access NFS share on Server for NFS.
# showmount -e 157.60.253.92 export list for 157.60.253.92: /roottest (everyone) # mkdir /mnt/rtest # mount 157.60.253.92:/roottest /mnt/rtest # cd /mnt/rtest # touch root.file.1 # ls -al root* -rw-r--r-- 1 root other 0 Apr 30 06:20 root.file.1
The owner and primary group information of the file root.file.1 is according to mapping shown above.
Owner: NTPHYSLAB\Administrator (User) : (S-1-5-21-339783794-3065341851-447533925-500) PrimaryGroup: NTPHYSLAB\Domain Admins (Group) : (S-1-5-21-339783794-3065341851-447533925-512)
Group Mappings
In the previous examples, although they are used we do not show explicit group mappings. Group mappings can be created the same way as user mappings can be created. They provide access to Server for NFS shares according to group permissions.
In this example, we have mapped linda and mary from UNIX to the same user names in Windows. In addition, we have mapped ntphyslab\particle group to uxphyslab\theory group.
C:\marydir>mapadmin list all Advanced User Mappings: Windows user UNIX user Uid Primary Gid ------------------------------------------------------------------------- ^ ntphyslab\mary uxphyslab\mary 627 200 ^ ntphyslab\linda uxphyslab\linda 866 147 Advanced Group Mappings: Windows group UNIX group Gid ------------------------------------------------------------------------- ^ ntphyslab\particle uxphyslab\theory 200
In the NIS domain, both linda and mary have their primary group as theory with GID 200. mary creates a file called mary.file.1 which has only read permission for the theory group. Consequently, Linda is able to read the file but unable to write to it.
# su mary $ rm mary.file.1 $ cat > mary.file.1 This file is created by Mary and can be read by members of theory $ ls -al mary.file.1 -rw-r--r-- 1 mary theory 66 Apr 30 09:54 mary.file.1 $ exit # su linda $ cat < mary.file.1 This file is created by Mary and can be read by members of theory $ cat >> mary.file.1 mary.file.1: cannot create
The DACLs of the file are as shown below. The primary group of the file is marked as ntphyslab\particle the group that UNIX group theory is mapped to.
C:\marydir>cacls mary.file.1 C:\marydir\mary.file.1 NTPHYSLAB\mary:(special access:) DELETE READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_GENERIC_WRITE FILE_READ_DATA FILE_WRITE_DATA FILE_APPEND_DATA FILE_READ_EA FILE_WRITE_EA FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES NTPHYSLAB\particle:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_READ_DATA FILE_READ_EA FILE_READ_ATTRIBUTES Everyone:(special access:) READ_CONTROL SYNCHRONIZE FILE_GENERIC_READ FILE_READ_DATA FILE_READ_EA FILE_READ_ATTRIBUTES
Frequently Asked Questions
Q: I created new mappings on User Name Mapping server. My Server for NFS does not seem to indicate that it has the new mapping.
A: Server for NFS refreshes its mappings every 30 minutes. That is changes made to any of the mappings that take place on User Name Mapping, won't be used by the Server for NFS until after 30 minutes.
Note: There will be an event log when the NFS Server has refreshed the mappings.
Q: I need Server for NFS to use the mapping created on User Name Mapping immediately. How do I do that?
A: You will need to stop the Server for NFS and restart it, or click Apply under Settings in the Admin UI to refresh the mappings immediately.
Q: I added some Windows accounts in the Windows domain (or UNIX accounts in the NIS domain), but User Name Mapping does not show the new mappings in Simple Mapping.
A: By default, User Name Mapping server refreshes the accounts from NIS or PCNFS and Windows domain every 24 hours. If users with identical user names are added to Windows and UNIX domains, a mapping will be added to Simple Mapping in User Name Mapping after this refresh interval. You may change this refresh interval using User Name Mapping admin console.
Q: I want to connect to UNIX NFS server using another Windows user name and password.
A: You can use either net command or mount command. You should provide the Windows username and password in this command where user name and password are required. If the user is a domain user, you should qualify the user name with the domain as (\\domain\username).
Q: I want to connect to UNIX NFS server using UNIX user name and password.
A: You can use either net command or mount command. You should provide the UNIX username and password in this command where user name and password are required.
Q: I am able to mount my Server for NFS share. However all files created are created as anonymous (nobody or UID –2).
A: Follow the following steps to diagnose the problem:
Make sure that Server for NFS is pointing to the right User Name Mapping server.
Make sure that User Name Mapping is running and working correctly.
Make sure that the user that is creating files is properly mapped in User Name Mapping. In particular make sure that the user has a mapping, the user is not mapped to <anonymous> Windows user.
For this UNIX user, if the mapped Windows user is a domain user, make sure that Server for NFS Authentication is installed on domain controllers of the Windows domain.
Summary
For More Information
For the latest information on Windows 2000 Server, check out Microsoft TechNet and the Windows 2000 web site and the Windows 2000/NT Forum at MSN Computing Central.
Related Documents
For more information on Server for NIS, refer to the following document: Server for NIS Overview.
Before You Call for Support
Please keep in mind that Microsoft does not support these white papers or walkthroughs. The purpose of the white papers and walkthroughs is to facilitate your initial evaluation of the Microsoft Windows Services for UNIX features. For this reason, Microsoft cannot respond to questions you might have regarding specific steps and instructions.
Reporting Problems
Problems with Microsoft Windows Services for UNIX should be reported by way of the appropriate bug reporting channel and alias. Please make sure to adequately describe the problem so that the testers and developers can reproduce it and fix it. Refer to the Release Notes included on the Windows Services for UNIX distribution media for some of the known issues.
| 1 | The passwords of the user in Windows domain and Unix domain need not be the same. |