NFS Documents Index

Pricing and Order
Choosing best product
DiskAccess
DiskAccess Lite
DiskAccess TS
DiskShare

More products...


DiskAccess Frequently Asked Questions

Tech Tips and TCP/IP Basics for DiskAccess on Windows NT4.0 and Windows 2000/XP

Quick Start Guide for DiskAccess

Configuring Credentials for DiskAccess’ RSH Server

Tech Tips and TCP/IP Basics for DiskAccess on Windows 95 and Windows 98

Tips For Capturing a Network Trace

DiskAccess and AccessNFS Gateway Printing

Tech Tips on Symbolic Links for DiskAccess and AccessNFS Gateway


free download Free to try

Order Network File Sharing products Buy Now


The Effect of Windows Security Policies on NFS Client Users

The ability of NFS users to access files and directories shared to the network by DiskShare depends greatly on a number of factors.  One such factor is the security policies set on the Windows system that runs DiskShare.  Although DiskShare provides tools that allow administrators to map NFS client users and groups to corresponding Windows users and groups, there may be instances when unmapped users may need to access the NFS resources.  The unmapped users may be denied access to the NFS resources because of security policies set on the Windows system running DiskShare.  The security policies not only affect DiskShare but also all programs that may need to access the system from the network.  The default security policies for a system running Windows XP or Windows 2003 server will prohibit unmapped users from gaining access to the NFS resources.  Additionally, Windows 2000 Professional and Server's security policies can be configured in a way that will deny access to unmapped users.  This document will examine the security policies and how DiskShare administrators can work within the security policies.

Background

NFS was developed so that users on UNIX systems could share files and directories across the network.  A unique identification number called the User Identification or UID for short represents UNIX users.  UNIX users can also be grouped together into groups that also have a unique identification number called the Group Identification or GID for short.  Due to a number of reasons, NFS has become the de facto standard for sharing files and directories across the network and has consequently been developed to run on other operating systems besides UNIX.  However, regardless of the operating system running NFS there has always been a need the operating system to represent its users and groups in the form of UIDs and GIDs.

DiskShare provides tools that allow Windows system administrators to map NFS client users and groups to corresponding Windows users and groups.  The DiskShare User Manager provides the traditional graphical mapping ability while the dsmap.exe utility provides the command line mapping ability.  Without going into great detail, once users and groups have been mapped, DiskShare will know how to equate file and directory access rights to requesting NFS client users.  However some NFS client users may not be mapped.  Any unmapped user will be represented to the Windows operating system as an anonymous user.  The anonymous user is a member of the Windows built-in group Everyone.  DiskShare translates the Everyone group to be equivalent to the UNIX world group.  The unmapped user's access to NFS provided files and directories will therefore be based on whatever the world group access rights are reported back by the DiskShare NFS server.  Consequently the world group access rights to the NFS client will be whatever access rights the Windows built-in group Everyone happens to have with a file or directory. 

Within the Windows operating system, access to anything is based on a user's access rights or the access rights of the groups in which the user may be a member.  Access rights are assigned to files and directories.   When a NFS client user attempts to access a file or directory that is being provided by DiskShare, DiskShare will translate the user's UID to the corresponding Windows identity based on the user mapping information.  DiskShare will then send the request to the Windows file system on behalf of the NFS client user.  The access rights assigned to the file or directory will determine NFS client user's privileges to the file or directory.

The Problem

Although the access rights assigned to a file or directory will determine whether or not a NFS client user has privileges to the resource, the Windows security policies on the system can also affect the ability of a user to gain access to the resource.  This becomes especially acute for unmapped users who are represented to the Windows system as an anonymous user and therefore rely on the access rights of the Everyone Windows group.  More to the point, anonymous users who are accessing NFS provided resources on a Windows XP or Windows 2003 Server system will have no access rights to the NFS resources.  The anonymous users will also be denied access to any Windows resources too.

Windows XP and Windows 2003 Server Security Policies

The Anonymous user is often a member of the Windows built-in group Everyone.  With the advent of Windows XP and Windows 2003 Server, the anonymous user is no longer a member of the Everyone group.  The exclusion from the Everyone group is a default security policy for these operating systems.  Due to this security policy and the fact that DiskShare relates the Windows Everyone group to the world group on the NFS client, any unmapped NFS users will no longer be able to access the NFS provided resources.  An unmapped NFS client user will not be able to list, read, or write NFS provided files or directories.  The formal name of the security policy is "Network access: Let Everyone permissions apply to anonymous users".

The Local Security Policy manager located in the Administrative Tools program group, allows administrators to manage the policies.  Domain policies can take precedents over local policies and may affect the effective policy of the system.  The highlighted policy in Figure 1 illustrates Windows XP or Windows 2003 Server security policy mentioned above.

The Effect of Windows Security Policies on NFS Client Users

To a lesser extent the "Access this computer from the network" user right policy and the "Accounts: Limit local account use of blank passwords to console logon only" security policy impact the ability of unmapped users to access NFS provided resources.  These policies are highlighted and are illustrated in figures 2 and 3.

The Effect of Windows Security Policies on NFS Client Users 2

The Effect of Windows Security Policies on NFS Client Users 3

If unmapped users must have access to NFS resources then the administrator will have to make  changes to the system's security policies by enabling the "Network access: Let Everyone permissions apply to anonymous users" policy and disabling the "Accounts: Limit local account use of blank passwords to console logon only" policy.  The administrator should consult their Microsoft provided documentation prior to making any security policy changes.  The recommended procedure is to map all NFS client users and groups to corresponding Windows users and groups and thereby avoiding the need to handle the case of unmapped users.

Windows 2000 Professional and Windows 2000 Server

Although the anonymous user is a member of the Everyone group for Windows 2000 Professional and Windows 2000 Server, administrators can configure their security policies so that the anonymous user is no longer a member of the Everyone group and will cause unmapped NFS client users not to be able to gain access to the DiskShare provided resources.  The Microsoft knowledge base article Q246261 titled "How To Use The RestrictAnonymous Registry Value in Windows 2000" informs administrators how to set the security policy.  The formal name of the security setting is "Additional restrictions for anonymous connections".  When the security policy is set, it will look like the Figure 4 illustration.

The Effect of Windows Security Policies on NFS Client Users 4

Unmapped users will be able to access NFS provided resources by default.  However, if the system has been secured by setting the "Additional restrictions for anonymous connections" policy to "No access without explicit anonymous permissions" and unmapped users need to access the NFS provided resources then the security policy will have to revert back to the default setting.  The recommended procedure is to map all NFS client users and groups to corresponding Windows users and groups and thereby avoiding the need to handle the case of unmapped users.