Hp NETSTORAGE 6000 File Sharing Security

Download

File Sharing Security

on the

hp surestore

netstorage 6000

White Paper

Table of Contents

1 Introduction__________________________________________________ 4 2 Security on UNIX Networks ______________________________________ 4

2.1 General Overview ___________________________________________ 4

2.2 Restricting User Access ________________________________________ 5

2.3 Restricting Host Access ________________________________________ 6

2.4 Considerations for the HP NetStorage 6000 _________________________ 6

2.4.1 Trusted Hosts __________________________________________________________6

2.4.2 The /etc Directory ______________________________________________________7

2.4.3 The /etc/approve File ___________________________________________________7

3 Security on Windows Networks ___________________________________ 8

3.1 General Overview ___________________________________________ 8

3.2 Share Level Security __________________________________________ 9

3.3 User Level Security ___________________________________________ 9

3.3.1 NT Domains __________________________________________________________ 10

3.3.2 User Authentication _____________________________________________________ 12

3.3.3 Password Maintenance and Encryption _____________________________________ 13

3.3.4 Security Descriptors_____________________________________________________ 14

3.4 Considerations for the HP NetStorage 6000 ________________________ 16

3.4.1 Share Level Security ____________________________________________________ 16

3.4.2 User Level Security _____________________________________________________ 16

3.4.3 DOS attributes ________________________________________________________ 17

4 Security on Mixed (UNIX/Windows) Networks_______________________ 17

4.1 General Overview __________________________________________ 17

5 File Sharing Configuration ______________________________________ 18

5.1 File Volume Permissions _______________________________________ 18

5.2 Mapping Strategies _________________________________________ 19

5.2.1 User Mapping_________________________________________________________ 20

5.2.2 Group Mapping_______________________________________________________ 20

6 Mapping Clients _____________________________________________ 20

6.1 Mapping Files _____________________________________________ 21

6.2 Establishing a Windows Client__________________________________ 22

6.3 Establishing a UNIX Client_____________________________________ 24

7 Examples___________________________________________________ 24

7.1 Client with both UNIX and Windows Account________________________ 24

7.2 UNIX File Accessed by Windows Clients ___________________________ 25

7.3 Windows File Accessed by UNIX Clients ___________________________ 26

8 File Format Details ____________________________________________ 27

8.1 HP NetStorage 6000 Files - passwd, group, users.map, group.map_________ 27

8.2 UNIX Files - passwd.nis and group.nis _____________________________ 28

9 Acronyms __________________________________________________ 28

1 Introduction

One of the most important aspects of serving data to clients over a network is the security mechanisms employed by the server to protect the data from accidental or malicious tampering. The HP NetStorage 6000 is a (NAS) Network Attached Storage Device with capabilities to serve files to Windows clients and UNIX/Linux clients using the native file serving protocol of each client. The HP NetStorage 6000 server has extensive security features built-in that leverage or extend the security mechanisms detailed in the specifications of each of these file serving protocols. In addition, the HP NetStorage 6000 is capable of mapping the security features of one protocol to the other. This feature allows files to be safely accessed through both protocols.

On a network of UNIX clients, the HP NetStorage 6000 provides a native interface to the files on the NAS device through the Network File System (NFS). The NFS protocol is the native file serving protocol of UNIX networks and integrates seamlessly with the established features of UNIX security and file locking. The HP NetStorage 6000 is capable of serving files via NFS to a variety of UNIX and Linux clients.

On a network of Windows clients, the HP NetStorage 6000 provides a native interface to the data on the server through the Common Internet File System (CIFS). This protocol is also commonly known as Server Message Block (SMB). The HP NetStorage 6000 offers a mature and robust implementation of the CIFS protocol, complete with the security mechanisms normally found on Windows servers. The HP NetStorage 6000 is capable of securing file access to Windows clients in a variety of ways, depending on the security requirements of the network.

The HP NetStorage 6000 is capable of serving the same files over either the NFS or CIFS protocol. File servers that can serve multiple protocols are commonly referred to as “Heterogeneous File Servers”. This capability adds a new dimension to the security issue in the nature of mapping the security parameters from one file system protocol to another. Although NFS and CIFS are both designed to serve files over a network, the methods by which they protect their data from unauthorized access are very different. The HP NetStorage 6000 addresses this issue by mapping the access information as needed, to determine the appropriate access to grant the user.

This document describes the general security aspects of the NFS and CIFS file serving protocols, including special considerations on how they are implemented on the HP NetStorage 6000. In addition, the security issues involved with offering files through both protocols on a server are covered in detail. Finally, the solutions implemented on the HP NetStorage 6000 to address the multi-protocol security problems are presented.

2 Security on UNIX Networks

2.1 General Overview

UNIX users gain access to remote resources on a network by mounting remote file systems (using the ‘mount’ command). Accessing remote file systems is accomplished over the network via the Network File System (NFS) protocol. Remote file systems attach themselves to the directory tree of the local file system at a specified location. The user interacts with the remote file system in the same way as the local file system.

There are two methods for restricting access to remote file systems on UNIX Networks. The first method involves restricting access to individual resources (files and directories) to specific users or groups of users on the network. The second method involves restricting resources to specific hosts (computers) or groups of hosts on the network.

2.2 Restricting User Access

All users on UNIX systems must perform a logon sequence before gaining access to the system. The logon involves entering an appropriate name and password at the logon prompt. Once the logon data is entered, the system searches the local passwd file for a matching entry. If a match is found, then the user is granted access, and is assigned two 16 bit numeric identifiers that are associated with the user. These identifiers are referred to as the UID (user ID), to specifically identify the user, and the GID (group ID) to specifically identify the group that the user belongs to.

The UID and GID of a user governs all access to files and directories available to the user, including remote file systems that the user mounts for access via the NFS protocol. All files and directories on UNIX style file systems contain a small amount of metadata that identify who has access rights to the file. This metadata that is associated with file security is defined as follows:

UID This is the identifier of the owner of the file

GID This is the identifier of the group owner of the file

Permission bits These bits identify the read, write and execute (rwx) privilege for the file’s owner, the

file’s group and anyone else who is not the owner or in the group (referred to as other).

For example, a typical UNIX file permission might appear as follows in a directory listing:

-rwxr-x--x 1 Wilson Engineering 611 Nov 11 11:09 testfile

In this case ‘Wilson’ is the UNIX account that the file belongs to. Even though the metadata of the file stores the UID of the owner, the Operating System was able to map the UID to the user name ‘Wilson’ in the passwd file for display. The file also belongs to the group ‘Engineering’. The first field in the entry displays the permission bits. In this case, the owner, ‘Wilson’, has read, write and execute (rwx) permissions. Users that belong to the group ‘Engineering’, have read and execute (r-x) permission. All other users have execute only (--x) permission.

When a user attempts to access a file, the file system first categorizes the user as either owner, group, or other, based on matching the file UID and GID to the users UID and GID. Once the user is categorized, then the permission bits of the category are examined to determine the allowed access.

An extension of this security system is the Network Information Services (NIS). The NIS service automatically distributes centrally maintained system files to all of the host systems on the network. This allows security files, such as the passwd file, to be maintained centrally. Using this service, users need not create and maintain a separate account on each host. In fact, security can be enhanced by preventing users from creating and managing local accounts on each host. NIS also prevents the same UID number being assigned to several different users, which could be problematic in network file storage.

One of the weaknesses of this security system is that individuals on other UNIX host systems, that have root access to their own system, can easily create local accounts that can have any UID they desire. Thus, unscrupulous users can impersonate other accounts when accessing remote resources. To address this security weakness, a second mechanism may be employed that restricts host access to remote resources.

2.3 Restricting Host Access

Since NFS servers do not distinguish between computers that are part of a secure network infrastructure (complete with NIS centralized administration), and computers that exist outside of the sphere of administrator control, a mechanism is needed to protect servers from unauthorized access. In typical UNIX installations, NFS mount points on servers are listed in the /etc/exports file. The mount points listed in the /etc/exports file may also contain restrictions on the clients that can mount the file system. This mechanism can be used to supply added protection to resources on NFS servers.

2.4 Considerations for the HP NetStorage 6000

The HP NetStorage 6000 utilizes an internal file system that is native to UNIX environments. As such, it has UNIX security mechanisms built-in, that may be leveraged when serving files over the NFS protocol. All resources stored on the file system contain the security metadata noted in the previous sections.

The HP NetStorage 6000 does not support the concept of the /etc/exports file for managing mount points. Instead, the NAS device automatically creates a single mount point at the root of all volumes created on the system. Since the NAS device is specifically designed to share files, the exporting of mount points has been automated.

The root directory of the mount points on the HP NetStorage 6000 are given special permissions to facilitate appropriate access to users. The owner and group of this directory are root (UID = 0, GID = 0), and the permissions are read, write, and execute to owner, group and other (rwxrwxrwx). One consequence of this setting is that all users can delete any file in the root of the mount point. Therefore, administrators are encouraged to avoid storing files in the root of the mount point.

The group assignment to files created in a file volume on UNIX can be performed in a variety of ways. On the HP NetStorage 6000, when a new file is created, the group assignment is inherited from the directory where the file is created. For example, if the group owner for directory /acct/usr is accountants (GID = 501), then all files created in that directory will be assigned a group owner of accountants (GID = 501).

2.4.1 Trusted Hosts

All UNIX clients that mount to file systems on the HP NetStorage 6000 use the UID and GID of their account, when accessing files. A special case is the root user (UID = 0). In UNIX, the root user is a Super User, with full access to all files and directories in the file system. Due to the extensive rights provided to the root user, and the extensive damage that can be done by a malicious root user, the HP NetStorage 6000 does not trust them by default. Clients that attach with root privilege are given access as user ‘nobody’ (UID = 60001), with no special rights or privileges.

The administrator can override this default behavior by declaring a particular client to be a Trusted Host. A root user mounting a HP NetStorage 6000 file system from a client that is a Trusted Host will be given root privilege (UID = 0) to the file system. This feature allows administration of the file system by a root user, while at the same time, protecting the file system from other root users that should not have privileged access to the HP NetStorage 6000 file systems.

The administrator may declare Trusted Hosts using the web based administration tool, or the telnet administration tool of the HP NetStorage 6000.

2.4.2 The /etc Directory

It is necessary to maintain a number of system files on the HP NetStorage 6000 in an accessible place for administrative purposes. Some of the more common files found in this directory are as follows:

hosts Host name resolution group Define local group accounts passwd Define local user accounts hostgrps Define groups of host computers approve Restrict host access

These files are all stored in the /etc directory on the first volume created on the system. The files in the /etc directory are for system management purposes and cannot be deleted. If the volume that stores the /etc directory is ever deleted, then the system moves the contents of this directory to another available volume.

Of the files listed above, the hosts file, the group file and the passwd file may be edited through the web based user interface, or the telnet interface of the HP NetStorage 6000. In some cases, it is necessary to edit these files directly using a text editor. By default, all files in the /etc directory belong to the root user, and may only be edited by the root user. Therefore, the only way to edit these files directly (using a text editor) is to mount the file system as the root user from a Trusted Host (discussed in the previous section).

Important Note: The HP NetStorage 6000 does NOT authenticate UNIX accounts and thus does not use the passwd file, the group file, or the equivalent security files from NIS for authentication or account name resolution. The only reason to store and maintain these files is to map UNIX users to NT users. If the NAS device is not used for NT access, or if the storage for NT users and the storage for UNIX users are kept separate, then there is no need to maintain these files.

2.4.3 The /etc/approve File

Since the HP NetStorage 6000 does not support the /etc/exports file, support has been added for a file named /etc/approve. This file can be used to restrict NFS access to particular clients on the network.

Currently, the administrator has a limited ability to indirectly edit the /etc/approve file using the web based administration tool. Each volume on the server allows general UNIX access settings of No Access, Read Only or Read/Write. These settings apply to all clients accessing any resource on the volume.

In order to restrict individual clients and groups of clients to specific resources on the HP NetStorage 6000, the /etc/approve file must be edited manually. Entries in the /etc/approve file have four fields. These fields are defined as follows:

class This field specifies the class of object to protect. In all cases, the object is ‘files’.

specifier This field specifies the resources on the HP NetStorage 6000 to protect. For example,

‘/engineering’, applies to all files and directories in the /engineering file system.

host pattern This field has the name of a host or group of hosts that have access rights. Host names must be

resolvable through the local /etc/hosts file, the NIS hosts file, or through DNS. Groups of hosts are specified in the /etc/hostgrps file. If the host pattern is the name of a group, then it must be preceded by the @ symbol. The wildcard character ( * ) may be used to specify all hosts.

rights This field specifies the access limits to apply. The entry in this field can be one of the following:

access=rw Allow read and write access to the resources access=ro Allow read only access to the resources access=none Deny all access to the resource

Following is a list of example entries in the /etc/approve file:

#class specifier host pattern rights files /acct/usr @executive access=rw files /acct/etc it1 access=rw files /acct/etc it2 access=rw files / @untrusted access=none files /acct/usr/theList.txt guest access=ro

The first entry allows read/write access to all client systems defined in the ‘executive’ group (listed in the /etc/hostgrps file) to all files and directories under the /acct/usr directory. The second and third entry allows read/write access to the machines ‘it1’ and ‘it2’ to all files and directories in the /acct/etc directory. The fourth entry denies all access on all file systems to any machine in the ‘untrusted’ group. The last entry grants specific read only access to a single file for any user on the ‘guest’ machine.

Note that the file is searched sequentially for a match. Once an entry is found that matches the host and the resource to restrict, then all other entries are ignored.

3 Security on Windows Networks

3.1 General Overview

Two distinct mechanisms are used on Windows networks to provide security for resources. They are known as “Share Level Security” and “User Level Security”.

The simplest and least secure mechanism is known as Share Level Security. This security mode allows each network share to be protected with a password. Although the mechanism is very limited, it is useful on small networks that utilize peer-to-peer networking. Share Level Security is the default security mode of Windows for Workgroups, Windows 95 and Windows 98.

User Level Security is more complex to implement, but is easier for the end user, and more flexible in terms of what can be protected and how. In this mode, each user is provided a logon account, and must be authenticated on that account before gaining access to resources on a computer. This security mode is most appropriate in client-server based networks. User Level Security is the default security mode of Windows NT and Windows 2000.

The following sections explain these security modes in more detail.

3.2 Share Level Security

Share Level security is the simplest SMB security mode to use, but offers the least security. In this mode, each share may be protected by a password. When the server administrator defines a new share, a password is specified to protect the share from unauthorized access. When a user first accesses the share, the user is prompted for the password. Once the password is entered and verified, then the user has full access to all files on the share. Share Level security is the default security mode for Windows for Workgroups and Windows 95.

Share Level security may be implemented to allow both Read/Write access, as well as Read Only access to shares. Each share may be protected by one Read/Write password and one Read Only password. The access allowed on the share (Read/Write or Read Only) is dictated by the password entered by the user.

This mechanism is sufficient in small networking environments. However, in large environments, the model breaks down. If a different password is used to protect each share, and if many shares are defined on a network, then managing and remembering all those passwords becomes extremely difficult. In addition, the granularity of protection extends only to the share. Any user that has access to the share, has access to all of the files in the share. There is no way to limit access to individual files within a share.

In most cases, when a user enters a password to access a share, the client system creates a session with the server that may extend beyond the expected interval. For example, if a user accesses a share via Network Neighborhood (and providing the correct password), closes the Explorer window, and then returns to the share at a later time, the user may not be prompted again for the password, since the original session is still active. In addition, the client system may cache the password, and submit it again automatically on behalf of the user when a session is ended and a new one is activated with the same share. To summarize, users should not expect to have to enter in the password to a share more than once in a typical Windows session.

3.3 User Level Security

User Level Security offers the superior flexibility and ease of use on networks with a significant number of users and/or resources. In this mode, each user is provided a logon account to a computer or network. The user only has to remember the credentials for this one account, instead of numerous passwords for network shares. Resources can be protected with a much finer granularity. Not only can shares be protected, but directories and individual files may be protected as well. Also, each resource may be protected on a user by user basis that allows almost infinite permutations of access restrictions of users and groups of users. User Level Security is the default security mode of Windows NT systems.

The user accounts may be either local machine accounts for access to a single computer, or they may be accounts that apply to all computers attached to the network. If a computer is attached to a network, then local machine accounts are of little value, since the user of that account may only access resources on that computer, and not any other computer on the network. On the other hand, network wide accounts allow users to access resources on other computers on the network. In addition, these accounts allow the user to logon to any computer on the network.

On NT networks, the network wide user accounts are managed through NT domains. The architecture of NT domains is discussed in the next section.

Under User Level security, each computer on the network is responsible for authenticating users, before the user is allowed to access the resources on that computer. Once a user is authenticated on a computer, a session is established with the user. Thus, the user will not need to be authenticated again during that session. This not only applies to users accessing machines directly (interactive logon), but also to users accessing resources on remote servers (remote, or network logon).

Interactive logon is a very common experience for most users. Every time a Windows NT computer boots, a user must logon to the system before gaining access to any resource. The user is prompted to press Ctrl-Alt-Del and then enter a name, password and NT Domain name at the console of the local computer. Once the user is authenticated with these credentials, then the user is allowed access to the resources of the computer.

Remote logon is not as obvious to most users. When a user attempts to access files on a remote computer (such as through Network Neighborhood, or by mapping a network drive to a drive letter), the remote computer must first authenticate the user before allowing access, even though the user has already logged onto the local system. Unlike the interactive logon, remote logon usually occurs automatically, without user interaction. The local computer will offer the account name and password from the interactive logon as credentials to logon to the remote computer.

3.3.1 NT Domains

NT Domains provide the means of authenticating users on a network, both for interactive logon, as well as remote logon. In addition, NT Domains are used to group together and manage resources on a network. An NT Domain is defined by one or more NT servers acting in the role of a Domain Controller. The NT Domain must have one and only one server configured as the Primary Domain Controller (PDC). All other Domain Controllers in the domain must be Backup Domain Controllers (BDC). All Domain Controllers store a current copy of the Security Accounts Manager (SAM) database, and use this database to authenticate users. The domain administrator manages the SAM database from the Primary Domain Controller. Backup Domain Controllers manage a read-only version of the SAM database, replicated from the PDC. The purpose of having multiple Domain Controllers in a domain is for redundancy and load balancing.

One important aspect of NT Domains is the concept of Trust relationships. One NT Domain may be configured to “Trust” another NT Domain, so that the first domain trusts the members of another domain. Trust relationships are one way. Domain A can be configured to trust Domain B, but the reverse would not be true. When Domain A trusts Domain B, then the user accounts on Domain B are given access to resources on Domain A, just as though the user accounts existed on Domain A.

The concept of the Trust allows the administration of the user accounts and the network resources to be distributed among multiple NT Domains. One common architecture is to allocate all resources in one or more resource domains and allocate all user accounts on one or more account domains. There is nothing special about these domains other than how the administrator has used them to manage user and resource accounts. The domains are then linked together by having the resource domains Trust the account domains.

A common architecture is to have one or more domains configured as resource domains, and one domain configured as the account domain. All of the resource domains are then configured to trust the account domain. In NT literature, this architecture is known as the Master Domain model. Figure 1 shows a diagram of the trust relationships in the master domain model. Each circle in the diagram represents a different NT domain. Domains X, Y and Z are configured as resource domains. Domain A is configured as an account domain. The

arrows between the domains represent the trust relationship between the domains. The domain that trusts another

domain has an arrow pointed at the domain it trusts.

Account Domain

Trust Relationships

Y Z

Figure 1. Master Domain Model

Another common architecture is to have one or more domains configured as resource domains, and multiple domains configured as account domains. All of the resource domains are then configured to trust all of the account domains. In NT literature, this architecture is known as the Multiple Master Domain model. Figure 2 shows a diagram of the trust relationships in the Multiple Master Domain model. Each circle in the diagram represents a different NT domain. Domains X, Y and Z are configured as resource domains. Domains A, B, and C are configured as account domains. The arrows between the domains represent the trust relationship between the domains. The domain that trusts another domain has an arrow pointed at the domain it trusts.

B C A

Trust Relationships

X Y Z

Figure 2. Multiple Master Domain Model

Account Domains

Resource Domains

All NT workstations and servers on a network must be provided a machine account in order to participate in a domain. Machine accounts are established for NT machines by the domain administrator when the system is configured and added to an NT domain. The account is then used by the NT system to logon to the network (the NT domain) every time the computer boots up. In the Master Domain architectures discussed above, the machine accounts would reside in one of the resource domains.

Windows NT systems use the NetLogon service to perform the logon of the computer to its domain on the network, using the machine account. The NetLogon service establishes a secure communications channel with its domain controller. Security is maintained through the use of special internal trust accounts.

Using the NetLogon service, all users logging onto the computer, whether interactively or remotely, are authenticated through the domain where the computer has the machine account. In many cases, such as in the Master Domain model, the user account will not reside on the domain where the computer has the machine account. In these cases, the domain controller will examine the domain name to which the account belongs (the domain of the account is provided with the rest of the logon credentials) and will determine if a trust relationship exists with that domain. If a trust relationship does exist, then the authentication request is passed on to that domain. The response to the authentication request is then passed back through the domain controller where the request originated.

3.3.2 User Authentication

Whenever a user accesses the resources of a computer on a Windows network, the user must first be authenticated. User authentication is the process of matching credentials provided by the user against an equivalent entry in an account database. In the case of Windows, the credentials of the user are the account name and password.

User accounts may be stored locally on the machine performing the authentication, or remotely by a server dedicated to managing the accounts and authenticating users. Windows supports both mechanisms, but authentication using locally stored accounts is very limiting on a network. This is because there is no way to perform a remote logon using a locally defined account. The remote computer knows nothing of accounts stored on individual computers, and thus has no way of authenticating these accounts.

On most Windows networks, user accounts are managed centrally on one or more Domain Controllers. The Domain Controllers store user accounts in the Security Accounts Manager (SAM) database. Whenever a computer on a network wants to authenticate a user, it contacts a Domain Controller, and asks to authenticate a user.

When a user logs onto a machine either interactively, or remotely, the user is first challenged by the machine. The user responds with the appropriate account name and password (in remote logons, this is usually automatic). The response is then authenticated as follows:

1) The machine will examine the credentials offered by the user to see if the account is a local account on the machine. If the account is local, then the authentication is processed locally.

2) If the account is not a local account, then the request is passed onto the NetLogon service, which in turn passes it along to the domain controller where the computers own machine account resides (domain A).

3) The domain controller in domain A will examine the request to see if the account is associated with the domain. If it is, then it will authenticate the user and pass back the result.

4) If the account is with another domain (domain B), then domain A will verify that it has a trust relationship with domain B. If a trust relationship does exist, then the request is passed onto a domain controller in domain B for verification.

5) Domain B verifies the authentication request, then passes the result to domain A, which in turn passes it to the requesting computer.

When a user is authenticated, the authenticating computer passes back an access token to the requesting computer. The access token represents the user and contains a security identifier (SID) for the user, the SID of each group of which the user is a member, the SID to be assigned to objects created by the user and a default access control list.

3.3.3 Password Maintenance and Encryption

The following discussion of passwords pertains to Windows NT 4.0. The Windows 2000 encryption mechanisms are not presented here, except to note that Windows 2000 is backward compatible with the Windows NT 4.0 mechanisms described here.

User records are stored in the security accounts manager (SAM) database. Each user has two passwords with which it is associated: the LAN Manager (Lan Man 1.2) compatible password and the Windows NT (NT LM

0.12) password. Each password is stored doubly encrypted in the SAM database. The first encryption is a one-

way function (OWF) version of the clear text generally considered to be non-decryptable. The second encryption is an encryption of the user's relative ID (RID). The second encryption is decryptable by anyone who has access to the double-encrypted password, the user's RID, and the algorithm. The second encryption is used for obfuscation purposes.

The LAN Manager compatible password is based on the original equipment manufacturer (OEM) character set, not case sensitive (enforced by upper casing before encryption), and up to 14 characters long. The OWF version (called the LAN Manager OWF or ESTD version) of the password is computed by encrypting a constant with the clear text password using DES encryption. The LAN Manager OWF password is 16 bytes long. The first 7 bytes of the clear text password are used to compute the first 8 bytes of the LAN Manager OWF password. The second 7 bytes of the clear text password are used to computer the second 8 bytes of the LAN Manager OWF password.

The Windows NT password is based on the Unicode character set, is case sensitive, and can be up to 128 characters long. The OWF version (called the Windows NT OWF password) is computed using the RSA MD-4 encryption algorithm, which computes a 16-byte "digest" of a variable length string of clear text password bytes.

The purpose of maintaining both versions of a password is to ensure compatibility with all clients on the network. In no instance is the password of any user account stored as plaintext – it is always encrypted by the OWF first. It is important to note, however, that the encrypted passwords are almost as valuable as the plaintext passwords, and are even commonly referred to as plaintext equivalents. Even though it is not feasible to decrypt plaintext equivalent passwords, they can be used to obtain authentication on a server.

When a client attempts to logon to a server on a network (known as remote logon or network logon), the client is given a 16-byte challenge (or "nonce"). If the client is a LAN Manager client, the client computed a 24-byte challenge response by encrypting the 16-byte challenge with the 16-byte LAN Manager OWF password. This is the algorithm used by LAN Manager. The LAN Manager client passes this "LAN Manager Challenge Response" to the server. If the client is an Windows NT client, the client computed a LAN Manager Challenge Response, just as above. In addition, the Windows NT client computes an "Windows NT Challenge Response" by using the identical algorithm but using the 16-byte Windows NT OWF password instead of the LAN Manager OWF password. The Windows NT client then passes both the LAN Manager Challenge Response and the Windows NT Challenge Response to the server.

In either case, the server authenticates the user by passing this response to its Domain Controller which will either process the request, or will pass the request onto another Domain that it has a trust relationship with, depending on the Domain of the user account. The response includes the following information: the domain name, the user name, the original challenge, the LAN Manager Challenge Response, and the optional Windows NT Challenge Response. To authenticate the response, the Domain Controller queries the OWF passwords from SAM, computes the appropriate Challenge Response using the OWF password from SAM and the passed in Challenge, and then compares the computed challenge response to the one passed in. The Windows NT OWF password will be used to authenticate wherever possible. In cases where the Windows NT OWF password is missing from either the SAM or the response, then the LAN Manager password will be used instead. This allows for backward compatibility.

3.3.4 Security Descriptors

Windows NT, in conjunction with the NT File System (NTFS), is designed to support restricted access to any object (i.e. files or directories) on the File System. Every file and directory stored on the system contains a small amount of administrative information (often referred to as metadata) which includes the security information associated with the object. This information is known as the Security Descriptor, and contains the following main attributes:

Owner SID The owner’s security ID.

Group SID The security ID of the primary group for the object (used only by POSIX).

Discretionary Access Control List (DACL) Specifies who has what access to an object

System Access Control List (SACL) Controls the auditing messages the system will generate.

System ACLs are controlled by the administrators.

This security mechanism protects the object from unauthorized access, regardless of whether the user attempts to access the object on the local machine, or over the network from a client system.

The Discretionary Access Control List (DACL), is by far the most common form of access control list, and is often abbreviated simply as the ACL of an object.

An Access Control List is made up of a header and zero or more access control entry (ACE) structures. These entries specify access or auditing permissions to that object for one user or group. There are three ACE types: two for Discretionary ACLs and one for System ACLs. The Discretionary ACEs are AccessAllowed and AccessDenied. They explicitly grant or deny access to a user or group of users. SystemAudit is a System ACE

that is used to keep a log of security events (such as who accesses which files) and to generate and log security audit messages.

Each ACE contains a security ID and an access mask. The SID identifies the user or group to be associated with the entry, and the access mask defines the type of access allowed or denied. The access mask varies for different object types. In general, they include Standard types, Specific types, and Generic types. The Standard types are defined as follows:

SYNCHRONIZE The right to use the object for synchronization. This enables a thread to wait until the

object is in the signaled state. Some object types do not support this access right. WRITE_OWNER The right to change the owner in the object's security descriptor. WRITE_DAC The right to modify the DACL in the object's security descriptor. READ_CONTROL The right to read the information in the object's security descriptor, not including the

information in the SACL. DELETE The right to delete the object.

Specific types include access options that apply specifically to an object type. Each object type can have up to 16 specific access types. For example, Windows NT files have the following specific access types:

q ReadData q WriteData q AppendData q ReadEA (Extended Attribute) q WriteEA (Extended Attribute) q Execute q ReadAttributes q WriteAttributes

The granting of access rights to a particular user for a particular object is known as the security policy. Each request to access an object contains a set of desired access rights. These desired access rights are checked against the access control information defined in the object’s security descriptor to determine whether or not access should be granted or denied. There are two algorithms used to validate access to an object:

1) The first algorithm determines the maximum access allowed to the object. A grant-access mask and a deny-

access mask is constructed based on the entries in the DACL.

2) The second algorithm is used to determine the specific access allowed, based on the user’s access token.

The main task of these algorithms is to examine each ACE in the DACL. If the SID in the ACE matches a SID in the user’s access token, the ACE is processed further to determine the access allowed. If any requested access type is specifically denied to the user in one of the entries, then access to the object is denied. If ALL of the requested access types are specifically granted after examining the ACEs in the DACL, then the user is granted access to the object. Otherwise, access is denied.

For example, if a user wants to access a file for reading and writing, then the ACEs in the DACL must contain one or more entries that specifically allow both reading and writing to the user. In addition, there must not exist any entry that specifically denies reading or writing to the user. Otherwise, the user will be denied access to the file.

Note: If the object has no DACL, also known as a NULL DACL, the object has no protection and access is granted to everyone. On the other hand, if the object has a DACL with no entries in it (termed an empty DACL), no accesses are specifically granted, so access is implicitly denied to everyone. In all cases, the owner of an object can modify the permissions of the object, regardless of the status of the DACL.

3.4 Considerations for the HP NetStorage 6000

3.4.1 Share Level Security

By default, the HP NetStorage 6000 accepts encrypted passwords for verification. In these cases, Windows NT (also known as NT LM 0.12) password encryption is used. The HP NetStorage 6000 will also accept plaintext passwords from older clients, for backward compatibility.

Since the native file system on the HP NetStorage 6000 is UNIX based, all files must have a UID and GID associated with them. However, since Share Level security does not support the concept of users or groups, a single UID and GID is assigned to each share, such that all files created in the share from Windows clients will be assigned the UID and GID of the share.

When shares are managed through the web based administration tool, shares are automatically assigned a UID and GID of zero (UID = 0, GID = 0). Since UID of zero effectively gives the share user root privileges, it is up to the administrator to ensure that the Windows shares are created in such places so as not to expose sensitive system files, or the resources of other UNIX users.

For administrators with special needs, the default UID and GID of zero may be changed for a given share. The telnet interface of the HP NetStorage 6000 allows the user to specify the UID and the GID to be used for a particular share. In this case, ALL directories and files created in the share will be assigned the UID and GID specified by the administrator.

3.4.2 User Level Security

The HP HP NetStorage 6000 fully supports the security model of Windows NT systems. This includes the assignment and enforcement of Security Descriptors to objects on the file system, as well as the authentication of users attempting to access resources.

The CIFS protocol is documented in a public specification. The NetLogon service is not. NetLogon is a proprietary Microsoft service that is used for establishing secure communications with a domain controller, and providing pass-through authentication, as needed. Since a public specification for providing the same service as NetLogon does not exist, the HP NetStorage 6000 must emulate the features of NetLogon where necessary.

q The HP NetStorage 6000 does not logon to the domain with a machine account. Thus, it is not a trusted

member of the domain. However, it can still advertise its resources through the domain that it is associated with (the resource domain).

q The HP NetStorage 6000 is designed to authenticate users under the NT LM 0.12 or the Lan Man 1.2

dialects of SMB. The HP NetStorage 6000 simply forwards these requests to an NT domain controller for authentication. The server is not designed to authenticate user accounts that are maintained locally.

q The HP NetStorage 6000 is designed to authenticate users directly with the appropriate NT account

domain. It does not pass authentication requests through it’s own resource domain. This allows the HP NetStorage 6000 to participate on networks where the user accounts are separated from the NT resources (Master Domain model), as well as on networks where user accounts and resources are contained in a single domain. However, on networks designed around the Multiple Master Domain model, the HP NetStorage 6000 may only be configured to authenticate users through only one of the account domains.

q The HP NetStorage 6000 can discover an appropriate domain controller to communicate with, given the

NT domain name. This allows the server to connect to any available domain controller within a domain.

q The HP NetStorage 6000 can obtain and store Security Descriptor information (ACLs) for its files. This is

accomplished through a user account logon to the resource domain. The user account information is provided by the administrator when the system is configured for user level security.

3.4.3 DOS attributes

The DOS attributes are integrated with the file system and may be viewed, set or cleared via Windows applications or utilities. The behavior associated with these attributes is detailed below:

archive Whenever a file is modified, locally, via NFS or SMB, this attribute is set. The archive attribute

may be used for operations such as network backup via NT systems.

hidden If a file is created via NFS whose name begins with “.”, this attribute will be set. It is otherwise

ignored by the system.

read-only If this attribute is set on a file, it will have the effect of making the file read-only regardless of the

UNIX or NT permissions.

system This attribute is ignored by the system.

4 Security on Mixed (UNIX/Windows) Networks

4.1 General Overview

The HP NetStorage 6000 works in a heterogeneous environment and supports file sharing between Windows and UNIX clients using CIFS/SMB or NFS file access protocols respectively. In order to understand file sharing in a heterogeneous environment it is necessary to understand the file system that the HP NetStorage 6000 uses, how clients or users are identified in each protocol and how users can be mapped.

The HP NetStorage 6000 utilizes a UNIX file system. Objects that are created with NFS protocol and stored on the HP NetStorage 6000 will have UNIX security attributes and classified as UNIX objects. Objects that are created via SMB protocol have both UNIX and Windows security attributes and are classified as NT objects. Since the native file system used by the HP NetStorage 6000 is a UNIX file system, any Windows objects that are created will have both UNIX and NT security attributes associated with these objects. It is possible for a Windows user to modify a UNIX objects' security attribute. After this modification, however, the object will be considered an NT object. As a security policy it is not possible to modify the security attributes on a Windows

object via UNIX (chmod or chown commands) and have the object become a UNIX object since this could potentially weaken the access control that protects these objects.

In order for clients to share files across Windows and UNIX protocols, it is necessary to establish their credential equivalence in each protocol. With this equivalence established, clients can access the files without regard to their current working environment as the owner, member of a group, or as part of the Everyone or Other account. A Windows client is identified by NT domain name, user name and the RID (relative ID) that is part of the unique security descriptor supplied by the NT domain controller. UNIX clients are identified by their UID and GID values whether they are part of a NIS administered server or not.

As described in the previous sections, the Windows and UNIX operating systems use different methods for authentication, user identification, and controlling access to resources through permissions. If users are going to be recognized as the owner of a file in both Windows and UNIX it will be necessary to "map" or create equivalence between users in each environment. It will also be necessary to obtain information from each user that will allow file permissions and access controls to be displayed in a manner that is consistent with each protocol. All of this is accomplished using a series of map files that hold client information that will allow the identification and translation of user credentials from one protocol to another.

Before discussing mapping strategies and the mechanisms used to map clients note that mapping is only used when NT clients access UNIX file objects. Because the HP NetStorage 6000 uses a UNIX file system as its native file system, UNIX file objects and NT objects have UNIX security attributes associated with these objects. Therefore, whenever a UNIX client accesses these objects the HP NetStorage 6000 does not need to consult any mapping strategy to determine permissions. It is only when an NT client tries to access UNIX objects that the mapping strategy is employed or necessary.

File access and sharing is determined on several different levels including file volume creation, Windows and UNIX security policies, and a choice of mapping strategies that are selected. Each of these aspects controls and refines the access that users will or will not have with the files stored on the HP NetStorage 6000. Each of these topic areas will be covered in the discussion below.

5 File Sharing Configuration

File sharing considerations begin with the file allocation storage that is established when file volumes are created with UNIX and/or Windows permissions. The administrator will need to consider the overall availability and amount of storage resources needed for each of the protocols.

5.1 File Volume Permissions

Before files can be shared in a heterogeneous environment the administrator must establish file sharing policies which will allow both Windows and UNIX clients to gain access to files that are located on the HP NetStorage

6000. When file volumes are created the administrator selects the access that will be available for this volume by selecting Windows clients only, UNIX clients only, or both Windows and UNIX clients. The choices that the administrator makes on one volume will not affect the choices that can be made on other volumes. An example is shown below:

File Volume

Name

Finance Windows only; no UNIX

Marketing Windows & UNIX access Read & write access for

Procurement Windows & UNIX access No passwords Research &

Development

In this example, clients using either a Windows or UNIX protocol can access Marketing and Procurement files. When clients attempt to mount or access files for the Marketing group they will be challenged for the appropriate password. In the case of files that belong to the Finance group UNIX users will be unable to mount this volume. Similarly Windows users will be unable to “see” or access the Research and Development file volume since it is only available to UNIX clients.

File Volume Access Password Restrictions

Read access only

access

Windows; Read access for UNIX

UNIX access only Read and write access

5.2 Mapping Strategies

Mapping strategies are a means for defining users and groups that have both a Windows and UNIX identity. Mapping is the mechanism that is used to determine whether a user should be granted file access rights in a different protocol. Recall that the two operating systems use two different methods for securing file objects. By establishing either user or group equivalence, the proper access controls can be in place while providing users with greater flexibility in their work.

If mapping is desired it can be selected for users and/or groups. Recall from the previous discussion that the HP NetStorage 6000 file system uses a UNIX style file system. Therefore, it is necessary to identify all users with a UID and GID value. Since the Windows protocol does not use UID or GID values, and instead associates a unique security descriptor with each client, it is necessary to create or associate a UID and GID number with each Windows user. Assigning UID and GID values is done based upon the mapping strategy that the user selected. The four possible methods are as follows:

User Mapping

§ No mapping (default) - no association between UNIX and NT accounts. A unique UNIX UID will be assigned to all Windows users. If the Windows client has previously accessed the HP NetStorage 6000 the UID value that they were previously assigned will be saved in the passwd file. If no entry for this client is found in the passwd file, they will be given a UID value that is one larger than the largest UID value found in this search.

§ Username mapping - users have equivalent UNIX and NT credentials if the user name is the same in the NT domain and UNIX account.

§ Full name mapping - users have equivalent UNIX and NT credentials if the NT domain full name matches the UNIX comment field for the UNIX account.

Group Mapping

§ No mapping (default) - no association between UNIX and NT groups

§ Group name mapping - groups have equivalent UNIX and NT credentials if the primary group name associated with an NT account is the same as a group defined for UNIX accounts.

5.2.1 User Mapping

There are two ways that a HP NetStorage 6000 user can obtain a UID. In the first case, the user has a UNIX account and the administrator has elected to do some type of mapping - either by user logon name or full name mapping. If the Windows client is matched to a UNIX account then the UID associated with the UNIX account will be assigned to them. Otherwise, the HP NetStorage 6000 will assign a UID number that will be associated with their NT domain, logon name and full name fields. Once the user has a UID assigned to them, then any further activities on the server will have this unique UID associated with the file or directory metadata.

The HP NetStorage 6000 assigns UID values beginning with number 60001. This number was chosen so as to not conflict with typical UNIX installations that don't have or use numbers greater than 60000.

The HP NetStorage 6000 administrator provides information about their UNIX clients automatically by enabling the NIS server. Where this is enabled, the NIS server database will be automatically downloaded and refreshed on a periodic basis. If this feature is not enabled, or the UNIX administrator is not using a NIS server to manage their UNIX accounts, they will need to manually edit and manage the mapping files that are used to associate UNIX and Windows accounts. For user mapping the passwd.nis file is used.

5.2.2 Group Mapping

In a manner consistent with user mapping, group mapping assigns a unique GID for Windows clients. The HP NetStorage 6000 will attempt to map the Windows clients' primary group with a known UNIX group. If there is no match then the HP NetStorage 6000 will assign a GID beginning with number 60001. Once the group number is assigned this number will be part of the metadata that is associated with the users files and directories.

In a similar manner with User mapping, the administrator provides UNIX group information by enabling the automatic download of the NIS server data. For group mapping the group.nis file contains information about UNIX groups along with their associated GID and members. If the NIS server is not enabled or used, then the administrator must manually edit and manage this file.

6 Mapping Clients

User mapping is used to create an equivalence relationship between a UNIX user and an NT user in which both sets of credentials are deemed to have equivalent rights on the system. Since the underlying file system used by the HP NetStorage 6000 is a UNIX system it is really only necessary to map NT users to a UNIX domain.

Each time a Windows user logs in to the system, the mapping files are checked to determine the user’s UNIX credentials. The passwd file and users.map file are searched to determine whether the Windows client had previously been assigned a UNIX UID value. The user’s NT domain name and user name are used in this search. If a match is found, the UNIX UID is taken from the matching entry. If there is no match, then one of the four mechanisms described below is used to determine the user’s UNIX UID. The mechanism to be used is controlled via the user mapping policy setting.

The mapping that occurs between clients is done using several files that must be maintained if file security and user credentials are to be established and maintained. For example, the NIS database files will refresh automatically every 5 minutes. However, the passwd and group files are maintained using the HP NetStorage 6000 GUI interface.

6.1 Mapping Files

The following table shows the files that are employed for assigning UID, GID values and creating the association between clients.

File Name File Information Purpose

passwd NT domain, user logon,

UID, GID and comments. If the user resides only in the local HP NetStorage 6000 domain, the default NT domain that is assigned is the local hostname.

group NT domain, user logon,

GID. If the user resides only in the local HP NetStorage 6000 domain, the default NT domain that is assigned is the local hostname.

passwd.nis UNIX logon name,

encrypted password, UID, and GID

Assign a UNIX style UID to an NT client if they do not have a UNIX account.

Assign a UNIX style GID to an NT client's primary group.

If user mapping is enabled and the NT client has not previously been assigned a UID and GID value, this file is consulted to match on either username or full name values depending upon the mapping strategy that is employed.

This file is also used to generate an ACL display list for Windows users for UNIX files.

group.nis UNIX group name,

GID, members of group in text format.

If group mapping is enabled and the NT client has not previously been assigned a GID

value, this file is consulted to match the NT primary group with a UNIX group name.

This file is also used to generate an ACL display list for Windows users for UNIX files.

The files that contain the association between the clients in Windows and UNIX are the following.

File Name File Information Purpose

Users.map UNIX username, UID,

NT username, NT domain, NT relative ID (RID)

Group.map UNIX groupname, GID,

primary NT group name, NT domain, NT relative ID (RID)

Provides UNIX users with an identity that can be used to display ACL data for Windows users. For Windows users the RID and assigned UID and GID values can be translated. Provides UNIX users with an identity that can be used to display ACL data for Windows users. For Windows users the RID and assigned UID and GID values can be translated.

A discussion about how these files are accessed and used follows.

6.2 Establishing a Windows Client

Each time an NT user logs into the HP NetStorage 6000 the mapping files are checked to determine whether the user has previously established UNIX credentials or whether it will be necessary to assign UID and GID values. The users.map files is consulted to determine if an equivalency already exists between the NT client and a UNIX account with a UID and GID value. If there is no match in the map file, the passwd file is scanned to see if the NT client has previously accessed the server and been assigned a local UNIX UID and GID value. If no mapping has been selected and if both of these checks fail, then the NT client will be added to the local passwd file and assigned a UID and GID with numbers greater than or equal to 60001. The users credentials are checked each time the user logs into the HP NetStorage 6000. The user must have the same NT domain and user name to be considered the same.

If any type of user mapping has been selected then additional checks are made. If user name mapping has been selected the passwd.nis file is scanned to determine if there is a UNIX user that has a logon name identical with the Windows client. Similarly if full name mapping has been selected the passwd.nis file will be scanned to determine if there is a UNIX client where the NT Windows full name matches the contents of the UNIX comment field which is frequently used for the users full name. If the HP NetStorage 6000 is able to find a match in the passwd.nis file then the UID and GID that will be associated with this Windows client will be that UID and GID from their UNIX account.

Windows Client User Mapping UNIX

Client

New Windows client.

No user mapping.

User mapping is selected.

Yes or No The users.map and passwd files

Yes The users.map and passwd files

Comments

are searched. Since this is a new client no match is found.

The passwd.nis file is NOT searched since the administrator does not want to associate Windows and UNIX clients that have the same user name.

Since this is a new client no match is found so a UID and GID will be assigned by the HP NetStorage 6000 beginning with 60001 for the UID and GID. The appropriate entry will be made in the passwd file.

are searched. Since this is a new client no match is found.

The passwd.nis file is consulted. A match is found because the Windows name is the same as the UNIX logon name.

Windows client will be assigned the UID and GID from the passwd.nis file. An entry will be made in the users.map file to associate the UNIX and

Windows accounts. New Windows client.

User mapping is selected.

No The users.map and passwd files

are searched. Since this is a

new client no match is found.

Established Windows Client

With or without user mapping.

The passwd.nis file is consulted.

No match is found.

Since this is a new client no

match is found so a UID and

GID will be assigned by the HP

NetStorage 6000 beginning

with 60001 for the UID and

GID.

The appropriate entry will be

made in the passwd file.

Yes or No The passwd file is searched.

Since this Windows client has

already been established - they

have previously accessed the HP

NetStorage 6000 - an entry will

be found in this file and the

previously assigned UID and

GID will be associated with this

client.

6.3 Establishing a UNIX Client

Recall that from the discussion above about operating in a UNIX only environment that it was not necessary to supply NIS server information since the HP NetStorage 6000 did not perform user authentication or account name resolution. When a UNIX client attaches to the HP NetStorage 6000 they have a UID and GID that have been previously assigned to them by their UNIX administrator. Since there is no need to assign these values the purpose for obtaining UNIX user information is to synthesize ACL information that can be displayed to the Windows clients or for mapping UNIX to Windows clients. The passwd.nis file will contain the UNIX logon name, encrypted password, UID and GID information. The group.nis file will contain the UNIX group names, GID and the members of the group in text format.

7 Examples

7.1 Client with both UNIX and Windows Account

If there are clients that have both UNIX and Windows accounts they can easily access their files regardless of their current environment.

The client has the following information:

Windows UNIX

User Name User name: msullivan

NT domain: Empire

msullivan

HP NetStorage 6000 Configuration assumptions:

• Administrator has established file volume permission so that both UNIX and Windows clients can access the

file.

• NIS server administration is used and enabled so that the passwd.nis file is populated with UNIX user

account information

• Administrator has selected user name mapping

Client assumptions:

• Windows client created the file and is the owner of the file.

• As a Windows client the user has stored the file on the HP NetStorage 6000

• Client is accessing HP NetStorage 6000 as a Windows client for the first time

• Windows logon name matches UNIX logon name

Files Scanned or Read Files Written Comments

passwd

-no relevant entry

Passwd.nis file is scanned and a match is made between the UNIX logon name and the NT logon name.

Users.map file has a new entry that contains information about the NT domain and UNIX accounts that have now been matched.

The client has never accessed the HP NetStorage 6000 so they don't have an autoassigned number or a UNIX UID value.

The UNIX account UID is assigned to this Windows client. A mapping is created.

The Windows user can use a tool like Windows Explorer to map a network drive and store the file on the HP NetStorage 6000. When the Windows client examines the Windows file permissions they will find that they are shown as the owner of the file. In addition they will see the group Everyone has Full Access permissions. As the owner the user can modify the permissions to either grant or prohibit access to users and groups as they see fit.

7.2 UNIX File Accessed by Windows Clients

For this example a UNIX client has created a file and UNIX and Windows clients will access it. The client has the following information:

Windows UNIX

User Name User name: msullivan

Full name: Mike Sullivan NT domain: Empire

HP NetStorage 6000 configuration assumptions:

• Administrator has established file volume permissions so that both UNIX and Windows clients can access the

file.

• NIS server administration is used and enabled so that the passwd.nis file is populated with UNIX user

account information

User name: msullivan Comment: Mike Sullivan

• Administrator has selected full user name mapping

Client assumptions:

• UNIX client created the file and is the owner of the file.

• The Windows client is accessing the HP NetStorage 6000 for the first time

• Windows full name matches the UNIX comment field exactly

Files Scanned or Read Files Written Comments

passwd

-no relevant entry

Passwd.nis file is scanned and a match is made between the UNIX comment field and the NT logon full name.

Users.map file has a new entry that contains information about the NT domain and UNIX accounts that have now been matched.

The client has never accessed the HP NetStorage 60001 so they don't have an autoassigned number or a UNIX UID value. The UNIX account UID is assigned to this Windows client. A mapping is created.

7.3 Windows File Accessed by UNIX Clients

For this example a Windows client is creating a file that they want to share with other Windows clients and UNIX users who are in the same group as themselves.

The client has the following information:

Windows UNIX

User Name User name: msullivan

NT domain: Empire

Group Primary group: marketing marketing

HP NetStorage 6000 Configuration assumptions:

• Administrator has established file volume permission so that both UNIX and Windows clients can access the

file.

• NIS server administration is used and enabled so that the passwd.nis and group.nis files are populated with

UNIX user and group accounts.

• Administrator has selected group mapping only

Client assumptions:

• Windows client created the file and is the owner of the file.

• As a Windows client the user has stored the file on the HP NetStorage 6000

• Client has accessed the HP NetStorage 6000 as a Windows client

• Windows logon name does not match any UNIX logon name

• Windows primary group matches a known UNIX group

- no account

Files Scanned or Read Files Written Comments

passwd Empire/msullivan:*:60004:101 :::

group No entry since the primary

passwd.nis

-no relevant entry group.nis

marketing:101:user1,user2,user 3

users.map No entry.

group.map <Empire/marketing>:101:m

arketing:Empire:1077

The Windows client can access the file and view the permissions. If they desire they can modify the permissions on this individual file to allow the Marketing group to access the file or deny the Marketing group access. UNIX clients that are members of the Marketing group will be able to access this file according to the permissions that have been granted by the creator or owner of the file.

Windows client has been auto-assigned a UID value since they do not have a UNIX account. The auto-assigned UID is 60004

Windows group matches a UNIX group.

8 File Format Details

8.1 HP NetStorage 6000 Files - passwd, group, users.map, group.map

Passwd <NT domain/logon name>:*:<UID>:<GID>:<comment>: Group <NT domain/logon name>:*:<GID> Users.map <UNIX-username>:<UID>:<NT-username>:<domain>:<rid> Group.map <UNIX-groupname>:<GID>:<NT-groupname>:<domain>:<RID>

8.2 UNIX Files - passwd.nis and group.nis

File Name File Format

passwd.nis <user name>:<encrypted password>:<UID>:<GID>:<comment fields>:<home

directory>:<shell>

group.nis <group name>:< encrypted password >:<GID>:<group members separated by

commas>

9 Acronyms

ACL Access Control List CIFS Common Internet File System IP Internet Protocol DACL Discretionary Access Control List DC Domain Controller DNS Domain Name System GID Group Identifier MAC Machine Access Control NAS Network Attached Storage NetBIOS Network Basic Input/Output System NFS Network File System NIS Network Information Services NT New Technology PDC Primary Domain Controller RID Relative Identifier SAM Security Account Manager SD Security Descriptor SID Security Identifier SMB Server Message Block UID User IDentifierReferences

Hp NETSTORAGE 6000 File Sharing Security

Specifications and Main Features

Frequently Asked Questions

User Manual