Partager via

How User Name Mapping works?

  • Article

How User Name Mapping works?

User Name Mapping is the core NFS authentication component in Services for UNIX, Windows Server 2003 R2 and Windows Vista. It bridges the gap presented by difference in user identification methods used by Windows and UNIX systems. It plays equally important role for Server for NFS and Client for NFS both.

When Server for NFS receives NFS access request from a UNIX client, all it gets is UID, GID and a set of auxiliary GIDs (which represents the secondary group memberships of that user in the UNIX world). Server for NFS then typically performs the following actions to authenticate the UNIX user who’s trying to access Windows NFS share –

    • Server for NFS uses User Name Mapping to obtain the corresponding Windows user name or group name.
    • After the user name is obtained, Server for NFS connects to a domain controller (for a domain account), or to local security authority for a local user –
      • The domain controller authenticates the domain account using Kerberos extension called Service-For-User (S4U).
      • Server for NFS Authentication is needed if the user account in question is a local account. Without Server for NFS authentication, the local security authority cannot authenticate the user and access to the UNIX client will be denied.

NFS authentication may not work for domain accounts if you have domain controllers running Window 2000 operating system. S4U extensions is not supported in Windows 2000 and earlier. In such cases, you need to install Server for NFS Authentication on all of your domain controllers to get the NFS authentication to work.

When you use Client for NFS to access a UNIX NFS share, it’s the UNIX NFS Server which authenticates the Windows user at the end. Since Windows users do not have UNIX-style UIDs and GIDs, the Client for NFS gets this information from the User Name Mapping service and uses them to connect to the UNIX NFS Server.

The NFS components included with Windows Server 2003 R2 and Windows Vista have RFC2307 support and can directly fetch the UIDs and GIDs from Active Directory. This post on this same blog talks more about this feature and User Name Mapping. The Active Directory domain, however, needs to be on the R2 schema level for that to work.

Comments

  • Anonymous
    May 27, 2007
    The comment has been removed

  • Anonymous
    May 28, 2007
    Unfortunately, Vista doesn't have User Name Mapping included. In fact, User Name Mapping will not be there in Windows Server 2008 (LH Server) too. However, you can install User Name Mapping on one of your DCs or XP Machines. You can also use Active Directory Lookup in Vista but your accounts need to have UNIX information populated in AD. if you are not using domain accounts, you are left with using User Name Mapping from SFU 3.5 :-(

  • Anonymous
    June 07, 2007
    Anwering an unpublished comment - Active Directory Lookup works only when you are on R2 schema level. For the reason that R2 schema is RFC2307 compliant (with minor deviations). And, Server for NIS (whether from SFU or R2 IdMU) can only be installed on a Domain Controller and not on member servers.

  • Anonymous
    June 16, 2007
    Hmm, yeh I guess I can install User Name Mapping on my XP, but the weird thing is that when I set the IP-address of the XP machine that has UNM installed so that it can get the UID/GIDs from there it doesnt work neither :/ I dont have the will to install active directory and what not. This is only used for a home network really, not enterprise so I dont use domains for my PCs but rather just workgroup.

  • Anonymous
    June 25, 2007
    You need to edit the .maphosts file on the Windows XP system and put a "+" or the IP Address of the other systems in it before other systems can fetch the UNM data from it.

  • Anonymous
    October 14, 2007
    During the set up of SFU I recognized that disabled Active Directory Accounts leads to an error during user name mapping. The chown on the NIS/NFS client failed and results in a NULL SID, the chown on a windows host with the korn shell succeeded.

  • Anonymous
    January 15, 2008
    The comment has been removed

  • Anonymous
    January 15, 2008
    I guess capturing the network wil give us an idea why we see this error with root owned files. Drop me a mail using the Email link on this blog and then you can send me the network trace.

  • Ashish