Services for UNIX - Interoperability : Server for NFS

Managing Client Groups - An Easier Approach

Ashish — Fri, 13 Nov 2009 00:43:00 GMT

Managing Client Groups - An Easier Approach On UNIX-based NFS servers, it's much easier to control access to the NFS shares based on host names or IP addresses. You just have to put them in the export file and it's done. It's not so difficult in Windows...(read more)

Getting AD Lookup to work without UNIX Attributes tab

Ashish — Thu, 16 Jul 2009 20:03:00 GMT

Getting AD Lookup to work without UNIX Attributes tab The previous post talks about how to get the UNIX Attributes tab to work without installing IdMU components. In this post, I would like to talk about what attributes the NFS components expect to be...(read more)

AD Lookup with ADAM/ADLDS

Ashish — Sat, 11 Jul 2009 01:17:00 GMT

AD Lookup with ADAM/ADLDS With removal of UNM in Vista/W2K8, it became really problematic to map users in non-AD environments to use with Vista/LH NFS Servers and Clients. For client, a workaround was discovered which was essentially a registry tweak...(read more)

Limitation with Active Directory Lookup feature in Microsoft Services for NFS

Ashish — Tue, 16 Dec 2008 01:25:00 GMT

Limitation with Active Directory Lookup feature in Microsoft Services for NFS The Active Directory Lookup feature that was introduced with Windows Server 2003 R2. This feature greatly simplifies the UNIX identity information management but has its own...(read more)

Set up Services for Network File System in Windows Server 2008

Ashish — Tue, 16 Dec 2008 01:03:00 GMT

Set up Services for Network File System in Windows Server 2008 The Microsoft Services for NFS continues to be the part of the operating system in Windows Server 2008 and seems we will see more improvements when Windows Server 2008 R2 is released. In Windows...(read more)

How User Name Mapping works?

Ashish — Fri, 11 May 2007 23:28:00 GMT

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.

Set up Server for NFS in Windows Server 2003 R2

Ashish — Thu, 19 Apr 2007 19:30:00 GMT

Set up Server for NFS in Windows Server 2003 R2

In this post, I will talk about configuring Microsoft Services for Network File System, mainly Server for NFS and User Name Mapping, in Windows Server 2003 R2. You can follow the same steps for Services for UNIX (SFU) 3.5 except only a few of them because of some changes introduced with Windows Server 2003 R2.

As we move forward setting up things for us, I have tried to include information on likely problems that may be encountered and facts which help understand Server for NFS behavior which sometimes is confusing.

And to keep the post short, I have broken them into pages -

You'll soon discover how Server for NFS makes life easier in heterogeneous environments.

GID on NTFS File System

Ashish — Mon, 16 Apr 2007 23:36:00 GMT

GID on NTFS File System

Can you set group on a file or folder on NTFS file system? - No, ugh... Yes.

This question puzzled me for a long time but since it never really made it to my top priorities, I didn't look up for information on this. I thought of exploring this area more while I was researching something about NFS server.

I started with looking for the utilities (obviously, Windows-based ones) which can set this information for me. My search ended quickly with the chown.exe and chgrp.exe which you can install with Interix/SUA Base Utilities.

Using Process Monitor (replacement of Filemon and Regmon utilities) revealed that group information gets stored on the file system with an IRP_MJ_SET_SECURITY request -

The other interesting fact is this request originating from the POSIX subsystem (psxss.exe) which makes sense because chown.exe and chgrp.exe utilities are POSIX subsystem utilities.

This KB Article says -

In the Windows NT and Windows 2000 NTFS file system, each file also has an owner and a primary group. The primary group of a file is not used by the Win32 subsystem, but is present for programs that make use of the POSIX subsystem. When a file is created, the user who created the file becomes its owner and that user's primary group becomes the file's primary group. Access Control Entries (ACEs) are then added to the DACLs to assign permissions.

That makes it clear that none of other utilities I tried to use, could set this information because they were basically Win32 binaries and Win32 subsystem does not, in anyway, uses this information.

So the best practice would be to set correct primary groups for your users and then use Interix/SUA chown.exe and chgrp.exe utilities to manage them the way you want them to be seen by your UNIX clients.

Additional Note: The ls.exe and chmod.exe are other utilities which can help you do things the UNIX way.

Active Directory Lookup? Or, User Name Mapping? Or Both?

Ashish — Fri, 13 Apr 2007 22:54:00 GMT

Active Directory Lookup? Or, User Name Mapping? Or Both?

User Name Mapping in Windows Server 2003 R2 and Services for UNIX allows you map UNIX user and group accounts to their Windows counterparts (both local and domain accounts). This service is used by Server for NFS and Client for NFS (also by Windows Remote Shell Service in SFU 3.5).

UNIX uses UIDs and GIDs to identify user and group account while Windows uses SIDs. User Name Mapping provides a mechanism for Windows to correctly authenticate users and groups who access Windows NFS shares from UNIX clients or UNIX NFS shares from Windows clients.

This page talks more about why User Name Mapping is required. And, this link explains how NFS authentication works in Service for UNIX and Windows Server 2003 R2.

User Name Mapping is the only way Services for UNIX components can map UNIX UIDs/GIDs to Windows SIDs (and vice versa) but starting with Windows Server 2003 R2 and Windows Vista, Server for NFS and Client for NFS can also use Active Directory Lookup feature to query this information directly from AD. It adds another level of integration with Active Directory and Server for NIS for these components and can help you do away with User Name Mapping and therefore, reducing administrative overhead.

Note: User Name Mapping in R2 is the final release of this component. It’ll not be supported in future releases of Services for NFS.

If you have tried configuring Server or Client for NFS in R2, you might have noticed that you can use Active Directory Lookup and User Name Mapping at the same time.

Why? Don't they do the same thing? Why would I use them both at the same time?

Active Directory Lookup and User Name Mapping - both allow you to map Windows SIDs to UIDs and GIDs (and vice versa). However, there's big difference - User Name Mapping allows you to do advanced mappings where you can map users who have different login names on Windows and UNIX systems. It also allows you to map multiple Windows accounts to a single UNIX account to simplify NFS access.

If you have populated UNIX attributes for all of your user and group accounts in Active Directory, you should use Active Directory Lookup. But, if you still depend on the passwd and group files or UNIX-based NIS servers to determine UIDs and GIDs for user and group accounts, you are good to go with User Name Mapping.

Using both of them makes sense in a situation where you have a mix of Windows accounts with their UNIX attributes saved in AD and still have a need to map with UNIX sources for some of the accounts.

Using them both can also help you slowly move over to Active Directory for storing UNIX attributes.

Word of caution - if you think using both of them is necessary for your setup, take care that you don’t have accounts in AD with one set of UNIX attributes and then also map those same accounts to another set of UNIX attributes using User Name Mapping. That can lead to confusion while you determine effective permissions.

Important: A memory leak in the Lsass.exe process forces Lsass.exe process to use more memory than expected. This can result in domain controllers becoming unresponsive over time and may need a reboot. This problem can be fixed by installing hot fix 931307. Windows Server 2003 Service Pack 2 includes this fix so if you are already on Service Pack 2, you are safe.