Welcome to Microsoft Services for Network File System

Microsoft Services for Network File System

Microsoft Services for Network File System makes it easy to integrate Windows operating systems into existing UNIX environments. It provides interoperability components that leverage existing UNIX network resources and expertise within your organization. It also provides manageability components that simplify account management across both platforms.

With Microsoft Services for Network File System, you can:

  • Use the network file system (NFS) protocol to share files between Windows and UNIX computers.
  • Provide Windows and UNIX users "single sign-on" capability by mapping authentication credentials between operating systems.

To learn more about Microsoft Services for Network File System, see Getting started.

Copyright© 1998-2003 Microsoft Corporation. All rights reserved.


Getting started

Microsoft Services for Network File System components provide file-sharing interoperability between Windows Server 2003 and UNIX platforms. UNIX clients can access files on the Windows Server 2003 computer using Network File System (NFS). User Name Mapping associates Windows user and group accounts with UNIX accounts, allowing UNIX users to access files on the Windows server without logging on to the Windows server.

  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For information about copyrights and product support options, see Copyrights and product support.

Microsoft Services for Network File System consists of the following components:

  • Server for NFS
  • Server for NFS Authentication. For more information, see Understanding Server for NFS Security.
  • User Name Mapping


How to ...

  • Allow anonymous access by Everyone under Windows Server 2003


Allow anonymous access by Everyone under Windows Server 2003

To allow anonymous access by Everyone under Windows Server 2003

  1. Click Start, point to Control Panel, point to Administrative Tools, and then click either Local Security Policy or Domain Security Policy (on a domain controller).
  2. In Security Settings, double-click Local Policies, and then click Security Options.
  3. Right-click Network access: Let Everyone permissions apply to anonymous users, and then click Properties.
  4. To allow permissions applied to the Everyone group to apply to anonymous users, click Enabled.

    Or, to prevent permissions applied to the Everyone group from applying to anonymous users, click Disabled.

Note

  • There is no command-line method for this procedure.

Related Topics

Anonymous users and Windows Server 2003


Concepts

This section provides general background information about Microsoft Services for Network File System.

  • Microsoft Services for Network File System overview
  • Understanding Microsoft Services for Network File System


Microsoft Services for Network File System overview

Microsoft Services for Network File System provides a comprehensive set of services and tools that make it easy to integrate computers running UNIX into your existing Windows network. Microsoft Services for Network File System supports flexible file sharing between Windows-based and UNIX-based computers.

Microsoft Services for Network File System contains the following components:

User Name Mapping. This component provides centralized mapping between Windows user accounts and UNIX accounts for Server for NFS. With User Name Mapping, UNIX users can access files on Windows computers transparently and without compromising security. User Name Mapping can use UNIX accounts from Personal Computer Network File System (PCNFS) servers or NIS servers.

Server for NFS. The administrator of a Windows computer can use Server for NFS to share directories as NFS exported file systems. This makes it possible for UNIX-based clients to mount a shared directory just as they would an exported file system located on a UNIX server. User-level security is maintained because, in conjunction with Server for NFS Authentication, User Name Mapping maps the UNIX client's user identifier (UID) and group identifier (GID) to existing Windows user accounts. This ensures that UNIX clients are given appropriate access to files on Windows-based servers.


Understanding Microsoft Services for Network File System

This section provides information about:

  • Understanding Windows and UNIX file system security
  • Anonymous Users and Windows Server 2003


Understanding Windows and UNIX file system security

Windows and UNIX both let you control access to your files and directories. The method for doing so differs greatly, however. Generally speaking, the UNIX system is simpler and more limited, while Windows file security is considerably more complex and flexible.

In UNIX, the directory entry for each file or directory includes a bitmap of 12 bits, known as file-mode bits. Of these, three bits control access by the file's owner, three bits control access by the owner's primary group, and three control access by everyone else.

In Windows, files and directories on NTFS partitions are protected by a discretionary access control list (DACL) consisting of one or more access control entries (ACEs). Each entry assigns or denies permissions to a user or group; unlike with UNIX, however, the number of permissions that can be granted or denied is quite extensive, and provides for a much finer degree of control over the access allowed to the user or group. In addition, ACEs can be added to the DACL for any number of users or groups, allowing the file's owner complete control over who can and cannot access the file. For more information about how Windows file-system security works, see Windows Help.

Microsoft Services for Network File System gives users of UNIX computers the ability to access files on Windows servers running Server for NFS. Because the same file can be accessed by both Windows and UNIX users, it is important to understand how UNIX file security and Windows file security interact through Microsoft Services for Network File System. The remainder of this topic describes how Windows permissions are represented using UNIX file-mode bits, and how UNIX file-mode bits are represented by Windows DACLs.

Representing Windows permissions using UNIX file modes

A UNIX client examining the security on a file shared through Server for NFS cannot see the complete protection provided the file by Windows file security. This is because the UNIX file-security system is much simpler and so is unable to represent the depth of access control provided by the ACEs in the file's DACL. Instead, Microsoft Services for Network File System presents a simplified view of the DACL that is consistent with UNIX conventions.

The following describes how this simplified view is constructed:

  • ACEs that affect the file's owner, Everyone, and Authenticated Users are used to determine the file-mode bits that are set for the owner. Consistent with Windows security, the most permissive entry is used unless an access mode is explicitly denied. For example, if the owner is not given (but also not denied) write permission for the file, but Everyone is granted write permission, then Microsoft Services for Network File System will show the write-access bit set for the owner. On the other hand, if Everyone is denied write access, then the write-access bit will not be set for the owner. Unlike in Windows, groups to which the owner belongs are not used to determine the owner's permissions.
  • ACEs that affect the owner's primary group, Everyone, and Authenticated Users are used to determine the file-mode bits that are set for the owner's UNIX group, again using the most permissive entry unless an access mode is explicitly denied. Other groups (including parent groups of the owner's primary group as well as any other groups to which the owner belongs) are ignored.
  • ACEs that affect Everyone and Authenticated Users are used to determine the file-mode bits for other users, again using the most permissive entry unless an access mode is explicitly denied.
  • ACEs for users and groups other than those representing the file's owner, the owner's primary group, and Everyone are ignored. For example, if the owner belongs to a group that has an access permission not granted the owner, the corresponding file-mode bit is not set for owner.

Representing UNIX file modes using Windows permissions

As noted previously Windows DACLs provide a much finer level of access control that does UNIX. As a consequence, Microsoft Services for Network File System represents a single UNIX file-mode bit using multiple permissions in the relevant ACEs in a file's DACL. The following describes how access bits are mapped to Windows permissions:

  • For owner, group, and everyone, if a file-mode bit is set, then the corresponding Windows permissions are granted. If owner is denied an access permitted to either group or everyone, then the file's owner is explicitly denied that access by Windows. If owner, group, and everyone are all denied access, the file's owner is not explicitly denied access, but is not granted access either.
  • Regardless of the UNIX file-mode settings, the file's owner, primary group, and Everyone always receive permissions for Read Attributes, Read Extended Attributes, and Read Permissions for the file. In addition, the file's owner also receives permissions for Write Attributes, Write Extended Attributes, Delete, Change Permissions, and Take Ownership for the file.
  • The UNIX read bit is represented in Windows as the List Folder/Read Data permission.
  • The UNIX write bit is represented in Windows as the Create File/Write Data, Create Folders/Append Data, Write Attributes, and Delete Subfolders and Files permissions.
  • The UNIX execute bit is represented in Windows as the Traverse Folder/Execute File permission.

Additional considerations

You should take care when using UNIX utilities such as chmod to change permissions for a file stored on an NTFS partition. Doing so will overwrite the file's DACL with a DACL consisting of ACEs for the file's owner, primary group, and Everyone.

If you use UNIX utilities such as cp to create a file on an NTFS partition, the file does not inherit its permissions from the folder as is typically the case when a file is created using a Windows program. Instead, permissions are applied as described above.

The setuid, setgid, and sticky file-mode bits can be set and queried on files stored on NTFS partitions.


Anonymous users and Windows Server 2003

On computers running Windows Server 2003 and later versions of Windows, the Everyone group no longer includes anonymous users by default. This change reduces the number of network resources available by default to anonymous users and simplifies how network administrators can control access by anonymous users. It is easier for administrators to configure a secure system due to the following:

  • The default access control lists on earlier versions of Windows that granted the Everyone group access to resources and potentially exposed them to attack does not grant this access to anonymous users after the computer has been upgraded to Windows Server 2003 or later versions of Windows.
  • Anonymous users cannot be accidentally granted access to resources as in the past when administrators did not realize that anonymous users were included in the Everyone group.

You can still allow anonymous access to selected shared directories and files by adding the Anonymous Logon group to the discretionary access control lists protecting those resources.

In some situations, it might be difficult to determine which resources must grant anonymous access or to modify the permissions on all the necessary resources. If so, you can configure Windows Server 2003 and later versions of Windows to permit anonymous access by the Everyone group. For more information, see To allow anonymous access by Everyone under Windows Server 2003.


Copyrights and product support

This section provides information about:

  • Copyrights
  • Product support


Open Windows Explorer

To open Windows Explorer

  • Click Start, point to All Programs, point to Accessories, and then click Windows Explorer.


Copyrights

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

The links in this area will let you leave Microsoft's product and/or Web site. The linked sites are not under the control of Microsoft and Microsoft is not responsible for the contents of any linked site or any link contained in a linked site, or any changes or updates to such sites. Microsoft is not responsible for webcasting or any other form of transmission received from any linked site. Microsoft is providing these links to you only as a convenience, and the inclusion of any link does not imply endorsement by Microsoft of the site.

For your convenience, Microsoft may make available on this service or in its software products, tools and utilities for use and/or download. Microsoft does not make any assurances with regard to the accuracy of the results or output that derives from such use of any such tools and utilities. Please respect the intellectual property rights of others when using the tools and utilities made available on this service or in Microsoft software products.

© 1998 - 2003 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, MS, Windows, Windows NT, Win32, Active Desktop, Active Directory, ActiveMovie, ActiveX, Authenticode, BackOffice, Direct3D, DirectAnimation, DirectDraw, DirectInput, DirectMusic, DirectPlay, DirectShow, DirectSound, DirectX, DoubleSpace, DriveSpace, FrontPage, IntelliMirror, IntelliMouse, JScript, Microsoft, Microsoft Press, Microsoft QuickBasic, MSDN, MS-DOS, MSN, Natural, NetMeeting, OpenType, Outlook, PowerPoint, SideWinder, Visual Basic, Visual C++, Visual FoxPro, Win32, Windows, Windows Media, Windows NT, and Wingdings are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.