Mapping UNIX Passwords to Windows NT User Accounts

At Terra Flora, all user accounts, passwords and permissions have been set up on the computers running Windows NT Server. For details see, Microsoft Windows NT Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User and Group Accounts," and Chapter 3, "Managing User Work Environments."

Additionally, the UNIX /etc/Passwd file has been copied to the proper Windows NT directory WINNT\System32\Drivers\Etc, which makes it accessible to the graphical interface supplied in Integraph's DiskShare. The entries in the UNIX password file will be mapped or matched to user accounts created in Windows NT domains.

Mapping the UNIX user accounts and passwords to a Windows NT User account grants the UNIX user the same rights and permissions to the Windows NT server as the Windows NT user to whose account the UNIX account is mapped.

Note

If the name and password are exactly the same in the UNIX /etc/Passwd file as that stored in the Windows NT Directory Database, mapping is automatic.

Without mappings, server resource access will default to whatever privileges are given to the Everyone user trying to access the group. See your UNIX documentation for more details on UNIX privileges.

To administer UNIX-to-NT user mappings

1. Open the NFS Administrator.

2. Click Mappings.

In the User Mappings dialog box, the users that are currently mapped are listed in NFS Mapped Users.

3. In Network Users, click the UNIX user to be mapped to the Windows NT user.

4. In NT Users, click the Windows NT user to which you want the UNIX Network user mapped.

5. Click Add.

The mapping appears in NFS Mapped Users.

Additional information that appears in the NFS Administrator window includes:

• Network Users, which list user names and user IDs (UIDs) in the format: network user name:UID. This information comes from the UNIX-style password file.
• NT Users, which lists Windows NT user accounts that are local to the domain controller of the specified NT domain.
• List Names From Domain, which lists all NT domains to which the local machine has access. It includes the local machine name, the primary domain, and any domains that trust the primary domain.

Note

Changes made in this dialog box do not take effect until you click OK, to write the new information to the registry.

Online Help is part of the DiskShare product and explains mapping, such as how to map Windows NT User Groups to UNIX Groups and perform reverse mappings. These sections focus on administrative tasks specific to the Intergraph PC-NFS and DiskShare products.

Note

Sharing and unsharing of NFS directories and files requires the same user permissions required by Windows NT Server and LAN Manager. The local user account must be logged on as a member of the Administrators, Server Operators, or Power Users groups.

Sharing NFS Server Resources

Two separate and complimentary mechanisms govern file access through the NFS server. The first is the NFS administrator's ability to control both which server resources are made available as network resources and what access clients within the network will have to the data. The second is the security administration performed by the underlying server file system itself. Effective access permission granted to any user is the more restrictive of these two mechanisms.

Share permissions are the first line of defense for the NFS server. Using share permissions, an administrator can control which network NFS client nodes have read and/or write access to NFS Shared resources. Four levels of access are available depending on the type of object selected, as follows:

• No Access

This prevents all mount or connection requests for the share except for those individual client nodes or client groups that have a type of access specified.

• Read-Only

The client is allowed to mount and read the shared resource, but cannot alter it.

• Read-Write

The client may mount, read and write the shared resource.

• Root

The client may mount, read, write, and perform "superuser" type operations on the file system assuming the requesting User ID is correct for the operation, and that is maps to the Administrator privilege. This access level can only be assigned to individual client nodes or client groups.

To determine if sufficient permission is available for the NFS request, the Global Permission is checked first. If this is not sufficient, an individual client's permission entry is checked. If no individual client permissions are present, then permission is given based on client group access.

File permissions within NFS are very much like those in a UNIX system. Under UNIX, every file belongs to a single user and group; the user must be a member of the group that owns the file. More precisely, a file has a single user ID and a single group ID. Because several different user accounts can have the same user ID, and several groups the same group ID, it may be ambiguous to speak of a particular user or group. The following criteria, in order of decreasing precedence, govern access to files:

• Access granted to the owner of the file, a user with the same effective user ID as the file owner ID.
• Access granted to members of the group to which the file belongs, users can belong to several groups simultaneously.
• Access to granted to all others, such as those who do not own the file and are not members of the group to which the file belongs.

Each permission category controls three modes of access:

• Read, which is the ability to open the file for read access and examine its contents without altering it in any way.
• Write, which is the ability to open the file with write access and update its contents.
• Execute, which is the ability to load the file into the system and run it. For directory files, execute access is interpreted as search permission.

Understanding the Security Descriptor

Intergraph DiskShare uses the Windows NT security descriptor when implementing NFS access permissions. The security descriptor is the structure that governs security within Windows NT. The security descriptor contains the following components:

• File owner.
• File group.
• System Access Control List (SACL). The SACL is used for auditing and does not affect file permissions.
• Discretionary Access Control List (DACL).

The following is an example of a security descriptor:

In this example, the file owner is spike, the file group is UtilGroup, and the DACL shows the permissions given to spike, UtilGroup, and Everyone.

Within the security descriptor, the file owner and file group are pointers to Security Identifiers (SIDs). The SID can be thought of as the internal representation for an individual user or group. The primary reason for using SIDs is to distinguish between accounts across different domains that may share the same account name. Even though the names are the same, they represent different accounts and can thus be given different access rights to the same file.

Understanding the DACL

The Discretionary Access Control List (DACL) within the security descriptor provides the core of Windows NT security. The DACL is a list of entries that grants or denies certain rights to specific users or groups. A list entry is called an Access Control Entry (ACE). Each ACE consists of the following:

• A Security Identifier (SID) to identify a particular user or group.
• An access list specifying the rights allowed or denied for the user or group.

The following is an example of a DACL:

In this DACL, mrjones has read, write, and execute access to the file; members of the group ToolGroup have read and execute access, and members of the group Everyone (all other users) have read and execute access.

The following rules govern access to a file:

• If no DACL is present, everyone is granted full access.
• If a DACL is present, but contains no entries, everyone is denied any access.
• The file owner always has the ability to change the DACL.

Reverse Mapping Permissions

The function of Intergraph DiskShare is to translate between a security descriptor on the computer running Windows NT Server and Intergraph DiskShare and a (UID, GID, mode) triplet on the NFS client.

Intergraph DiskShare controls permission translation with reverse mapping. Intergraph DiskShare's NFS Administrator program allows the DiskShare administrator to specify a mapping between NFS User and Group IDs and their corresponding Windows NT users and groups.

• A given UID can be mapped to any Windows NT user.

Because multiple UIDs can be mapped to the same Windows NT user, one of the mappings will be marked as the default mapping. The default mapping is the UID to be returned when the mapped Windows NT user is found to be the file owner.

If the given UID is not mapped, the ANONYMOUS LOGON account will be used. This can have some undesirable results, so we recommend that all UIDs be mapped to a valid Windows NT account.

• A given GID can be mapped to any Windows NT group.

Note If the given GID is not mapped, no group will be assigned, and no group entry will be placed in the DACL.

You can use the reverse mapping feature when mapping from NFS to Windows NT, or from Windows NT to NFS.

Sharing Files and Directories on a NFS Server

Once the DiskShare product is installed, the ability to share the NFS server files and directories and grant permissions to the users is provided through the computer running Windows NT Server.

To share files and directories on a NFS Server

1. Click Start, and then click Run.

2. In Open, type winfile, and then click OK.

3. On the Disk menu, click Share as.

4. Click NFS, and then click OK.

5. In the New NFS Share dialog box, type the path of the file you want to share.

6. Click Permissions.

The NFS Share Permissions dialog box appears.

7. Enter the settings you want for Anonymous UID and Type of Access, and then click Add.

8. Under Names in the Add Clients and Client Groups dialog box, click the user to be granted access.

9. In Type of Access, click the setting you want, and then click OK.

UNIX Client Sign On

Once the above steps are performed, the UNIX client is mapped with the proper permissions to the computer running Windows NT Server. When the UNIX client signs onto the server, authentication is provided via pcnfsd on the UNIX server to Windows NT User Account.

From the UNIX client, create a local directory as a mount point. Then mount the exported directory to a local directory.