Front cover
IBM System Storage N series
Multiprotocol Use Guide
Discusses multiprotocol access and
group mapping
Provides caching user mapping
information
Includes managing file and
folder security details
Alex Osuna
Gary R. Nunn
Ellie Berriman
ibm.com/redbooks
International Technical Support Organization
IBM System Storage N series Multiprotocol Use
Guide
September 2007
SG24-7469-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page v.
First Edition (September 2007)
This edition applies to Version 7.1 or higher of Data ONTAP.
© Copyright International Business Machines Corporation 2007. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP
Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Chapter 1. Multiprotocol on the IBM System Storage N series. . . . . . . . . . 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Multiprotocol on the System Storage N series . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Authentication in a multiprotocol environment . . . . . . . . . . . . . . . . . . 4
1.3 Export and share security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Share level access control list (ACL) . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.2 Export options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Data ONTAP file security styles and multiprotocol access . . . . . . . . . . . . . 6
1.5 Qtree security styles and the System Storage N series . . . . . . . . . . . . . . . 7
1.6 Security styles and user mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6.1 UNIX qtrees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.2 NTFS qtrees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6.3 Mixed qtrees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Multiprotocol access and group mapping . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.8 Caching user mapping information: The WAFL credential cache . . . . . . . 12
1.9 Managing file and folder security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 2. Display and effective permissions in a multiprotocol
environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Display and effective permissions prior to Data ONTAP 7.2 . . . . . . . . . . . 16
2.1.1 Display permissions versus effective permissions . . . . . . . . . . . . . . 16
2.2 Display and effective permissions beginning with Data ONTAP 7.2 . . . . . 20
Chapter 3. Changing security styles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Changing an NTFS or mixed volume with NTFS effective security to a UNIX
volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Changing a UNIX or mixed volume with UNIX effective security to an NTFS
volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Root and administrative access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Root privileged access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 Windows administrator privileged access . . . . . . . . . . . . . . . . . . . . . 28
© Copyright IBM Corp. 2007. All rights reserved.
iii
3.3.3 Mixed security style and Windows administrator and root privileged
access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 The multiprotocol access process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Chapter 4. NFS access of data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 NFS access of UNIX security style data . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1 Steps for NFS access of UNIX security style data . . . . . . . . . . . . . . 32
4.2 NFS access of NTFS security style data . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1 Steps for NFS access of NTFS security style data . . . . . . . . . . . . . . 34
Chapter 5. CIFS access of UNIX security style data . . . . . . . . . . . . . . . . . 37
5.1 Steps for CIFS access of UNIX security style data . . . . . . . . . . . . . . . . . . 38
Chapter 6. CIFS access of NTFS security style data . . . . . . . . . . . . . . . . . 45
6.1 Steps for CIFS access of NTFS security style data . . . . . . . . . . . . . . . . . 46
Appendix A. CIFS access in workgroup mode . . . . . . . . . . . . . . . . . . . . . . 53
Steps for CIFS access in workgroup mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Appendix B. Qtree security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Alter qtree security at the qtree level or volume level. . . . . . . . . . . . . . . . . . . . 56
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
How to get IBM Redbooks publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
iv
IBM System Storage N series Multiprotocol Use Guide
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
© Copyright IBM Corp. 2007. All rights reserved.
v
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks (logo)
DS4000™
IBM®
®
Redbooks®
Sequent®
System Storage™
Tivoli®
The following terms are trademarks of other companies:
Network Appliance, WAFL, FilerView, Data ONTAP, and the Network Appliance logo are trademarks or
registered trademarks of Network Appliance, Inc. in the U.S. and other countries.
Active Directory, Microsoft, Windows NT, Windows, and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
vi
IBM System Storage N series Multiprotocol Use Guide
Preface
Many customer sites need to access data from both Windows® and UNIX®
clients. For these environments, Data ONTAP® has native multiprotocol support.
After the user is authenticated on the network, if the user has both appropriate
share or export permissions and the necessary file permissions, the user can
access all data from UNIX hosts using Network File System (NFS) or from
Windows hosts using Common Internet File System (CIFS).
IBM® System Storage™ N series provides native multiprotocol support by
supporting multiple security models. This IBM Redbooks® publication discusses
those models in detail.
This book can help storage administrators in determining what type of data
access configuration is appropriate for their environment.
The team that wrote this book
This book was produced by a team of specialists from around the world working
at the International Technical Support Organization (ITSO), Tucson Center.
Alex Osuna is a Project Leader at the ITSO, Tucson Center. He writes
extensively and teaches IBM classes about all areas of storage. He has more
than 28 years in the IT industry working for United States Air Force, IBM, and
Tivoli® in computer maintenance, field engineering, service planning,
Washington Systems Center, business and product planning, advanced
technical support, and systems engineering focusing on storage hardware and
software. He has more than 10 certifications from IBM, Microsoft®, and Red Hat.
Gary R. Nunn is a SAN support specialist based in Bristol, U. K. His role
includes support of the IBM DS4000™ products, IBM NAS, San Volume
Controller, and SAN switches across a broad range of customer environments.
He has been in this role for almost four years. His background is in electronics,
where he served 10 years with the British Army, specializing in radar support and
repair. After leaving the Army, he then worked as a Support Engineer for wireless
networks for three years before moving to hardware support for the Sequent®
UNIX based systems NUMA and Symmetry and associated SAN attached
storage. He performed this role until 2003, where he then migrated to his current
position.
Ellie Berriman is a employee of Network Appliance™ Corporation.
© Copyright IBM Corp. 2007. All rights reserved.
vii
Figure 1 Gary Nunn and Alex Osuna
Become a published author
Join us for a two- to six-week residency program! Help write a book dealing with
specific products or solutions, while getting hands-on experience with
leading-edge technologies. You will have the opportunity to team with IBM
technical professionals, Business Partners, and Clients.
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you will develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
viii
IBM System Storage N series Multiprotocol Use Guide
Comments welcome
Your comments are important to us!
We want our books to be as helpful as possible. Send us your comments about
this book or other IBM Redbooks in one of the following ways:
򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
򐂰 Send your comments in an e-mail to:
redbooks@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Preface
ix
x
IBM System Storage N series Multiprotocol Use Guide
1
Chapter 1.
Multiprotocol on the IBM
System Storage N series
IBM System Storage N series provides access to data that is stored in both UNIX
and Common Internet File System (CIFS) networking environments. This access
is transparent to the client because of native multiprotocol support, which
provides a bridge between UNIX file security and Windows file security by
mapping the UNIX identities and Windows identities (see Figure 1-1).
This chapter provides a summary of how the security styles and user mapping
work together to provide seamless access to data.
© Copyright IBM Corp. 2007. All rights reserved.
1
Multiprotocol, Heterogeneous Environment
iSCSI
FCP
CIFS
NFS
Figure 1-1 Multiprotocol access
1.1 Introduction
Some customer sites have pure Windows or pure UNIX environments, where all
data is accessed using either CIFS and NTFS file security or using NFS and
UNIX file security. However, many customer sites need to access data from both
Windows and UNIX clients. For these environments, Data ONTAP has native
multiprotocol support. After the user is authenticated on the network, if the user
has both appropriate share or export permissions and the necessary file
permissions, the user can access all data from UNIX hosts using NFS or from
Windows hosts using CIFS.
System Storage N Series provides this type of access by supporting multiple
security models. When a client requests access to a file with UNIX security, the
client must present UNIX credentials. Similarly, if a client requests access to a
file with NTFS security, the client must present CIFS credentials. Because the
UNIX security model and the Windows security model do not directly correlate,
one security style’s credentials cannot be used when accessing data with a
non-native security style.
Because both models use the concept of a user for authentication and
authorization, System Storage N series has implemented user mapping to
provide a bridge between the two security styles. When an NFS user requests
access to a file that uses non-native NTFS file security, the user is mapped to the
2
IBM System Storage N series Multiprotocol Use Guide
corresponding CIFS identity, and the CIFS credentials are used for access
checks. File access is granted or denied after the mapped user’s credentials are
evaluated against the file’s Windows Access Control List (ACL). Any time a CIFS
client accesses data that is stored on a System Storage N series, a mapping
process takes place, even if the access request is to data with NTFS Windows
ACLs. Figure 1-2 illustrates this mapping process.
Windows Users
User request checked
Against Windows ACL
Alex
Gary
Helvio
Chico
Windows
ACL
NFS request
User Roman maps
To Windows id
Alex
Myfile.bat
Access
granted
Oscar
Carlos
Figure 1-2 NFS file access request
This book provides a summary of the practical application of multiprotocol
access of data stored on the IBM System Storage N series. For more information
about multiprotocol concepts and theory, see Multiprotocol Data Access with IBM
System Storage N series, REDP-4176, which is available at:
http://www.redbooks.ibm.com/redpapers/pdfs/redp4176.pdf
1.2 Multiprotocol on the System Storage N series
Before users request access to data on the network, they must be authenticated
by whatever method is configured in the customer environment. Users who log in
from a Windows client are typically authenticated in a Windows domain. Less
frequently, they are authenticated locally on the workstation. UNIX users are
typically authenticated locally by the system or by Kerberos—a secure,
network-based authentication service. After the drive is mapped or an export is
mounted, the user can request access to data.
Chapter 1. Multiprotocol on the IBM System Storage N series
3
1.2.1 Authentication in a multiprotocol environment
UNIX/NFS and Windows/CIFS differ in how they authenticate users:
򐂰 On UNIX systems, an export can be mounted manually by root or, more
typically, can be mounted at boot time or mounted on demand by the
automounter. After the export is mounted, the user can request access to
data.
NFS is a connectionless protocol, and each NFS request includes the UID
and GIDs of the user making the request. The UNIX client determines the UID
and GIDs when the user first logs in, by retrieving the information from
/etc/passwd and /etc/groups, NIS, or the LDAP identity store.
򐂰 Before the authenticated Windows user can access data on a storage
system, the user must create an authenticated session with the storage
system (mapping a drive). Because CIFS is session based, the identity of the
user can be determined just once, when the session is first set up.
1.3 Export and share security
In addition to file security, access to data over a network is secured by share or
export access checks.
When data is accessed from a Windows client from CIFS, a share to the data
must exist, and the user must have sufficient share permissions to perform the
requested action. This is true whether the file security style is UNIX or NTFS.
Windows share permissions and NTFS Windows ACLs are both user based.
When you are evaluating whether a specific action is permitted on the file, both
share and file permissions must allow it.
When data is accessed from a UNIX client with NFS, an export to the data must
exist and the UNIX client must have sufficient export permissions to perform the
requested action. This is true whether the file security style is UNIX or NTFS.
UNIX export rules are host based; therefore when a user wants to perform an
action on a file or folder over NFS, the UNIX host must be permitted the
requested action and the user’s credential must have the required file access
permissions.
4
IBM System Storage N series Multiprotocol Use Guide
1.3.1 Share level access control list (ACL)
The following facts describe share level access management:
򐂰 Share level ACLs include Full Control, Change, Read, and No Access.
򐂰 The effective rights of a user are the combination of share and Windows
ACLs.
򐂰 The most restrictive permissions take effect.
򐂰 No Access takes precedence over any granted permissions, file, or share.
򐂰 CIFS share ACLs can be managed through the Windows Computer
Management snap-in, through FilerView®, or through the cifs access
command.
1.3.2 Export options
The following export options are available with the System Storage N series:
򐂰 Export options are set on the storage system with the /etc/exports file.
򐂰 Exports can be manually changed or added with the exportfs command.
򐂰 Export options apply to the host; however, the effective permissions for the
user are based on the combined export and file access controls.
򐂰 The most restrictive permission takes effect. If a file system is exported as
read only, the user has read-only access even if the file permission would
grant write access.
򐂰 The root export option is used to grant root access to the System Storage N
series file system to the root user on UNIX hosts.
Chapter 1. Multiprotocol on the IBM System Storage N series
5
1.4 Data ONTAP file security styles and multiprotocol
access
All files and folders stored on System Storage N series are protected by one of
two file security schemes: UNIX or NTFS. The effective security schemes are
represented by three security styles: UNIX, NTFS, and mixed. Here are some
facts about these security schemas:
򐂰 Every volume and qtree is given a default security style when it is created.
The default security style is set with the option shown in Example 1-1.
Example 1-1 To display and set the WAFL® default security settings
To view current settings
itsotuc3*> options wafl.default_security_style
wafl.default_security_style unix
To alter default settings
itsotuc3*> options wafl.default_security_style ntfs
itsotuc3*>
(refer to Note)
Syntax is as follows
itsotuc3*> options wafl.default_security_style [unix | ntfs | mixed] (default:unix)
򐂰 The security style of a volume or qtree can be changed after it is created with
the command shown in Example 1-2.
Example 1-2 Setting and viewing the qtree security
Syntax is as follows
itsotuc3*> qtree security
qtree security <path> [unix | ntfs | mixed]
To view the current security settings
itsotuc3*> qtree security /vol/NFSvol_GRN
/vol/NFSvol_GRN/ has ntfs security style and oplocks are enabled.
To alter security settings
itsotuc3*> qtree security /vol/NFSvol_GRN unix
itsotuc3*>
(refer to Note)
6
IBM System Storage N series Multiprotocol Use Guide
Note: With reference to Example 1-1 and Example 1-2, after executing the
command to set the WAFL and qtree security settings, you will not receive a
confirmation that the command completed successfully. You can use the
option to view current settings to confirm that the change was made.
For more information about how to set and view qtree security settings using
FilerView, see Appendix B, “Qtree security” on page 55.
1.5 Qtree security styles and the System Storage N
series
The following qtree security styles are available with the System Storage N
series:
򐂰 UNIX qtree style indicates that the file security style of the qtree is UNIX
based.
򐂰 NTFS qtree style indicates that the file security style of the qtree is Windows
based.
򐂰 Mixed qtree style indicates that either the UNIX or the NTFS file security style
could be the effective security style for each file or folder within the qtree.
With mixed volumes or qtrees, some files in the qtree or volume might have
UNIX security style and some might have NTFS security style. Each file or folder
has only one security style, either NTFS or UNIX, but not both. A file's security
style depends on whether the permission was last set from CIFS or NFS. For
example, if a file currently uses the UNIX security style and a CIFS user sends a
set-ACL request to the file, the file's security style is changed to NTFS. If a file
currently uses the NTFS style and an NFS user sends a set-permission request
to the file, the file's security style is changed to UNIX.
Referring to security style does not refer to the type of client used to access the
data. Data in all three security styles can be accessed from both Windows and
UNIX hosts, if the appropriate user mapping is in place and if the share, export,
and file access permissions allow it.
Security style refers to the style of file permissions and the type of authorization
needed to access the directories and files within a volume or qtree.
Chapter 1. Multiprotocol on the IBM System Storage N series
7
For the UNIX security style, authorization to access directories and files is based
on access allowed to the user’s UNIX UID and GIDs, with access rules (see
Example 1-3) following the UNIX style of file permissions (rwxrwxrwx), where r =
read access, w = write access, and e = executable access.
Example 1-3 Brief explanation of UNIX permissions
[root@itso tmp]# ls –l
-rwxr--r-- 1 root root
0 Mar
5 09:49 test.file
Within UNIX each file or folder and even devices have a set of permissions
assigned to them. This set of permissions determines which users and groups
have access. Reviewing the output captured using ls –l we can see that the first
character indicates the file type. In this example, we are concerned with the next
nine characters, which determine who has access to the file.
Referring to Example 1-3 (reading from left to right):
rwx
r-r--
are the access rights that the user has
are the access rights for group members
are the access rights for others
In Example 1-3 the user has read, write, and execute access. The groups and
others have read access only.
For further information about UNIX permissions refer to online UNIX man pages
(for example man chmod, man chown, and man chgrp).
For the Windows security style, authorization to access folders and files is based
on access allowed to the user’s Windows SID and Windows group SIDs, with
access rules based on NTFS Windows security descriptors.
1.6 Security styles and user mapping
User mapping between Windows users and UNIX users is a fundamental part of
System Storage N series multiprotocol access. Multiprotocol access depends on
user mapping between a user’s UNIX identity and Windows identity to evaluate
the user’s rights to perform file and folder operations within volumes and qtrees.
This section explains the access logic that this process follows.
8
IBM System Storage N series Multiprotocol Use Guide
1.6.1 UNIX qtrees
A UNIX-style qtree is always accessed with a user’s UNIX credentials:
򐂰 If a user is accessing data from a UNIX or Linux® host, the user’s UID and
GIDs are used to determine access rights.
򐂰 If a user is accessing data in a UNIX volume from a Windows machine, Data
ONTAP first maps the Windows user name to its corresponding UNIX UID.
򐂰 If there is no corresponding UNIX user, by default, the Windows user is
mapped to the default UNIX user. The default user is designated with the
option shown in Example 1-4.
Example 1-4 Showing default WAFL user and example output if the user is not configured correctly
itsotuc3*> options wafl.default_unix_user
wafl.default_unix_user
pcuser
itsotuc3*>
itsotuc3*> options wafl.default_unix_user itso
wafl.default_unix_user itso no such user
Check that the user is correctly configured in /etc/passwd, NIS or LDAP
The designated default UNIX user can be any valid UNIX user designated by the
storage administrator, but the default user must exist in the storage system’s
/etc/passwd file (see Example 5), the NIS database, or the LDAP database.
Example 5 Example of filer /etc/passwd file
root:_J9...fWSfMKev6nmmbk:0:1::/:
pcuser::65534:65534::/:
nobody::65535:65535::/:
ftp::65533:65533:FTP Anonymous:/home/ftp:
If this option is set to the null string, Windows users who are not mapped to a
UNIX user are not allowed to connect to the storage controller through CIFS.
Therefore, if this option is set to the null string, it is vital that each Windows user
can successfully map to a specific UNIX user.
1.6.2 NTFS qtrees
An NTFS style file system is accessed with a user’s Windows credentials. Data
ONTAP always maps the user’s Windows identity to the user’s UNIX identity
when access is requested to data from a CIFS client even when the CIFS client
is accessing data in an NTFS-security style file or folder.
Chapter 1. Multiprotocol on the IBM System Storage N series
9
If a user is accessing NTFS-security style files or folders with Windows ACLs
from a Windows host, the SIDs of the user’s Windows user name and Windows
groups are used to determine NTFS access rights. The user and group SIDs are
compared to the file’s Windows security descriptor.
If a user is accessing files and folders with Windows ACLs in an NTFS qtree from
a UNIX host, Data ONTAP grants access based on the user’s mapped Windows
user. The user’s Windows user SID and Windows group SIDs are used to
determine NTFS access rights.
There is an exception: A user’s Windows credential is not used if a user requests
access to data in an NTFS security-style qtree or volume in the following
scenario. When a UNIX-security style volume or qtree is changed to
NTFS-security style, the files and folders contained within the qtree or volume do
not automatically have Windows ACLs placed on them. In this situation, if the file
or folder has existing UNIX-style permissions, the UID and GIDs are used for the
access check.
This exception also applies when a mixed security style volume or qtree with
UNIX effective security style is changed to NTFS-security style. For more
information about this exception, see 3.2, “Changing a UNIX or mixed volume
with UNIX effective security to an NTFS volume” on page 26.
By default, if there is not a corresponding Windows user, access is denied to the
NTFS qtree from a UNIX host, because the option that is used to configure a
generic Windows account is, by default, set to null.
The option wafl.default_nt_user is a storage system option that administrators
can use to allow mapping of Windows users with no corresponding UNIX
account to a generic Windows account. The default for this option is also null. To
enable access from a default user, add a valid Windows account to this option,
as shown in Example 1-6.
Example 1-6 Syntax for setting WAFL default NT user
itsotuc3> options wafl.default_nt_user [corp / ntuser]
1.6.3 Mixed qtrees
For mixed-style volumes and qtrees, access is based on the effective security
style on the volume and the qtree, folders, and files within the volume. A mixed
volume or qtree can have either UNIX or NTFS-style security in place. However,
only one security style is applied to any one file or folder. A file or folder has
either NTFS security style or UNIX security style in place, not both.
10
IBM System Storage N series Multiprotocol Use Guide
Particular folders or files within a mixed volume or qtree can have a security style
that differs from the root of the volume or qtree (but not both security styles apply
at the same time to any particular folder or file).
Example 1-7 shows the qtree and a folder that was created within it.
Example 1-7 Qtree example
itsotuc3:/vol/vol1/qtree_mixed
itsotuc3:/vol/vol1/qtree_mixed/ntfs_folder
In Example 7, the root of qtree_mixed has UNIX-style security (uses UID and
GIDs to determine access rights). However, the folder ntfs_folder was created by
a Windows administrator using a mapping on a Windows machine. The Windows
administrator specified that this folder should not inherit parent permissions.
Instead, the administrator gave the folder its own specific NTFS permissions.
The addition of specific NTFS permissions changed the security style of this
folder and all data subsequently placed within it to NTFS security style.
1.7 Multiprotocol access and group mapping
Data ONTAP user mapping maps user names. It does not map groups. Due to
the fundamentally different way that Windows groups and UNIX groups are
configured, it is not possible to perform a consistent, exact mapping of UNIX and
Windows groups. However, because group membership is critically important
when determining file access, as part of the mapping process, the mapped user’s
group membership is retrieved and cached along with the user mapping
information.
If a user is supposed to have access to a file or folder based on a group
membership, ensure that the user is a member of a group that correlates to the
file’s security style and ensure that this group has appropriate access rights to
the file.
For example, suppose that a CIFS user is a member of a Windows group called
itso and requests access to a UNIX security style file with a group owner of
unixitso, as shown in the following line:
-rw-r--r--
1 red1
unixitso
0 Mar
7
2007 file1
Also, the user is not the file owner and expects access to be granted based on
rights granted to the UNIX unixitso group. The mapped UNIX user must be a
member of the UNIX unixitso group. Access will not be granted based on the
Windows user’s membership in the Windows itso group.
Chapter 1. Multiprotocol on the IBM System Storage N series
11
1.8 Caching user mapping information: The WAFL
credential cache
After UNIX-to-Windows user mapping is performed, the results, including group
membership for both the UNIX user and the Windows user, are stored in the
storage system’s WAFL credential cache (wcc).
Windows-user-to-UNIX-user mapping is not stored in the wcc. Instead, with
Windows-to-UNIX-user mapping, the UNIX user information is kept as part of the
CIFS session credential. A fresh Windows-to-UNIX-user mapping is needed only
when a new CIFS session is established for that user.
By default the UNIX-to-Windows mapping information is cached for 20 minutes.
The cache time can be increased with the option in Example 1-8.
Example 1-8 Showing how to display and set WAFL cache
itsotuc3> options wafl.wcc_minutes_valid
wafl.wcc_minutes_valid
20
Syntax as follows:
itsotuc3> options wafl.wcc_minutes_valid value (1 to 21060)
Use the storage system command wcc to determine the effective user mapping
between UNIX and Windows user.
The wcc command simulates NFS-to-Windows user mapping; however, there is
no CIFS authentication step when using the wcc command. Administrators
cannot use this command to troubleshoot CIFS authentication issues, but it is
useful for troubleshooting user mapping issues (Example 1-9). The wcc
command does not look in the wcc cache. Each time the command is run, the
user map operation is performed, providing current user map information.
Example 1-9 Showing NT user mappings
itsotuc1> wcc -s red3
(NT - UNIX) account name(s):
***************
UNIX uid = 65534
(ITSO\red3 - pcuser)
NT membership
ITSO\red3
ITSO\Domain Users
ITSO\itso
BUILTIN\Users
User is also a member of Everyone, Network Users,
Authenticated Users
***************
12
IBM System Storage N series Multiprotocol Use Guide
1.9 Managing file and folder security
CIFS file and folder level ACLs can be managed with the Security tab of the file
or folder Properties tab. NTFS ACLs can also be managed from a UNIX client
with the smbcacls program.
UNIX file and directory level permissions can be managed by the UNIX chmod
command. Special permissions such as changing the file owner or group are
managed with the chown or chgrp command (Example 1-10).
Example 1-10 Example of changing file permissions on a UNIX system
[root@itso tmp]# ls -l (to display current permissions)
-rw-r--r-- 1 root root
0 Mar 5 09:49 test.file
[root@itso tmp]# chmod 666 test.file (this setting allows all users
read & write access)
[root@itso tmp]# ls -l (to display new file permissions)
-rw-rw-rw- 1 root root
0 Mar 5 09:49 test.file
Note: You can find further information about the syntax and usage of the
UNIX commands chmod, chown, or chgrp from the UNIX man pages. For
example, entering the # man chmod command displays the syntax and usage
help page for the chmod command.
Starting with Data ONTAP 7.2, UNIX permissions can also be managed from the
Windows Security tab, which is accessed through a CIFS share. (Figure 1-3).
Chapter 1. Multiprotocol on the IBM System Storage N series
13
Figure 1-3 File permissions of a file created in UNIX using CIFS shared NFS volume
Note: The new protocol feature options cifs.preserve_unix_security
available on Data ONTAP 7.2 or later has to be enabled. For more
information, see 2.2, “Display and effective permissions beginning with Data
ONTAP 7.2” on page 20.
14
IBM System Storage N series Multiprotocol Use Guide
2
Chapter 2.
Display and effective
permissions in a
multiprotocol environment
Requests from users are evaluated using the real file permissions that are in
effect on the file or folder. However, Data ONTAP must provide a method for
viewing display permissions from non-native clients.
There are two ways that Data ONTAP manages display permissions, depending
on the Data ONTAP version:
򐂰 All versions of Data ONTAP prior to 7.2 handle display permissions as
outlined in 2.1, “Display and effective permissions prior to Data ONTAP 7.2”
on page 16.
򐂰 Starting with Data ONTAP 7.2, if you enable a specific option, display
permissions are displayed differently than in previous versions. 2.2, “Display
and effective permissions beginning with Data ONTAP 7.2” on page 20
describes the new permission display method and information about enabling
this feature.
© Copyright IBM Corp. 2007. All rights reserved.
15
2.1 Display and effective permissions prior to Data
ONTAP 7.2
When a host views the displayed security information associated with a file or
directory that has non-native file permissions (that is, the Windows host displays
permissions on a UNIX file system or a UNIX host displays permissions on an
NTFS file system), a set of display permissions is created, but they are generally
not the same as the effective permissions. They are intended to represent as
closely as possible the semantics of the non-native security information. They
are for display purposes only and are not used for actual permission checking.
2.1.1 Display permissions versus effective permissions
In this section, we discuss both NFS and CIFS effective permissions.
NFS client requests permissions from an NTFS-style security
volume
An NFS client requesting permissions for a file with NTFS-style security gets a
UNIX permission set derived from the ACL. Because some NFS clients actually
use the display permissions to prescreen certain kinds of file access, the display
permissions returned show the maximum access allowed to any user in the ACL.
This often results in a displayed UNIX permission that appears to be granting
read, write, and execute access to all. However, this representation is for display
purposes only. Regardless of the display permissions, file access is still granted
based on the ACL.
In Example 2-1, it appears that all users have read, write, and execute
permissions.
Example 2-1 Example of user file permissions
drwxrwxrwx 8 root root 4096 Jul 5 08:38 /mnt
16
IBM System Storage N series Multiprotocol Use Guide
However, as shown in Figure 2-1, the effective permissions show that not all
users have write permissions.
Figure 2-1 Permissions from a Windows client of a volume with NTFS security style
CIFS client requests permissions from a UNIX-style security
volume
The display permissions in this case differ depending on whether the volume is
UNIX-style security or mixed-style security, with an effective security style of
UNIX.
Chapter 2. Display and effective permissions in a multiprotocol environment
17
If the security style of the volume is UNIX, display permissions are not displayed
at all (see Figure 2-2). The Security tab is not available when a UNIX security
style volume is mapped on a Windows machine. The mapped drive appears to
be formatted with FAT, which has no file permissions. In this case, any
representation of the permissions must be viewed from UNIX mounts. This
behavior changes with Data ONTAP 7.2. See 2.2, “Display and effective
permissions beginning with Data ONTAP 7.2” on page 20 for a description of the
changes in Data ONTAP 7.2 to display permissions.
Figure 2-2 Permissions from a Windows client of a volume with UNIX security style
If the security style of the volume is mixed with an effective security style of
UNIX, the Security tab is available when the volume is mapped on a Windows
machine (see Figure 2-3). A set of display permissions is available for viewing. A
CIFS client requesting the security descriptor for a file with UNIX-style security
gets a display ACL that is based on the rights granted to the owner of the file, the
rights granted to the requester, and the rights granted to Everyone. Again, this
ACL is for display only, and is not actually used for permission checking.
18
IBM System Storage N series Multiprotocol Use Guide
Figure 2-3 Display permissions with mixed security using UNIX effective security
Chapter 2. Display and effective permissions in a multiprotocol environment
19
2.2 Display and effective permissions beginning with
Data ONTAP 7.2
NFS client requests permissions from an NTFS-style security volume. There is
no change between the way previous versions of Data ONTAP and Data ONTAP
7.2 and later display NTFS security style permissions on a UNIX host.
CIFS client requests permissions from a UNIX-style security volume.
By default, there is no change in displaying UNIX permissions from a CIFS client.
However, by enabling the option shown in Example 2-2, the new multiprotocol
feature is implemented and there is a change between the way previous versions
of Data ONTAP and Data ONTAP 7.2 and later display UNIX-style permissions
on a Windows host.
Example 2-2 Checking and enabling the new protocol feature with Data ONTAP 7.2
To view current settings
itsotuc3*> options cifs.preserve_unix_security
cifs.preserve_unix_security off
To enable / disable this feature
itsotuc3*> options cifs.preserve_unix_security on/off
itsotuc3*>
When this option is enabled, if the security style of the volume is either UNIX or
mixed with an effective security style of UNIX, the Windows Security tab is
available in the file or folder Properties tab and now displays the effective UNIX
owner, group, and other access permissions on the file or folder. The special
UNIX permissions—suid, sgid, and svtx—are also displayed.
When the new security feature is available, in addition to viewing effective UNIX
permissions, UNIX permissions can also be changed from the Windows Property
Security tab. The new functionality is limited to changing permissions on the
existing owner and group and on the other, suid, sgid, and svtx entities.
Ownership and group cannot be changed from the Windows Security tab.
Because Windows file permissions do not directly correlate to the standard
Windows file permissions, UNIX permissions are viewed by clicking the
Advanced button in the Security Properties tab. Permissions can be viewed and
edited by selecting a UNIX entity and clicking Edit in the Advanced window.
20
IBM System Storage N series Multiprotocol Use Guide
In Example 2-3, red1 has read and write permissions on the file. The group
unixitso and other has read permissions. The special permissions suid, guid,
and svtx are set on the file. The following figures illustrate how these
permissions are displayed in the Windows Security tab.
Example 2-3 Permission for a UNIX security style file, test.doc
-rw-r--r--
1 red1
unixitso
0 Mar
7
2007 test.doc
To set UNIX permissions from the Windows Security tab, select the appropriate
permission, click OK, and then click Apply.
Figure 2-4 Data ONTAP 7.2 display permissions with the new multiprotocol feature enabled
Chapter 2. Display and effective permissions in a multiprotocol environment
21
Note: Traverse Folder/Execute File corresponds to the UNIX execute
permission. List Folder/Read Data corresponds to the UNIX read permission.
Create Files/Write Data corresponds to the UNIX write permission.
Figure 2-5 Data ONTAP 7.2 suid, sgid, and svtx display permissions
22
IBM System Storage N series Multiprotocol Use Guide
Note: List Folder/Read Data corresponds to the UNIX permissions suid,
sgid, and svtx. To set the permissions, choose this permission for each of the
special permission entries—suid, sgid, and svtx. Then, click OK and click
Apply.
Chapter 2. Display and effective permissions in a multiprotocol environment
23
24
IBM System Storage N series Multiprotocol Use Guide
3
Chapter 3.
Changing security styles
This chapter discusses the detailed steps to change security styles. It includes
the following sections:
򐂰 Changing an NTFS or mixed volume with NTFS effective security to a UNIX
volume
򐂰 Changing a UNIX or mixed volume with UNIX effective security to an NTFS
volume
򐂰 Root and administrative access
򐂰 The multiprotocol access process
© Copyright IBM Corp. 2007. All rights reserved.
25
3.1 Changing an NTFS or mixed volume with NTFS
effective security to a UNIX volume
If an NTFS or mixed qtree is changed to UNIX, the permissions that are used
revert to a minimally permissive set such that the allowed permissions are at
least as strict as the access control list (ACL). Because the full range of
possibilities in an ACL cannot be represented in the UNIX security model,
necessarily some accesses will be denied by the synthesized UNIX permissions
that would have been granted by the ACL. For example, assume that file ABC is
in an NTFS or mixed qtree and that the file has the following ACL entries:
redpaper(owner)
itso Change
its
Full Control (All)
(RWXD)
Read (RX)
If the qtree is changed to UNIX, both itso and its belong to the other category.
The synthesized UNIX permissions for other are set to the minimally permissive
setting, which is r-x. Therefore, itso loses the ability to write to or delete the file
ABC.
Even though UNIX permissions are used when accessing the files, the ACLs are
not removed when the qtree security style is changed to UNIX. As long as the
files do not have their security modified with chmod, chown, chgrp, and so forth,
the original ACLs continue be stored. If the volume security style is changed
back to NTFS, the original ACLs are restored.
3.2 Changing a UNIX or mixed volume with UNIX
effective security to an NTFS volume
If a volume or qtree with UNIX effective security style is changed to NTFS
security style, the root volume or qtree directory gets an ACL that allows
everyone full control, if it did not already have an ACL. However, it does not add
ACLs to directories and files within the volume. On the root volume, /etc/ does
not get an ACL.
Files created before the security style is changed do not have Windows NT®
permissions (unless the volume or qtree had previously been NTFS security
style and already has an ACL in place). For these files, the storage system uses
only the UNIX-style permission bits to determine access. ACLs must be placed
on existing files and folders within the volume or qtree, either on a file-by-file
basis or by setting ACLs on a parent folder and propagating them down to child
26
IBM System Storage N series Multiprotocol Use Guide
objects. New files or folders receive ACLs depending on the rules of inheritance
and propagation set up by the Windows administrator on that file system.
3.3 Root and administrative access
Root has special privileges on UNIX file systems, and Windows administrators
have special privileges on Windows file systems. Therefore, root and
administrative file and folder access requests require additional access checks.
3.3.1 Root privileged access
For UNIX-style file permissions, if the root user is on a client that is granted root
access in the exportfs file, root always has file access permissions. If a root user
on a client that is not granted root access in the exports file attempts to perform
an action on a file or folder, the user is mapped to the nobody user (see
Example 3-1).
Example 3-1 Root from a client without root export rights creates a file
[root@itso NFSvol_GRN]# touch test1
[root@itso NFSvol_GRN]# ls -l
-rw-r--r-- 1 nfsnobody nfsnobody 0 Jul 10 10:52 test1
For UNIX security style volumes, Windows administrators always have access to
files as though they were root if the appropriate mapping configuration exists.
There are two ways to map a Windows user to root:
򐂰 Turn on the option that allows all Windows administrators to map to root, as
shown in Example 3-2.
Example 3-2 How to enable and check wafl.nt_admin_priv_map settings
itsotuc3> options wafl.nt_admin_priv_map_to_root on
itsotuc3>
No confirmation will be given that this has been successful. Run the
following to display current settings
itsotuc3> options wafl.nt_admin_priv_map_to_root
wafl.nt_admin_priv_map_to_root on
itsotuc3>
Chapter 3. Changing security styles
27
򐂰 Configure the /etc/usermap.cfg file to allow specific users to map to root. This
is the recommended way to allow root access by Windows users.
Example 3-3 performs a one-way mapping of specific Windows users to root
Example 3-3 One way mapping of windows users
itso\red1 => root
Prior to Data ONTAP 7.2, permissions on UNIX security style volumes could not
be configured through the Windows Security tab. The permissions are configured
from a UNIX host with the chmod command.
Data ONTAP 7.2 and later allows UNIX permissions to be configured from the
Windows Security tab as long as that user maps to a UNIX user who has the
appropriate rights to change permissions on that object. Special UNIX
permissions (chown and chgrp commands) cannot be configured from the
Windows interface even with Data ONTAP 7.2 or later.
3.3.2 Windows administrator privileged access
Windows administrators do not always have access to NTFS-style files. The
NTFS permissions can be configured so that an administrator cannot access the
files. Windows administrators can always take ownership of files and grant
themselves access.
The cifs.nfs_root_ignore_acl option controls how Data ONTAP handles ACLs
placed on an NTFS-style file system when a root user has been granted root
privileges to the exported NTFS security style volume:
򐂰 The cifs.nfs_root_ignore_acl on option allows root to access files with
ACLs even if the ACLs would not allow access to the mapped Windows user.
򐂰 The cifs.nfs_root_ignore_acl off options requires that the Windows user
to whom root maps has appropriate access rights in the ACLs to perform the
requested action.
In addition to setting the cifs.nfs_root_ignore_acl option to on, the export
options must also be set to allow root access to the UNIX host from which the
root user is accessing data. Even if the cifs.nfs_root_ignore_acl option is set
to on, a root user cannot perform privileged commands such as changing
ownership on files or changing permissions on files with NTFS security style
volumes. Windows administrators must perform these actions.
Windows file security can also be managed with the Samba tool, smbcacls.
Because security style determines what type of file permissions are used to
control access, choose NTFS security style if the file system is administered by
28
IBM System Storage N series Multiprotocol Use Guide
Windows administrators and access is controlled using Windows users and
groups.
3.3.3 Mixed security style and Windows administrator and root
privileged access
Files and folders in mixed security style volumes can have either Windows-style
security or UNIX-style security (but not both at the same time), as shown in
Example 3-4. Both Windows administrators and UNIX administrators can
administer file security within the volume, with the effective security style of the
file or folder determined by which type of administrator last changed permissions
or owner on the file or folder.
Example 3-4 Mixed security
itsotuc3> qtree status alexnfs
Volume
Tree
Style Oplocks
-------- -------- ----- -------alexnfs
unix enabled
alexnfs alexnfs mixed enabled
Status
--------normal
normal
If mixed security style volumes are configured, it is important to have
documentation that outlines which areas of the volume are controlled by
NTFS-style security and which areas are controlled by UNIX-style security.
Administrators must be careful not to inadvertently change security style of files
or folders. Doing so can cause access issues for users, especially in the case
where a folder has been changed from UNIX-style security to NTFS-style
security. Windows, by default, propagates changes, and carefully crafted UNIX
permissions on subfolders can be changed inadvertently.
Prior to Data ONTAP 7.2, areas of a mixed volume that have UNIX-style security
files and folders must be administered from UNIX hosts. With Data ONTAP 7.2
and later, UNIX permissions can be changed from the Windows Security tab, but
changes to the owner and group ownership must still be performed from a UNIX
host.
Areas of a mixed volume that have NTFS-style files and folders should be
administered from the Windows Security tab.
Chapter 3. Changing security styles
29
A file's security model can be flipped from one style to another by NFS set
attribute or CIFS set ACL requests. The file can be flipped by the following users:
򐂰 A file's owner
򐂰 Root (for UNIX-security style files/folders)
򐂰 Any Windows user given NTFS change permission (for NTFS-security style
files/folders).
3.4 The multiprotocol access process
There are four main methods used to access data:
򐂰 A UNIX user on a UNIX or Linux host accesses data on a UNIX security style
volume. This type of file access does not require a user mapping operation.
򐂰 A UNIX user on a UNIX or Linux host accesses data on a Windows security
style volume. This type of file usually does require a user mapping operation.
There is an exception to this type of access. If a mixed or UNIX-style security
qtree is changed to an NTFS-style security qtree, the files and folders
contained within the qtree or volume do not have Windows ACLs placed on
them automatically. In this situation, if the data being accessed has existing
UNIX permissions, UNIX UIDs and GIDs are used for the access check. In
this case, the mapping does not need to be done. See 3.2, “Changing a UNIX
or mixed volume with UNIX effective security to an NTFS volume” on page 26
for details.
򐂰 A Windows user authenticating either with domain authentication or local
workgroup authentication accesses data on a UNIX security style volume.
This type of file access does require a user mapping operation.
򐂰 A Windows user authenticating either with domain authentication or local
workgroup authentication accesses data on an NTFS security style volume.
This type of file access does require a user mapping operation. Even though
this is a Windows user accessing NTFS-style security data, user mapping still
occurs. Current implementations of Data ONTAP always perform a user
mapping operation when data is accessed through CIFS.
The four main access methods are described in detail in the remaining chapters
of this book. These descriptions are valid for NFS v2 and NFS v3. Special
mapping operations that are used when the user is root or a Windows
administrator are not included in the mapping process described. See 3.3, “Root
and administrative access” on page 27 for information about how Data ONTAP
handles access requests from root or Windows administrators.
30
IBM System Storage N series Multiprotocol Use Guide
4
Chapter 4.
NFS access of data
This chapter describes details of data access by NFS in both the NFS and NTFS
environment. It discusses differences and commonalities in both environments
when it comes to the System Storage N series introduction into these
environments.
© Copyright IBM Corp. 2007. All rights reserved.
31
4.1 NFS access of UNIX security style data
Figure 4-1 portrays the process when a user on a UNIX host accesses data with
UNIX security style using NFS. You will see that the System Storage N series
behaves with little differentiation in the UNIX environment.
UNIX Identity Store
(NIS or LDAP)
Active Directory
IBM System Storage N series
1
2
UNIX
Volume
5
NTFS
Volume
4
6
UNIX Host
Windows Host
3
Figure 4-1 NFS access of UNIX security style data
4.1.1 Steps for NFS access of UNIX security style data
To provide NFS access to UNIX data, complete 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.
32
IBM System Storage N series Multiprotocol Use Guide
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 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 would 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 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. 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.
Note: 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. See 3.3, “Root and administrative access” on
page 27 for information about root access.
Chapter 4. NFS access of data
33
4.2 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 4-2 describes the
process when a user on a UNIX host accesses data with NTFS security style
using NFS.
UNIX Identity Store
(NIS or LDAP)
Active Directory
9
6
7
10
IBM System Storage N series
11
1
12
8
2
5
13
UNIX
Volume
NTFS
Volume
4
14
UNIX Host
Windows Host
3
Figure 4-2 NFS access of NTFS security style data
4.2.1 Steps for NFS access of NTFS security style data
To provide NFS access of NTFS data, complete 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.
34
IBM System Storage N series Multiprotocol Use Guide
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 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 would 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 filer 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.
Chapter 4. NFS access of data
35
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.
Note: 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.
Note: The complete credential retrieved in Step 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.
This section does not describe how the process handles access requests by
root. Root access is described in 3.3.1, “Root privileged access” on page 27.
36
IBM System Storage N series Multiprotocol Use Guide
5
Chapter 5.
CIFS access of UNIX
security style data
In a multi protocol environment enabled by the 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 chapter
discusses how to provide that access and structure on System Storage N series.
© Copyright IBM Corp. 2007. All rights reserved.
37
5.1 Steps for CIFS access of UNIX security style data
Figure 5-1 describes the process when a user on a Windows host accesses data
with UNIX-style security using CIFS.
UNIX Identity Store
(NIS or LDAP)
Active Directory
4
10
11
IBM System Storage N series
5
8
9
1
7
6
UNIX
Volume
14
3
2
NTFS
Volume
12
13
15
UNIX Host
Windows Host
Figure 5-1 CIFS access of UNIX security style data
The following steps outline the steps illustrated in Figure 5-1 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 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
38
IBM System Storage N series Multiprotocol Use Guide
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 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 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.
Chapter 5. CIFS access of UNIX security style data
39
– 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.
Note: 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.
40
IBM System Storage N series Multiprotocol Use Guide
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 5-1.
Example 5-1 Setting the option to allow guest connection
itsotuc3*> options cifs.guest_account unix_name
No confirmation will be given that this has been successful. Run the
following to display current settings
itsotuc3*> 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—/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 5-2. All guest access requests will be denied.
The default for this option is NULL. Guest access is denied by default.
Example 5-2 Setting CIFS guest account to null
itsotuc3*> options cifs.guest_account ""
No confirmation will be given that this has been successful. Run the
following to display current settings
itsotuc3*> 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.
Chapter 5. CIFS access of UNIX security style data
41
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.
Note: 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.
42
IBM System Storage N series Multiprotocol Use Guide
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.
Note: This section does not describe how the process handles access
requests by Windows administrators. See 3.3, “Root and administrative
access” on page 27 for more information about data access by administrators.
Chapter 5. CIFS access of UNIX security style data
43
44
IBM System Storage N series Multiprotocol Use Guide
6
Chapter 6.
CIFS access of NTFS
security style data
This chapter discusses native CIFS access to NTFS data. It provides high-level
steps for CIFS access.
© Copyright IBM Corp. 2007. All rights reserved.
45
6.1 Steps for CIFS access of NTFS security style data
Figure 6-1 describes the process when a user on a Windows host accesses data
with NTFS security style using CIFS.
UNIX Identity Store
(NIS or LDAP)
Active Directory
4
10
11
IBM System Storage N series
5
8
9
1
7
6
14
UNIX
Volume
NTFS
Volume
2
3
12
13
UNIX Host
15
Windows Host
Figure 6-1 CIFS access of NTFS security style data
The following steps outline the steps illustrated in Figure 6-1 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
46
IBM System Storage N series Multiprotocol Use Guide
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 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).
Note: The format for a UNC path is \\server name\shared volume\shared
directory\name of file and is not case-sensitive.
Typically the location of a file is described by the drive letter and folder it is
located in. This is likely to be unique to the host this location is mapped to.
Where as specifying a UNC path it more specific and is common across all
operating systems
When a user requests access to data on a 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
Chapter 6. CIFS access of NTFS security style data
47
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.
48
IBM System Storage N series Multiprotocol Use Guide
Note: 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 6-1.
Example 6-1 Setting the option to allow guest connection
itsotuc3*> options cifs.guest_account unix_name
No confirmation will be given that this has been successful. Run the
following to display current settings
itsotuc3*> 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—/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 6-2. All guest access requests will then be
denied. The default for this option is NULL. Guest access is denied by default.
Example 6-2 Setting CIFS guest account to null
itsotuc3*> options cifs.guest_account ""
No confirmation will be given that this has been successful. Run the
following to display current settings
itsotuc3*> 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.
Chapter 6. CIFS access of NTFS security style data
49
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.
Note: 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.
50
IBM System Storage N series Multiprotocol Use Guide
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.
Note: This section does not describe how the process handles access
requests by Windows administrators. See 3.3, “Root and administrative
access” on page 27 for information about data access by administrators.
Chapter 6. CIFS access of NTFS security style data
51
52
IBM System Storage N series Multiprotocol Use Guide
A
Appendix A.
CIFS access in workgroup
mode
A System Storage N series storage system supports four CIFS access methods.
The method is chosen during CIFS setup. We described the access methods for
joining an Active Directory domain, joining an NT domain, and joining a local
Windows workgroup in previous chapters.
Joining a workgroup using /etc/password, NIS, or LDAP for authentication offers
a substantially different method for managing file and folder access. Example A-1
illustrates this method.
Example: A-1 CIFS setup and access method designation
(1)
(2)
(3)
(4)
Active Directory domain authentication (Active Directory domains only)
Windows NT 4 domain authentication (Windows NT or Active Directory domains)
Windows Workgroup authentication using the filer's local user accounts
/etc/passwd and/or NIS/LDAP authentication
Selection (1-4)? [1]:
In this appendix, we describe CIFS access in workgroup mode.
© Copyright IBM Corp. 2007. All rights reserved.
53
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 is 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 is UNIX-style security, UNIX file permissions in
conjunction with share permissions are used to determine access.
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.
54
IBM System Storage N series Multiprotocol Use Guide
B
Appendix B.
Qtree security
This appendix gives an illustration of how to alter qtree security at the qtree level
or volume level.
© Copyright IBM Corp. 2007. All rights reserved.
55
Alter qtree security at the qtree level or volume level
To alter qtree security at the qtree level or volume level, follow these steps:
1. Open an internet browser and enter the IP address of the System Storage N
series that you want to manage (for example, http://IP_address/na_admin,
where IP_address is the IP address of your System Storage N series).
2. Select the FilerView icon, as shown in Figure B-1.
Figure B-1 System Storage N series main management screen
56
IBM System Storage N series Multiprotocol Use Guide
3. In the FilerView window, select Volumes. A list of management options
available displays under Volumes, as shown in Figure B-2.
Figure B-2 View of Volumes management options
Appendix B. Qtree security
57
4. Select Qtrees as shown in Figure B-3 to see a list of management options
available under Volumes.
Figure B-3 View of management options available under Qtrees
58
IBM System Storage N series Multiprotocol Use Guide
5. Select Manage as shown in Figure B-4 to display the Manage Qtrees view.
Figure B-4 View of Manage Qtrees
Appendix B. Qtree security
59
6. Select the Qtree Volume that you want to modify (Figure B-5).
Figure B-5 View showing which volume and qtree has been selected for modification
60
IBM System Storage N series Multiprotocol Use Guide
7. In the Modify Qtree view, select the desired Security Style from the
drop-down menu options and click Apply, as shown in Figure B-6.
Figure B-6 View of Security Style options under Modify Qtree view
Appendix B. Qtree security
61
After you click Apply, you are presented with the final screen that displays a
message telling you that your applied changes were successful (Figure B-7).
Figure B-7 View of screen after modification to Security Style was applied successfully
62
IBM System Storage N series Multiprotocol Use Guide
Related publications
We consider the publications that we list in this section particularly suitable for a
more detailed discussion of the topics that we cover in this book.
IBM Redbooks publications
For information about ordering these publications, see “How to get IBM
Redbooks publications” on page 64. Note that some of the documents
referenced here might be available in softcopy only.
򐂰 IBM N Series Storage Systems in a Microsoft Windows Environment,
REDP-4083
򐂰 Multiprotocol Data Access with IBM System Storage N series, REDP-4176
򐂰 IBM System Storage N series File System Design for an NFS File Server,
REDP-4086
򐂰 Setting up CIFS and Joining the Active Directory, REDP-4074
Other publications
These publications are also relevant as further information sources:
򐂰 IBM System Storage N series Data ONTAP 7.2 Storage Management Guide,
GC26-7966
򐂰 IBM System Storage N series Data ONTAP 7.2 File Access and Protocols
Management Guide, GC26-7965
򐂰 IBM System Storage N series Network Management Guide, GA32-0525
© Copyright IBM Corp. 2007. All rights reserved.
63
Online resources
These Web sites are also relevant as further information sources:
򐂰 Support for Data ONTAP
http://www-304.ibm.com/jct01004c/systems/support/supportsite.wss/sup
portresources?taskind=3&brandind=5000029&familyind=5329797
򐂰 Support for IBM System Storage and TotalStorage products
http://www-304.ibm.com/jct01004c/systems/support/supportsite.wss/all
products?brandind=5000029
򐂰 Network attached storage (NAS)
http://www-03.ibm.com/systems/storage/nas/index.html
How to get IBM Redbooks publications
You can search for, view, or download Redbooks, Redpapers, Technotes, draft
publications and additional materials, as well as order hardcopy Redbooks, at
this Web site:
ibm.com/redbooks
Help from IBM
IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services
64
IBM System Storage N series Multiprotocol Use Guide
Index
A
ACLs 5, 10, 26, 54
Active Directory 36, 38, 46
Active Directory domain 47
K
Kerberos Authentication 39–40, 47–48
L
LDAP 9, 35, 41
C
cache 48
cached 35
chmod 13
CIFS 2, 4–5, 11, 13, 30, 42, 45–46, 48, 51, 53–54
CIFS client 20
cifs.guest_account 41
cifs.nfs_root_ignore_acl 28
Common Internet File Sytem. See CIFS
connection request 42
D
Data ONTAP 9, 11, 13, 15, 28–29, 41
domain controller 40, 46
DOS 54
E
Export 5
Export options 5, 35
F
file level access 54
file permission 5
file permissions 41
M
mapping entry 50
mapping process 42
mixed security 29
multiprotocol access 6
multiprotocol feature 20
N
Network File System. See NFS
NFS 2, 4, 16, 31
NFS client 16
NFS v3 30
NIS 34
NT 4 domain 39
NT LAN Manage (NTLM) Authentication 39, 48
NTFS 6, 9–10, 26, 30
NTFS permissions 11, 51
NTFS-security 10
NTFS-style 29
NTFS-style file permissions 49
NTFS-style files 28
NTFS-style security 10, 20
NTLM 47–48
NTLM authentication 39
NULL 41, 49
G
GIDs 35
GIDs. 33
group 11
guest credentials 39
I
IBM System Storage N series 1, 3, 5, 34
IBM System Storage N series file system 33, 35,
39, 47
© Copyright IBM Corp. 2007. All rights reserved.
O
options cifs.nfs_root_ignore_acl 28
options cifs.nfs_root_ignore_acl off 28
P
permissions 5, 16, 33, 36, 43, 51, 54
protocol 37
65
Q
qtree 7, 10–11, 26
user mapping 35
user mapping process 42
R
W
Redbooks Web site 64
Contact us ix
restrictive permissions 5
root 27
root access 28
WAFL 12, 50
wafl.default_nt_user 10, 36
wafl.default_unix_user 42
wcc 12
Windows 8, 10, 30, 38
Windows account 54
Windows administrators 27–28
Windows client 54
Windows file security 28
Windows NT 26
Windows NT LAN Manage (NTLM) Authentication
39–40
Windows user 36
S
security style 28
session cache 43
share permissions 51
SID 40, 48
SIDs 36, 40, 51
SIDs. 46
special permissions 21
storage system 33, 39, 41–42, 49–50
U
UID 33, 35
UNC 47
UNIX 2, 4, 7–9, 11–12, 26, 30, 42, 49–50
UNIX client 35
UNIX credential 50
UNIX credentials 42
UNIX file system 16
UNIX host 32–35
UNIX identity store 35, 54
UNIX name 42
UNIX name service 35, 50
UNIX name services 50
UNIX permission 41
UNIX permissions 20–21
UNIX security style 33, 38, 54
UNIX security style using NFS 32
UNIX security style volume 18, 43
UNIX security style volumes 27
UNIX UID 9, 54
UNIX user 9, 42, 50, 54
UNIX user name 35–36
UNIX users 3
unix_name 41
UNIX-style 11
UNIX-style file permissions 27
UNIX-style security 17–18, 29
66
IBM System Storage N series Multiprotocol Use Guide
(0.1”spine)
0.1”<->0.169”
53<->89 pages
Back cover
®
IBM System Storage N series
Multiprotocol Use Guide
Discusses
multiprotocol access
and group mapping
Provides caching
user mapping
information
Includes managing
file and folder
security details
Many customer sites need to access data from both
Windows and UNIX clients. For these environments, Data
ONTAP has native multiprotocol support. After the user is
authenticated on the network, if the user has both
appropriate share or export permissions and the necessary
file permissions, the user can access all data from UNIX
hosts using NFS or from Windows hosts using CIFS.
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
IBM System Storage N series allows users to access data
from both types of clients by supporting multiple security
models.
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
This IBM Redbooks publication discusses those models in
detail. It can help storage administrators in determining what
type of data access configuration is appropriate for their
environment.
IBM Redbooks are developed by
the IBM International Technical
Support Organization. Experts
from IBM, Customers and
Partners from around the world
create timely technical
information based on realistic
scenarios. Specific
recommendations are provided
to help you implement IT
solutions more effectively in
your environment.
For more information:
ibm.com/redbooks
SG24-7469-00
ISBN 0738488801