Multiprotocol data access
This chapter describes multiprotocol data access for the IBM System Storage N series storage systems, which provide fast, simple, and reliable network data access to the following clients: Network File System (NFS), Common Internet File System (CIFS) for Microsoft Windows networking), and Hypertext Transfer Protocol (HTTP) primarily for web browsers.
Support for all three protocols is woven into the Data ONTAP microkernel and file system.
It provides multiprotocol data access that transcends the enclosed perspective of general purpose operating systems, as explained in this chapter.
It provides multiprotocol data access that transcends the enclosed perspective of general purpose operating systems, as explained in this chapter.
The following topics are covered:
•NFS
•CIFS
25.1 Introduction to multiprotocol access
As mentioned, support for the NFS, CIFS, and HTTP protocols has been designed into the Data ONTAP microkernel and file system, and it provides you with multiprotocol data access that transcends the enclosed perspective of general-purpose operating systems.
In the context of file service to Windows clients, Data ONTAP software for Windows is virtually indistinguishable from other Microsoft Windows servers in a Windows domain. For example, in addition to many other Windows-compatible features, note the following points:
•Access control lists (ACLs) can be set on shares, files, and directories.
•IBM System Storage N series storage systems can be administered through Windows Server Manager and User Manager.
•UNIX users are mapped to Windows users.
•Multi-language support is available through UNICODE.
•File access logging can be tracked for Windows and UNIX users.
•IBM System Storage N series storage systems interoperate with NTFS and Active Directory.
Windows-style ACLs and UNIX-style file access permissions are fully integrated on the IBM System Storage N series storage system. Furthermore, Windows users are automatically mapped dynamically to their respective UNIX accounts (to assess file permissions), thus simplifying the unification of the two separate namespaces.
This setup is especially powerful in conjunction with the IIBM System Storage N series autohome feature, which provides all Windows users with share-level access to their own home directories without the painstaking administrative efforts typically required on other Windows file servers. (Users automatically see their own home directory as a share in the Network Neighborhood, but not other users’ home directories, unless those others have been deliberately and explicitly exported as publicly visible shares.)
With multiprotocol access, Windows clients can store and access data side-by-side with UNIX-based clients without compromising their respective file attributes, security models, or performance. Users with Windows desktops can work within the single instances of their home or project directories, with Windows-based applications executing locally, or with UNIX-based applications running on a server. Whether written to the storage system through NFS or CIFS, documents can be accessed directly by a wide variety of web browsers through HTTP.
Multiprotocol access, as illustrated in Figure 25-1, liberates the data infrastructure, largely freeing it from the constraints of operating system preference or existing investments.
Figure 25-1 Network-attached storage and SAN protocols
In the following sections, we describe these topics:
•The IBM System Storage N series multiprotocol storage system architecture
•The implications of multiprotocol access for system administrators and users
•The evolution of Data ONTAP software for Windows
25.2 File system permissions
IBM System Storage N series storage systems support both UNIX-style and NTFS-style file permissions. Because the ACL security model in NTFS is more complex than the file security model used in UNIX, no one-to-one mapping can be made between them.
The fundamental problem occurs when a Windows or similar type of client (which expects an ACL) accesses a UNIX file, or when a UNIX client (which expects UNIX file permissions) accesses a Windows file. In these cases, the file server must sometimes authorize the request using a user identity that has been mapped from one system to the other, or in some cases using even a set of permissions that has been synthesized for one system based on the actual permissions for the file in the other system.
IBM System Storage N series storage systems ensures that these synthesized file permissions are at least as restrictive as the true file permissions. In other words, if user XYZ cannot access a file using the true file permissions, the same is true when using the synthesized file permissions. Data ONTAP has a mechanism called UID-to-SID mapping to address this issue.
25.2.1 UNIX file permissions
UNIX file permissions are usually represented as three sets of concatenated rwx triplets. Example 25-1 illustrates a directory listing in a UNIX File System.
Example 25-1 UFS permissions
lrwxrwxrwx 1 agy eng 10 Sep 2 14:42 perms.doc->perms.html
-rw-r--r-- 1 agy eng 1662 Sep 2 14:32 perms.html
-rw-rw---- 1 agy eng 2399 Feb 19 1998 privileges.nt.txt
drwxr-xr-x 2 agy eng 4096 Sep 2 14:42 work
The first 10 characters on each line indicate the file type and permissions for the listed file:
•The first character is as follows:
d A letter (d) indicates that the file is a directory.
l A letter (l) indicates that the file is a symbolic link.
- A dash (-) character indicates that it is a regular file.
•The next three characters specify whether the user (agy, in this example) can read (r), write (w), or execute (x) the file.
•The following three characters specify the permissions for the group associated with the file (eng, in this example).
•The last three characters specify the permissions for users who are not the owner or members of the file’s group.
Referencing Example 25-1, perms.doc is a symbolic link that anyone can traverse (obtaining the file perms.html). perms.html is a regular file that anyone can read, but only the user agy can write. privileges.nt.txt is a file that agy (or anyone from the group eng) can both read and write. Finally, work is a directory that anyone can search and read files in, but only agy can insert files into or delete files from it.
When user agy attempts to access a UNIX file named nfsfile, the behavior of the file system depends on what kind of file it is. First, though, the request is checked against the permissions associated with the file. For example, if it is a read request, the following processing occurs:
•If agy is the nfsfile owner and the owner has read permission on nfsfile, then the request can be honored.
•Otherwise, if agy is a member of the file’s group and the group has read permission, the request can be honored.
•Otherwise, if all others have read permission, the request can be honored.
•However, if none of these tests succeed, the request is denied.
25.2.2 NTFS file permissions
NTFS uses a different system for denoting file permissions. On the FAT and FAT32 file systems, which were designed as single-user file systems, there are no permissions. Anyone who can gain access to the machine has unlimited privilege on every file in the system.
The NTFS file system, however, has a sophisticated security model. This same security model is also available for use by the CIFS network file system protocol on IBM System Storage N series storage systems, so Windows clients accessing files on a storage system, whether or not they are running NTFS, can also use this security model.
In NTFS and CIFS, each file has a data structure associated with it known as a security descriptor (SD). This contains (among other things) the file owner’s security ID (SID), as shown in Example 25-2, and another data structure known as an access control list (ACL).
Example 25-2 An owner’s SID
User Name SID
================== =============================================
itsoadministrator S-1-5-21-2057036396-1631034848-1296613683-500
An ACL consists of one or more access control entries (ACEs), each of which explicitly allows or denies access to a single user or group. Suppose that user agy attempts to open file pcfile for reading. The algorithm used to determine whether to grant agy permission to do this task is conceptualized as follows:
•First, search all the ACEs that deny access to anyone. If any of them deny read access to agy specifically, or to any of the groups of which agy is a member, stop searching the ACL and reject the request.
•If no denials of access are found, continue searching the rest of the ACEs in the ACL. If one is found that grants read access to agy or to any of the groups that agy is in, stop searching the ACL and allow the request.
•If the entire ACL has been searched and no ACEs were found that allow agy to read the file specified in the request, reject the request.
It ought to be clear by now why it is not always possible to make a one-to-one mapping from the ACL model to the UNIX security model. For example, using the ACL security model, you can allow access to all the members of a group, except to some specified user. However, It cannot be done using the UNIX model.
25.2.3 NFS access of data
Figure 25-2 portrays the process when a user on a UNIX host accesses data with UNIX security style using NFS. You will see that the IBM System Storage N series behaves with little differentiation in the UNIX environment.
Figure 25-2 NFS access of UNIX security style data
Steps for NFS access of UNIX security style data
To provide NFS access to UNIX data, perform the following steps:
1. The user begins a login from the UNIX host.
As part of the login process, the host requests user and group information for the user from the name services configured in the /etc/nsswitch.conf file. The data can be retrieved from local files, an Network Information Service (NIS) server, or an LDAP server.
2. The configured name service returns user and group information to the UNIX host.
All user information needed to log in, including UID, GID, and the user shell and home directory, is returned. Additionally, the user’s secondary group GIDs are returned.
3. Using the user information retrieved from the identity store, the user is authenticated and allowed access to the UNIX host.
The user and group information retrieved in Step 1 is cached and used to determine access rights to local and remote resources.
4. The user requests access to a mounted IBM System Storage N series file system.
The storage system checks export options at the time the file system is mounted. Export options can affect the user’s ability to perform a requested action. For example, if the file system is mounted read only, the user cannot write to the file system even if file permissions allow it.
The file or folder access request contains the user’s UID and GIDs, including secondary GIDs.
5. The storage system uses the UID and GIDs sent in the access request for the access check.
Because the file system use the UNIX security style, with UNIX rwxrwxrwx type of file permissions, the storage system uses the UID and GIDs with the access check. The system determines if the UID is the owner of the file. If not, the system determines if any of the user’s groups are the objects group owner. If not, then other permissions apply. The system then determines if the desired action is allowed or not allowed.
6. The system replies to the access request, either permitting the requested action if the file permissions allow it or denying the action if the permissions do not allow it.
|
Scope: NFS access of UNIX security style data does not include a user mapping step. This section does not describe how the process handles access requests by root.
|
NFS access of NTFS security style data
The System Storage N series offers the unique capability of providing mixed access to both UNIX and Windows users/hosts. Figure 25-3 describes the process when a user on a UNIX host accesses data with NTFS security style using NFS.
Figure 25-3 NFS access of NTFS security style data
Steps for NFS access of NTFS security style data
To provide NFS access of NTFS data, perform the following steps:
1. The user begins a login from the UNIX host.
As part of the login process, the host requests user and group information for the user from the name services configured in the /etc/nsswitch.conf file. The data can be retrieved from local files, an NIS server, or an LDAP server.
2. The configured name service returns user and group information to the UNIX host.
All user information needed to log in, including UID, GID, and the user shell and home directory, is returned. Additionally, the user’s secondary group GIDs are returned.
3. Using the user information retrieved from the identity store, the user is authenticated and allowed access to the UNIX host.
The user and group information retrieved in step 1 is cached and used to determine access rights to local and remote resources.
4. The user requests access to a mounted IBM System Storage N series file system.
The storage system checks export options at the time the file system is mounted. Export options can affect the user’s ability to perform a requested action. For example, if the file system is mounted read only, the user cannot write to the file system even if file permissions allow it.
The UNIX client sends an access request for a storage system mount that contains the user’s UID and GIDs, including secondary GIDs.
5. The user requests access to data on the storage system that uses NTFS-style permissions, but the request contains UNIX-style UID and GIDs.
The storage system cannot use the UID and GIDs sent in the access request for the access check. Instead, the storage system must compare Windows user and group information to the file’s Window ACL to determine access for the user. Therefore, the storage system maps the UNIX user to the corresponding Windows user.
6. The system queries the configured UNIX identity store, supplying the user’s UID, and requests the user name.
When the user requests access from a UNIX host, the request contains the user’s UID, but does not contain the user name. Because mapping is done by user name, the system must determine the UNIX user name before the mapping process can proceed.
7. The UNIX name service returns the name of the UNIX user to the storage system.
8. The storage system uses the UNIX user name to begin the user mapping process.
The storage system checks /etc/usermap.cfg and the LDAP user mapping entries (if configured) to see if there is a specific mapping entry for the UNIX user.
If there is a specific mapping entry, the storage system uses this entry for the user mapping process.
If there is not a specific mapping entry, the storage system assumes that the Windows user name is the same as the UNIX user name and uses this name automatically during the mapping process.
|
Important: If there is not a specific mapping entry in /etc/usermap.cfg or in the LDAP store (if LDAP user mapping is configured), the Windows user name is assumed to be the same as the UNIX user name, and this name is automatically used in the mapping process. In addition to correlating a Windows user name with a UNIX user name, the mapping process is important in determining if the mapped user is a valid user or not. If the mapped name is not a valid user, access can be allowed as the default NT user or completely disallowed, depending on how the WAFL option wafl.default_nt_user is configured.
|
9. The storage system queries Active Directory to determine if the mapped user name is a valid Windows user.
If the user name is a valid Windows user, the mapping process continues.
If the user name is not a valid Windows user, the user is either mapped to the generic NT user or access is denied, depending on how the WAFL option wafl.default_nt_user is configured.
10. Active Directory replies to the query, either supplying information about the user or returning an error indicating that the user is not found.
11. The storage system queries Active Directory for the mapped Windows user’s SIDs (user SID and all group SIDs).
12. Active Directory replies to the query, supplying information about the user, including the user’s SIDs.
13. The storage system uses the user’s SIDs and compares them to the ACLs of files and directories for which access has been requested. The system then determines if the desired action is allowed or not allowed.
14. The system replies to the access request, either permitting the requested action if the file permissions allow it or denying the action if the permissions do not allow it.
|
Steps: The complete credential retrieved in steps 5 through 12 is stored in the WAFL credential cache. With subsequent access requests, the wcc is checked instead of repeating Steps 5 through 12. The wcc entries expire after 20 minutes (default). After the entry expires, the user mapping step is required again, with the results again being cached.
|
25.2.4 NTFS access modes
The Windows file permissions model defines more access modes than UNIX does (read, write, and execute). Table 25-1 explains what each of the basic file access modes means.
Table 25-1 Basic file access modes
|
Request type
|
The object is a folder
|
The object is a file
|
|
Read (r)
|
Displays the file’s data, attributes, owner, and permissions.
|
Displays the file’s data, attributes, owner, and permissions.
|
|
Write (w)
|
Writes the file, appends the file, and reads or changes its attributes.
|
Writes the file, appends the file, and reads or changes its attributes.
|
|
Read and execute (x)
|
Displays the folder’s contents. Displays the data, attributes, owner, and permissions for files within the folder. Runs files within the folder.
|
Displays the file’s data, attributes, owner, and permissions, and runs the file.
|
|
Modify
|
Reads, writes, modifies, and executes files in the folder. Changes attributes and permissions. Takes ownership of the folder or files within.
|
Reads, writes, modifies, executes, and changes the file’s attributes.
|
|
Full control
|
Reads, writes, modifies, and executes files in the folder. Changes attributes and permissions. Takes ownership of the folder of files within.
|
Reads, writes, modifies, executes, and changes the file’s attributes and permissions, and takes ownership of the file.
|
|
List folder contents
|
Displays the folder’s contents. Displays the data, attributes, owner, and permissions for files within the folder. Runs files within the folder.
|
|
Windows XP, 2000, 2003, and 2008 also support special access permissions, which are made by combining the permissions described in Example 25-1 on page 384.
Table 25-2 lists these special access permissions and their combinations.
Table 25-2 Special access permissions and combinations
|
File special permissions
|
Full control
|
Modify
|
Read and execute
|
Read
|
Write
|
|
Traverse folder/execute file.
|
X
|
X
|
X
|
|
|
|
List folder/read data.
|
X
|
X
|
X
|
X
|
|
|
Read attributes.
|
X
|
X
|
X
|
X
|
|
|
Read extended attributes.
|
X
|
X
|
X
|
X
|
|
|
Create files/write data.
|
X
|
X
|
|
|
X
|
|
Create folders/append data.
|
X
|
X
|
|
|
X
|
|
Write attributes.
|
X
|
X
|
|
|
X
|
|
Write extended attributes.
|
X
|
X
|
|
|
X
|
|
Delete Subfolders and files.
|
X
|
|
|
|
|
|
Delete.
|
X
|
X
|
|
|
|
|
Read permissions.
|
X
|
X
|
X
|
X
|
X
|
|
Change permissions.
|
X
|
|
|
|
|
|
Take ownership.
|
X
|
|
|
|
|
|
Synchronize.
|
X
|
X
|
X
|
X
|
X
|
25.3 File service for environments with NFS and CIFS
IBM System Storage N series storage systems support both NFS-style and CIFS-style file permissions. NFS-style file permissions are widely used in most UNIX systems. CIFS-style file permissions are used in Windows when communicating over networks.
Because the ACL security model in CIFS is more complex than the NFS file security model used in UNIX, no one-to-one mapping can be done between them. This mathematical fact has forced all vendors of multiprotocol file storage products to develop non-mathematical strategies to blend the two systems and make them as compatible as possible. This section explains the IBM System Storage N series approach to this problem.
File service for heterogeneous environments (UNIX workstations plus Windows servers) is challenging. Windows NFS software can be installed on Windows clients or SAMBA can be installed on a UNIX server, but these approaches are either costly or time-consuming, or they introduce an extra layer of file system emulation.
To reduce complexity, making changes must be done at the file server rather than altering a large (and growing) number of Windows clients or adding a file system emulation layer that reduces performance. In other words, in a heterogeneous environment, the file server must support remote file access protocols for both UNIX-based clients and Windows clients.
The alternative, that is, using separate file servers for each protocol, can increase costs due to administrative complexity and redundant investments in storage. Routine administrative functions such as backup and restore are duplicated, and it is still difficult to implement applications that must facilitate sharing of data between UNIX and Windows users.
Perhaps worst of all, perpetuating an arrangement of separate servers for distinct sets of UNIX and Windows clients creates an awkward situation for users that need to access the same files (in their home directories, for example) with locally executing applications on their server, and by means of an X Window System session on a UNIX host. See Figure 25-4.
Figure 25-4 Multiprotocol IBM System Storage N series storage system
25.3.1 CIFS access of UNIX security data
In a multiprotocol environment enabled by the IBM System Storage N series, requests for heterogeneous access to data are common. A method of access for CIFS to UNIX data and its security structure must be provided. This section explains how to provide that access and structure on the IBM System Storage N series.
Steps for CIFS access of UNIX security style data
Figure 25-5 describes the process when a user on a Windows host accesses data with UNIX-style security using CIFS.
Figure 25-5 CIFS access of UNIX security style data
Detailed procedure
The following steps outline the steps illustrated in Figure 25-5 in detail:
1. The user begins a login from the Windows host.
As part of the login process, the host communicates with the user’s domain controller or the local security database (if the user is logging in as a local user). The process can vary depending on whether the user is part of an Active Directory domain or an NT domain, or is a local user.
2. The user’s credential is returned to the Windows host.
The result is a credential that contains the user SID and the user’s group SIDs.
If the user is from a non-trusted domain and the domain guest account is enabled, the domain controller authenticates the user with the guest credentials. If a user is logging in locally to a Windows workstation where the local guest account is enabled and does not have a local account, the user is authenticated with the local guest credentials.
3. The user requests access to data stored on a IBM System Storage N series file system through the session setup and connect requests (either through mapping a drive or accessing through a UNC path).
When a Windows user requests access to data on a IBM System Storage N series file system, an authenticated session must first be set up and then the connection to the share must be made. The steps for session setup depend on the authentication protocol negotiated between the storage system and the client.
The Windows client determines which protocol is used. The storage system supports NTLMv1, NTLMv2, Kerberos, and clear text password authentication:
– Windows NT LAN Manage (NTLM) authentication:
Used when the storage system is a member of an NT 4 domain, when operating in local workgroup mode, or if the Windows client requests that NTLM authentication be used.
After the NTLM authentication protocol is negotiated, the client sends a session setup request. The request contains the user name along with NTLM authentication information and other information used in session setup.
– Kerberos authentication:
Used when the storage system is a member of an Active Directory domain and Kerberos authentication is negotiated between the client and the storage system.
After the Kerberos authentication protocol is negotiated, the client sends a session setup request. Kerberos uses tickets for authenticating user requests to network services. The session setup request contains a Ticket Granting Service (TGS) ticket for the storage system’s CIFS service. This ticket is embedded in the session setup request and contains a security blob with all of the information necessary for the storage system to authenticate the user. The TGS ticket also contains the user SID and the SIDs for all of the user’s domain groups.
4. The storage system processes the session setup request:
– Windows NT LAN Manage (NTLM) authentication:
In a domain environment, the storage system does not store information about the user’s Windows password; therefore, with NTLM authentication, the storage system must send the user information and NTLM authentication information to the domain controller, which performs the actual user authentication.
– Kerberos authentication:
Even though the request contains all of the information needed to authenticate the user session, the user name is not in the security blob; therefore, the storage system first consults the system’s SID cache to see if the user name for that SID is in cache. If it is not, the storage system queries the user’s domain controller and does a SID lookup.
5. The domain controller processes the request sent by the storage system and provides the information that the storage system needs to complete the session setup:
– Windows NT LAN Manage (NTLM) authentication:
The domain controller returns success or failure for the user authentication. If the user is authenticated, the domain controller also returns SIDs for the user and the user’s groups. The storage system then includes the SIDs of any local groups to which the user belongs and stores this information in the user’s CIFS session cache.
If the user who is requesting session setup is a local storage system user, the session authentication is handled locally by the storage system, and the SIDs of the local groups to which the user belongs are added to the user’s session cache.
– Kerberos authentication:
The domain controller returns the user name to the storage system, which already has the user SID and the user’s domain group SIDs. The storage system then includes the SIDs of any local groups to which the user belongs, and all SID information is stored in the user’s session cache.
|
Requirements: In a domain environment, before the storage system can query the domain controllers, the storage system must have a machine account in the domain and must authenticate to the domain and establish a Netlogon pipe. In a Kerberos environment, the storage system must obtain a valid Granting Ticket for the machine account. There can be additional traffic between storage system and domain controllers during the session setup; however, the basic process is as outlined here.
|
If the user is connecting as a guest, the storage system denies access unless the option to allow guest account connection is set, as shown in Example 25-3.
Example 25-3 Setting the option to allow a guest connection
itsotuc2*> options cifs.guest_account unix_name
No confirmation will be given that this has been successful. Run the following to display current settings
itsotuc2*> options cifs.guest_account
cifs.guest_account ‘value of unix_name’
In this example, unix_name is a user created in the UNIX identity store, that is, /etc/passwd, NIS, or LDAP.
If guest access to the storage system is not desired, set this option to a null value, as shown in Example 25-4. All guest access requests will be denied. The default for this option is NULL. Guest access is denied by default.
Example 25-4 Setting CIFS guest account to null
itsotuc2*> options cifs.guest_account ""
No confirmation will be given that this has been successful. Run the following to display current settings
itsotuc2*> options cifs.guest_account
cifs.guest_account
If the user is connecting to the storage system as a local user, the cifs.guest_account option determines whether access as a guest user is allowed or denied.
6. The user requests access to data on the storage system that uses UNIX-style file permissions, but the request contains Windows-style SIDs.
The storage system cannot use the SIDs sent in the file access request for the access check. Instead, the storage system must compare UNIX user and group information to the file UNIX permission to determine access for the user. Therefore, the storage system maps the Windows user to the corresponding UNIX user.
Additionally, current Data ONTAP implementations store the UNIX credentials with the user’s session cache. Therefore, the Windows-to-UNIX user mapping occurs prior to completion of the session setup and connection to the share.
7. The storage system uses the Windows user name to begin the user mapping process.
The storage system checks /etc/usermap.cfg or the LDAP user mapping entries (if configured) to see if there is a specific mapping entry for the Windows user.
If there is a specific mapping entry, the storage system uses this entry for the user mapping process.
If there is not a specific mapping entry, the storage system assumes that the UNIX user name is the same as the Windows user name and uses this name during the mapping process automatically.
|
Important: If there is not a specific mapping entry in /etc/usermap.cfg or in the LDAP store (if LDAP user mapping is configured), and the Windows user name is used automatically, the mapping process is still performed. It is important to determine if the UNIX user is a valid user or not. If the mapped name is not a valid user, access can be as the default user or it can be completely disallowed, depending on how the WAFL option wafl.default_unix_user is configured.
|
8. The storage system queries the configured UNIX name services to determine if the mapped user name is a valid UNIX user.
If the user name is a valid UNIX user, the mapping process continues.
If the user name is not a valid UNIX user, the user is either mapped to the generic UNIX account or access is denied, depending on how the WAFL option wafl.default_unix_user is configured.
9. The configured UNIX name service replies to the query, either supplying information about the user or returning an error indicating that the user is not found.
10. The storage system queries the UNIX name services for the mapped UNIX user’s user and group information.
11. The UNIX name service replies to the query, supplying information about the UNIX user’s credential, including the user’s UID and GIDs (including secondary group GIDs).
The UNIX credential is stored with the user’s cached authenticated session information.
The user mapping information in this process is not stored in the wcc. If the same user establishes a new CIFS connection, the process is re-executed.
12. Now that the UNIX credentials have been added to the authenticated session cache, the storage system can reply to the session setup request, with either a success or a failure.
If the session request was successful, the connection request to the share can be processed, and is either allowed or denied based on evaluation of user and group share permissions.
13. The Windows user requests access through the mapped drive to a file or folder in the UNIX security style volume.
14. The storage system uses the UNIX user information stored in the user’s session cache and compares it to the UNIX permissions on files and directories for which access has been requested.
The system then determines if the desired action is allowed or not allowed.
Because the file system has UNIX security style, with UNIX rwxrwxrwx type of file permissions, the storage system uses the UID and GIDs with the access check. The system determines if the UID is the owner of the file. If not, the system determines if any of the user’s groups are the objects group owner. If not, then other permissions apply (if the default user is configured). The system then determines if the desired action is allowed or not allowed.
15. The system replies to the access request, either permitting the requested action if the file permissions allow it or denying the action if the permissions do not allow it.
|
Scope: This section does not describe how the process handles access requests by Windows administrators.
|
25.3.2 CIFS access of NTFS data
This section describes native CIFS access to NTFS data. It provides high-level steps for CIFS access.
Steps for CIFS access of NTFS security style data
Figure 25-6 describes the process when a user on a Windows host accesses data with NTFS security style using CIFS.
Figure 25-6 CIFS access of NTFS security style data
Detailed procedure
The following steps outline the steps illustrated in Figure 25-6 in detail:
1. The user begins a login from the Windows host.
As part of the login process, the host communicates with the user’s domain controller or the local system’s local security database (if the user is logging in as a local user). The process can vary, depending on whether the user is part of an Active Directory domain or an NT domain, or is a local user.
2. The user’s credential is returned to the Windows host.
The result is a credential that contains the user SID and the user’s group SIDs.
If a user is from a nontrusted domain and the domain guest account is enabled, the domain controller authenticates the user with the guest credentials. If a user is logging in locally to a Windows workstation where the local guest account is enabled and does not have a local account, the user is authenticated with the local guest credentials.
3. The user requests access to data stored on an IBM System Storage N series file system through the session setup and connect requests, either through mapping a drive or accessing through a Uniform Naming Convention (UNC) path.
|
Path: The format for a UNC path is \server nameshared volumeshared directory
ame of file and is not case-sensitive.
Typically, the location of a file is described by the drive letter and folder in which it is located. It is likely to be unique to the host that this location is mapped to, whereas specifying a UNC path is more specific and is common across all operating systems.
|
When a user requests access to data on a IBM System Storage N series file system, an authenticated session must first be set up and then the connection to the share must be made. The steps for session setup depend on the authentication protocol negotiated between the storage system and the client. The Windows client determines which protocol is used. The storage system supports NTLMv1, NTLMv2, Kerberos, and clear text password authentication:
– NTLM authentication:
Used when the storage system is a member of an NT 4 domain, when operating in local workgroup mode, or if the Windows client requests that NTLM authentication be used.
After the NTLM authentication protocol is negotiated, the client sends a session setup request. The request contains the user name, along with NTLM authentication information and other information used in session setup.
– Kerberos authentication:
Used when the storage system is a member of an Active Directory domain and Kerberos authentication is negotiated between the client and the storage system.
After the Kerberos authentication protocol is negotiated, the client sends a session setup request. Kerberos uses tickets for authenticating user requests to network services. The session setup request contains a Ticket Granting Service (TGS) ticket for the storage system’s CIFS service. This ticket is embedded in the session setup request and contains a security blob with all of the information necessary for the storage system to authenticate the user. The TGS ticket also contains the user SID and the SIDs for all of the user’s domain groups.
4. The storage system processes the session setup request:
– Windows NT LAN Manage (NTLM) authentication:
In a domain environment, the storage system does not store information about the user’s Windows password; therefore, with NTLM authentication, the storage system must send the user information and NTLM authentication information to the domain controller, which performs the actual user authentication.
– Kerberos authentication:
Even though the request contains all of the information needed to authenticate the user session, the user name is not in the security blob; therefore, the storage system consults the system’s SID cache to see if the user name for that SID is in the cache. If it is not, the storage system queries the user’s domain controller and does a SID lookup.
5. The domain controller processes the request sent by the storage system and provides the information that the storage system needs to complete the session setup:
– Windows NTLM authentication:
The domain controller returns success or failure for the user authentication. If the user is authenticated, the domain controller also returns SIDs for the user and the user’s groups. The storage system then includes the SIDs of any local groups to which the user belongs and stores this information in the user’s CIFS session cache.
If the user who is requesting session setup is a local storage system user, the session authentication is handled locally by the storage system, and the SIDs of the local groups to which the user belongs are added to the user’s session cache.
– Kerberos authentication:
The domain controller returns the user name to the storage system, which already has the user SID and all the user’s domain group SIDs. The storage system then includes the SIDs of any local groups to which the user belongs, and all SID information is stored in the user’s session cache.
|
Requirements: In a domain environment, before the storage system can query the domain controllers, the storage system must have a machine account in the domain and must authenticate to the domain and establish a Netlogon pipe. In a Kerberos environment, the storage system must obtain a valid Ticket Granting Ticket for the machine account. There can be additional traffic between storage system and domain controllers during the session setup; however, the basic process is as outlined here.
|
If the user is connecting as a guest, the storage system denies access unless the option to allow guest account connection is set, as shown in Example 25-5.
Example 25-5 Setting the option to allow guest connection
itsotu2*> options cifs.guest_account unix_name
No confirmation will be given that this has been successful. Run the following to display current settings
itsotuc2*> options cifs.guest_account
cifs.guest_account ‘value of unix_name’
In this example, unix_name is a user created in the UNIX identity store, that is, /etc/passwd, NIS, or LDAP.
If guest access to the storage system is not desired, set this option to a null value, as shown in Example 25-6. All guest access requests will then be denied. The default for this option is NULL. Guest access is denied by default.
Example 25-6 Setting CIFS guest account to null
itsotuc2*> options cifs.guest_account ""
No confirmation will be given that this has been successful. Run the following to display current settings
itsotuc2*> options cifs.guest_account
cifs.guest_account
If the user is connecting to the storage system as a local user, the option cifs.guest_account determines if access as a guest user is allowed or denied.
6. The user requests access to data on the storage system that uses NTFS-style file permissions. The storage system uses the Windows-style SIDs when evaluating file access rights; however, current implementations of Data ONTAP always perform a user mapping when data is requested via CIFS.
The UNIX credentials, containing all of the mapped UNIX user’s UID and GIDs, are stored with the Windows user’s session authentication cache; therefore, a Windows-to-UNIX user mapping must be done before the session setup is complete.
Therefore, the storage system maps the Windows user to the corresponding UNIX user, even in the case where a Windows user is accessing data stored in an NTFS volume.
7. The storage system uses the Windows user name to begin the user mapping process.
The storage system checks /etc/usermap.cfg or the LDAP user mapping entries (if configured) to see if there is a specific mapping entry for the Windows user.
If there is a specific mapping entry, the storage system uses this entry for the user mapping process.
If there is not a specific mapping entry, the storage system assumes that the UNIX user name is the same as the Windows user name and uses this name during the mapping process automatically.
|
Important: If there is not a specific mapping entry in /etc/usermap.cfg or in the LDAP store (if LDAP user mapping is configured) and the Windows user name is automatically used, the mapping process is still performed. It is important to determine if the UNIX user is a valid user or not. If the mapped name is not a valid user, access can be as the default user, or it can be completely disallowed, depending on how the WAFL option wafl.default_unix_user is configured.
|
8. The storage system queries the configured UNIX name services to determine if the mapped user name is a valid UNIX user.
If the user name is a valid UNIX user, the mapping process continues.
If the user name is not a valid UNIX user, the user is either mapped to the generic UNIX account or access is denied, depending on how the WAFL option wafl.default_unix_user is configured.
9. The configured UNIX name service replies to the query, either supplying information about the user or returning an error indicating that the user is not found.
10. The storage system queries the UNIX name services for the mapped UNIX user’s user and group information.
11. The UNIX name service replies to the query, supplying information about the user, including the user’s UID and GIDs (including secondary group GIDs).
The UNIX credential is stored with the user’s cached authentication session information.
The user mapping information in this process is not stored in the wcc. If the same user establishes a new CIFS connection, the process is executed again.
12. Now that the UNIX credentials have been added to the authenticated session cache along with the Windows user SID information, the storage system can reply to the session setup request, with either a success or a failure.
If the session request was successful, the connection request to the share can be processed, and is either allowed or denied, based on evaluation of user and group share permissions.
13. The Windows user requests access through the mapped drive to a file or folder in the NTFS security style volume.
14. The storage system uses the Windows user information stored in the user’s session cache and compares it to the NTFS permissions on files and directories for which access has been requested. The system uses the Windows user and group SIDs to determine if the desired action is allowed or not allowed. The system then determines if the desired action is allowed or not allowed.
15. The system replies to the access request, either permitting the requested action if the file permissions allow it or denying the action if the permissions do not allow it.
|
Scope: This section does not describe how the process handles access requests by Windows administrators.
|
25.3.3 CIFS access of NTFS data
A IBM System Storage N series storage system supports four CIFS access methods. The method is chosen during CIFS setup.
Joining a workgroup using /etc/password, NIS, or LDAP for authentication offers a substantially different method for managing file and folder access. Example 25-7 illustrates this method.
Example 25-7 CIFS setup and access method designation
1) Active Directory domain authentication (Active Directory domains only)
(2) Windows NT 4 domain authentication (Windows NT or Active Directory domains)
(3) Windows Workgroup authentication using the filer's local user accounts
(4) /etc/passwd and/or NIS/LDAP authentication
Selection (1-4)? [1]:
In this example, we describe CIFS access in workgroup mode.
Steps for CIFS access in workgroup mode
When CIFS access is based on workgroup using /etc/password, NIS, or LDAP, session authentication is done on the basis of user names and passwords that are stored in the UNIX directory stores. Even if local Windows users are created on the storage system using the useradmin command, they are not used for session authentication. All authentication is done based on UNIX user information that is stored in the UNIX identity stores.
If the volume that is accessed uses NTFS-style security, ACLs are not used during the access check, even if the file or folders has valid ACLs. File access is determined by share level permissions. From the user’s point of view, an NTFS-style security volume is a FAT volume.
If the volume being accessed uses UNIX-style security, UNIX file permissions in conjunction with share permissions are used to determine access.
Detailed procedure
Here are the steps for CIFS access in workgroup mode:
1. The Windows client requests access to the data.
The user who is logged in to the Windows client can be a domain user or a local user. However, when mapping the drive, the user must use one of the following methods:
– Map the drive using a different user name, where the user name and password are the name and password of a UNIX user stored in the UNIX identity store.
– Use pass-through authentication, where the logged-in user is using the same user name and password as a user stored in the UNIX identity store of the storage device.
2. The storage device maps the Windows account name to the UNIX account name.
3. The storage device checks /etc/password and /etc/group, NIS, or LDAP to retrieve the UNIX UID and GIDs.
4. The storage system compares account information with share level permissions.
5. The storage system compares account information with UNIX permissions or DOS attribute bit.
6. If the user has both share and file level access, then access is granted.
25.4 Altering qtree security at the qtree level or volume level
This section gives an illustration of how to alter qtree security at the qtree level or volume level.
To alter qtree security at the qtree level or volume level, perform the following steps:
1. Start the N series System Manager.
2. Select your storage system.
3. Select storage.
4. Select qtrees.
5. Select your qtree and perform a right mouse click on the qtree to edit the security options as shown in Figure 25-7.
Figure 25-7 qtree security style change
25.5 NFS
Most UNIX clients use NFS for remote file access. Sun Microsystems introduced NFS in 1985. Since then, it has become a de facto standard protocol, used by 10 million systems worldwide. NFS is particularly common on UNIX-based systems, but NFS implementations are available for virtually every modern computing platform in current use, from desktops to supercomputers. Only when used by UNIX-based systems, however, does NFS closely resemble the behavior of a client’s local file system.
25.6 CIFS
The operating systems running on Windows clients do not include NFS. Instead, the protocol for remote file access is CIFS, formerly known as Server Message Block (SMB). SMB was first introduced by Microsoft and Intel in the early 1980s, and is the protocol used in several diverse PC network environments.
25.7 NFS compared to CIFS
The NFS protocol versions 1 to 3 are stateless protocols. NFS operations are idempotent (can be repeatedly applied harmlessly), or, if non-idempotent (file deletion, for example), are managed safely by the server. Clients are oblivious to server restarts (if service is restored promptly), with a few exceptions. The NFS protocol emphasizes that error recovery over file locking error recovery is simple if no state must preserved. To the contrary, NFS version 4 is a stateful protocol.
A CIFS file server is stateful (not stateless). The CIFS protocol emphasizes locking over error recovery, because Windows applications rely on strict locking. Strict locking requires a sustained connection. It is imperative that an active session not be interrupted.
Applications executing on Windows clients react to a CIFS server in exactly the same manner as they do to local disk drives. A down server is no different from an unresponsive disk drive. Therefore, Windows clients must be warned and allowed time to gracefully disengage (that is, save files, exit applications, and so on) before a server shuts down or restarts.
25.8 Mixing NFS and CIFS
Software solutions exist that allow UNIX-based servers to provide remote file access functionality to Windows clients without requiring NFS. Running in user mode (not in the UNIX kernel), these applications support Windows clients through CIFS. Of these, the most widely used are Samba, Hummingbird NFS Maestro, and Windows Service for UNIX (SFU) by Microsoft. Samba is a server-side installation. NFS Maestro and SFU are NFS emulators installed on the clients running NTFS.
For users with a casual need for CIFS access, or who are new to PCs and are trying to get a feel for what Windows service is like, Samba offers several advantages:
•It is available at no cost.
•It is easily available.
•It runs on most popular UNIX systems.
•It is relatively reliable for simple uses.
For more serious requirements (for example, providing primary file service for a large organization), however, Samba falls short in several important areas:
•Shallow integration with the underlying UNIX-centric file system (particularly with respect to locking mechanisms)
•Difficulty of installation, configuration, and administration
•Lack of reliable support (It is public domain software.)
25.9 Multiprotocol file service
A file server cannot easily deliver functionality to clients beyond what its local file system provides. For example, the UNIX File System (UFS) does not store the creation time stamp for a file. A Windows client cannot retrieve that information through the CIFS protocol if the server does not have that information to provide.
The NFS protocol does not offer mechanisms for data access beyond the capabilities of UFS. NFS was developed to extend UFS across networks. Similarly, the CIFS protocol extends a Windows-oriented file system to remote clients. In both of these cases, the remote file access protocol implementation is described as native to the operating system context in which it originated.
25.9.1 Emulated multiprotocol file service
When application software such as Samba provides remote data access to the files on a UNIX file server through the CIFS protocol, it must do more than simply provide semantically correct responses in its communication with clients over the wire. It must make up the difference between the personal computer’s requirements and the intrinsic facilities of the server’s local file system (UFS).
On a file-by-file basis, it must store additional information (in supplementary files, if the file system itself has no provision for it). For example, the server must offer case-insensitive file name lookup for personal computer clients. For older personal computer clients, the server must also generate DOS-style 8.3 file names (consisting of up to eight characters, plus up to three characters for an optional suffix).
An 8.3 file name is not inherently included in UFS, so the CIFS emulation application must store it elsewhere. Similarly, UFS does not provide case-insensitive file name lookup. The CIFS server emulation application must do that for itself.
The mapping from the Windows clients’ expectations to the server’s UNIX context is awkward and incomplete. The reverse situation (that is, a Windows server serving UNIX clients through NFS application software) is similarly mismatched. This dissonance is characteristic of emulated remote file access protocol implementations.
25.9.2 Native multiprotocol file service
IBM System Storage N series storage systems are not UNIX-based, nor are they Windows based. The microkernel operating system and WAFL file system are designed specifically for extensible file service.
Therefore NFS, CIFS, and HTTP (and in the future, additional protocols) can be implemented natively. There is no functionality mismatch (as with the emulated approaches), and kernel-based security and file locking enforcement are inherently stronger than user-space application software methods, as illustrated in Figure 25-8.
Note that in Figure 25-8, all IBM System Storage N series processing of a client’s request is executed within the kernel as a series of function calls, thus eliminating the data copies and impact of the interprocess communication (IPC) between the separate processes in the emulated approach.
Figure 25-8 Processing of client requests
These are the three primary elements in the Data ONTAP microkernel:
•A real-time mechanism for process execution
•The WAFL file system
•The RAID manager
Of these, only the RAID manager is insensitive to whether protocol blocks are read and written in the same way, whether originally triggered by NFS or CIFS.
Figure 25-9 provides a block diagram view of Data ONTAP software. Note that NFS can operate with either TCP or UDP transport mechanisms, but IBM System Storage N series support for the CIFS file-sharing protocol uses TCP exclusively.
|
Attention: CIFS uses NetBIOS over TCP/IP (NBT) in the IBM System Storage N series implementation, but can also use NETBEUI or IPX/SPX in other environments.
|
Figure 25-9 Data ONTAP software
Within the microkernel, all incoming NFS, CIFS, and HTTP requests are received by the network interface driver. After being initiated, the processing of a request is uninterrupted and continuous, as far as possible, utilizing a series of function calls. (It is entirely different from traditional file servers, which employ separate processes for the network protocol stack, the remote file system semantics, the local file system, and the disk subsystem.)
The advantages of this approach are performance and simplicity, and the simplicity enables extraordinary reliability. The process (which begins with the network interface driver) executes continuously and blocks only when waiting is unavoidable.
Ordinarily, this will occur only when the request has reached the WAFL file system. By this stage, the request has been interpreted with respect to the applicable protocol (NFS, CIFS, or HTTP) and tested for correctness and legality. If the request cannot be serviced (for example, because it is illegal or otherwise incorrect) an error code is immediately returned.
Assuming that the request can and ought to be serviced, a reply to the client is generated, unless one of the following conditions causes the process to block:
•A request requires data not already in memory.
•An administrative event preempts other processing.
Figure 25-10 illustrates the process flow for all cases except administrative events. (Administrative commands take effect immediately, possibly causing other operations to block.)
Figure 25-10 Client request processing
If a read request cannot be satisfied with data already in memory (from a previous read request or because of read-ahead), the process will block, while WAFL requests the RAID manager to retrieve the requested data (and the next several blocks deeper in the file. It occurs unless the minra option has been enabled, which limits read-ahead to a single block).
IBM System Storage N series storage systems serve all incoming requests with a continuous series of function calls (not IPCs) that block only when necessary, as described. This architecture is exceptionally well-suited to a multiprotocol context because it simply does not matter which protocol is used. All requests are handled expeditiously as single processes running in the kernel, regardless of protocol. Circumstances where a process might block are similar across protocols. The WAFL file system is extensible, allowing for native accommodation of both UNIX-style and Windows-style file and directory attributes.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.