You are on page 1of 15

MODULE 10: NAS MULTIPROTOCOL

MULTIPROTOCOL
Qtrees can have one of three security styles:
NTFS:
For CIFS clients, security is handled using Windows NTFS ACLs.
For NFS clients, the NFS user ID (UID) is mapped to a Windows security identifier (SID) and
its associated groups. These mapped credentials are used to determine file access based on the
NTFS ACL.

UNIX: UNIX files and directories, like UNIX systems, have UNIX
permissions.
Mixed:

Both NTFS and UNIX security are allowed. A file or directory can have either Windows NT
permissions or UNIX permissions.
The default file security style is the style that was most recently used to set permissions on a
file.
SECURITY STYLE INTERACTION
User mapping between UNIX users and NTFS users always occurs, whether the chosen security
style is NTFS or multiprotocol. Even when a Windows client user is accessing data through an
NTFS qtree on a storage system with NTFS security style, a user mapping occurs for the
Windows client user.

WINDOWS-TO-UNIX USER RESOLUTION


When a CIFS user attempts to access a volume or qtree that has UNIX permissions, the user is
authenticated with the method by which the CIFS server has previously been configured. If the storage
system has been configured for domain authentication, the storage system passes the credentials to the
domain controller for proper authentication. The credentials are either authenticated or not. If the storage
system has been configured for workgroup authentication, then the user is authenticated by /etc/registry.
WINDOWS-TO-UNIX: AUTHENTICATED USERS
A Windows authenticated user is looked up in the /etc/usermap.cfg file. If the user is:
Mapped to a UNIX user, the mapped UNIX user is passed to verification
Not mapped at all, then the authenticated CIFS users name, with all lowercase letters, is tried for
UNIX verification
Mapped to an empty string ( ), then the user is invalid.
Verification
The storage system attempts to verify a UNIX user by employing the mechanism that is specified in the
/etc/nsswitch.conf file. The mechanism could be using /etc/passwd, using Network
Information Service (NIS), using Lightweight Directory Access Protocol (LDAP), or using NIS and
LDAP. If verification is unsuccessful, then the option wafl.default_unix_user is tried as a
generic user account. A typical default UNIX user is pcuser (UID=65534 and GID=65534), which is
stored in the /etc/passwd file by default. If verification is successful, the CIFS user is properly
associated with a UNIX account. If verification is unsuccessful, the CIFS user is invalid.
Windows Administrator
The Windows administrator user is a special case. The administrator is mapped to the UNIX user name
root (UID=0 and GID=0) if the wafl.nt_admin_priv_map_to_root option is set to on.

WINDOWS-TO-UNIX: GUEST USERS


Unauthenticated or invalid users may still be allowed access to a resource if the option
cifs.guest_account is configured. The guest account is then passed to the storage system for
UNIX verification as specified by the /etc/nsswitch.conf file.
UNIX USER ACCESS TO FILES
This section explains the default mechanism (/etc/usermap.cfg) for mapping UNIX user names to
Windows accounts. This mapping can also be accomplished by using LDAP, Active Directory, or NIS
servers, as described in http://www.netapp.com/library/tr/3458.pdf.
UNIX-TO-WINDOWS USER RESOLUTION
For this example, assume that the version of NFS is NFSv2 or NFSv3. When an NFS user attempts to
access a volume or qtree that has NTFS ACLs, the users UID is passed from the client to the storage
system. The storage system attempts to resolve the users name by the normal UNIX methods, as defined
in /etc/nsswitch.conf.
UNIX-TO-WINDOWS USER RESOLUTION
A valid user is looked up in the /etc/usermap.cfg file. If the user is:
Mapped to a Windows user, the mapped Windows user is passed to verification
Not mapped at all, then the UNIX users name is tried for CIFS verification
Mapped to an empty string ( ), then the user is invalid.

Verification
The storage system attempts to verify a Windows user by using the mechanism configured by the CIFS
server. The mechanism either uses the local accounts that are defined in the /etc/registry file or
passes verification to a domain controller. If verification is unsuccessful, then the option
wafl.default_nt_user is tried as a generic user account. There is no default setting for this value,
so it must be configured. If verification is successful, the NFS user is properly associated with a Windows
account. If verification is unsuccessful, the NFS user is invalid.

UNIX-TO-WINDOWS USER RESOLUTION


Unlike in Windows-to-UNIX resolution, there is no guest user account for NFS users. If the user is
invalid, the user is rejected.

SECURITY STYLES
A CIFS user can access a file without disrupting UNIX permissions by using one of these techniques:
For versions of the Data ONTAP operating system earlier than version 7.2, the CIFS user must have
the SecureShare multiprotocol file-locking system, an add-on from the NetApp Support site.
For the Data ONTAP 7.2 operating system and later, the CIFS user can manage security directly with
cifs.preserve_unix_security.

PRESERVING UNIX PERMISSIONS


Enabling the cifs.preserve_unix_security option preserves UNIX permissions, because files
are edited and saved by Windows applications that perform the following steps:
1. Read the security properties of the file.
2. Create a new temporary file.
3. Apply the security properties to the temporary file.
4. Give the temporary file the original file name.
Windows clients that perform a security query receive a constructed ACL that exactly represents the
UNIX permissions.

PRESERVING UNIX PERMISSIONS (CONT.)


Enabling the cifs.preserve_unix_security option also allows you to manipulate the UNIX
permissions using the Security tab on a Windows client or using any application that can query and set
Windows ACLs.
When enabled, the Windows Security tab will appear for UNIX-style volumes and qtrees. By default, this
option is disabled.
NOTE: You cannot change the owner and group from the Windows Security tab.

FILE PERMISSIONS WITH A MAPPED UNIX USER


In this example, a Windows user is accessing a UNIX file. The Security tab in the file Properties window
displays the users mapped UNIX credentials.
When a users request is evaluated, the users UNIX credentials are compared against the file or folders
UNIX access permissions.

WAFL CREDENTIAL CACHE

WAFL CREDENTIAL CACHE


The WAFL Credential Cache contains cached user mappings of UNIX user identities (UIDs and GIDs) to
Windows identities (SIDs for users and groups). After a UNIX-to-Windows user mapping is performed
(including group membership), the results are stored in the WAFL Credential Cache.
A Windows-to-UNIX user mapping is not stored in the WCC, but instead is kept as part of the CIFS
session credentials. A fresh Windows-to-UNIX user mapping is required only when a new CIFS session is
established for a user.
The wcc command does not look in the WAFL Credential Cache, but performs a current user mapping
operation and displays the results. This command is useful for troubleshooting user mapping issues.
To display current user mappings for a Windows account, run the wcc s nt_name command, where
nt_name is a Windows user name or SID.

File sharing between NFS and SMB


NFS and CIFS file naming dependencies
File naming conventions depend on both the network clients operating systems and the file-sharing
protocols.
The operating system and the file-sharing protocols determine the following:
Characters a file name can use
Case-sensitivity of a file name

Characters a file name can use


If you are sharing a file between clients on different operating systems, you should use characters
that are valid in both operating systems.
For example, if you use UNIX to create a file, do not use a colon (:) in the file name because the
colon is not allowed in MS-DOS file names. Because restrictions on valid characters vary from one
operating system to another,

Case-sensitivity of a file name


File names are case-sensitive for NFS clients and case-insensitive but case-preserving for CIFS
clients.

For example, if a CIFS client creates Spec.txt, both CIFS and NFS clients display the file name as
Spec.txt. However, if a CIFS user later tries to create spec.txt, the name is not allowed because,
to the CIFS client, that name currently exists. If an NFS user later creates a file named spec.txt,
NFS and CIFS clients display the file name differently, as follows:
On NFS clients, you see both file names as they were created, Spec.txtand spec.txt, because
file names are case-sensitive.
On CIFS clients, you see Spec.txtand Spec~1.txt.
Data ONTAP creates the Spec~1.txtfile name to differentiate the two files.

Creating lowercase file names


You can set the cifs.save_caseoption to offto force Data ONTAP to ignore the case in which
file names are entered and instead force these names to lowercase text.
About this task

Setting this option to offprovides better compatibility between 16-bit applications and some UNIX
tools. However, by default, this option is set to on.
Step

1. Enter the following command:


optionscifs.save_caseoff

How Data ONTAP creates file names


Data ONTAP creates and maintains two file names for files in any directory that has access from a
CIFS client: the original long name and a file name in 8.3 format.
For file names that exceed the eight character name or the three character extension limit, Data
ONTAP generates an 8.3-format file name as follows:
It truncates the original file name to six characters, if the file name exceeds six characters.
It appends a tilde (~) and a number, one through five, to file names that are no longer unique after
being truncated.
If it runs out of numbers because there are more than five similar names, it creates a unique file
name that bears no relation to the original file name.
It truncates the file name extension to three characters.
For example, if an NFS client creates a file named specifications.html, the 8.3 format file
name created by Data ONTAP is specif~1.htm. If this name already exists, Data ONTAP uses a
different number at the end of the file name. For example, if an NFS client then creates another file
named specifications_new.html, the 8.3 format of specifications_new.htmlis
specif~2.htm.

Controlling the display of dot files from CIFS clients


Dot files typically do not appear on UNIX-based systems; if you want to provide Windows client

systems the option of hiding dot files, set the cifs.show_dotfilesoption to off.
About this task

By default, these files are displayed on CIFS client systems, regardless of the Windows Folder
Options View setting for showing or hiding hidden files.
Step

1. Enter the following command to set the cifs.show_dotfilesoption to off:


optionscifs.show_dotfilesoff

Dot files on this system can be excluded from display when Windows client users select "Do not
show hidden files and folders" from the View tab on the Folder Options box. (To display the
Folder Options box, in Windows Explorer, select Tools > Folder Options.)

Enabling file name character translation between UNIX and


Windows
If you have legacy file names on both operating systems (Windows and UNIX) that contain
characters that are not valid in both operating systems, you can use the charmapcommand to allow
CIFS clients to access files with NFS names that would otherwise not be valid for CIFS .

Managing UNIX credentials for CIFS clients


When connecting to your storage system, a user on a CIFS client receives a CIFS credential. The user
must also have one or more UNIX credentials to access resources controlled by Data ONTAP.

How CIFS users obtain UNIX credentials


A UNIX credential consists of a UNIX-style user ID (UID) and group IDs (GIDs).
Data ONTAP uses the UNIX credential for the following purposes:
When a user tries to access files that have UNIX-style security, Data ONTAP uses the UID and
the user's GIDs to determine the access rights of the user.
When you want to use group quotas on a group that contains CIFS users, those CIFS users must
have UNIX credentials.
When a CIFS user tries to connect to the storage system, Data ONTAP tries to determine the UID,
the primary GID, and all secondary group GIDs of the CIFS user. If Data ONTAP cannot determine
the UID of the CIFS user and a default UNIX user is not defined, the user is denied access.
When retrieving UNIX user and group information, Data ONTAP uses the /etc/nsswitch.conf
file to determine which name services to use, and in what order to use them. Data ONTAP supports
files (passwd), NIS, and LDAP name services for UNIX user and group databases. Data ONTAP
obtains UNIX credentials by looking up the UNIX password and group databases, which can be
the /etc/passwdand /etc/groupfiles, NIS maps, or an LDAP directory store to obtain the user
and group information for a user. The configured databases contain account information for all users
that might access the storage system.
After Data ONTAP determines that the UNIX user name is a valid user name, the UID and GIDs
(both primary and secondary) are retrieved from the directory store and are included in the CIFS
credential.

For Data ONTAP to obtain the UID and GIDs for a CIFS user, it must first determine the users
UNIX-style name. It does this through user mapping. Data ONTAP does not require that a users
Windows name be identical to the UNIX name. By entering information in the /etc/usermap.cfg
file, you can specify how each Windows name maps to a UNIX name. If you accept the default
mapping, you do not need to enter this information. By default, Data ONTAP uses the Windows
name as the UNIX name when it looks up the UID. (The storage system converts uppercase
characters in the Windows name to lowercase before the lookup.)
If the user names in the UNIX password database are identical to the Windows names, you need not
provide the mapping information in the /etc/usermap.cfgfile. If the user name is not found in
the UNIX password database and the wafl.default_unix_useroption has been specified, the
default login name specified for that option is used.
Data ONTAP obtains a users GIDs in the following ways:
Data ONTAP obtains the users primary GID from the UNIX password database.
Each account in the UNIX password database contains the primary GID for that user.
Data ONTAP obtains the users other GIDs from the group database, which can be the NIS group
map, the LDAP data store, or the /etc/groupfile.
The group database is where you define membership for various groups.
You can see the UNIX credential of a connected CIFS user when you display CIFS session
information.

Ensuring that only intended CIFS users receive UNIX credentials


You can configure which CIFS users receive UNIX credentials by editing the /etc/usermap.cfg
file, creating UNIX groups and users, and enabling the Windows guest user account.
Steps

1. If some Windows names are different from UNIX names or you want to prevent some CIFS users
from accessing the storage system, edit the /etc/usermap.cfgfile.
2. Create groups in the UNIX group database.
3. For each CIFS user with a mapped UNIX name, enter the user account in the UNIX password
database.
4. If you rename the Administrator account, make sure at least one CIFS user maps to the UNIX
root account.
5. If you want CIFS users who do not have an entry in the UNIX password database to access the
storage system, create a default user account in the UNIX password database and set the
wafl.default_unix_useroption to that user.
6. If you want unauthenticated users to access the storage system, enable the Windows guest user
account.
Specifying entries in the /etc/usermap.cfg file
Data ONTAP uses the /etc/usermap.cfgfile to map user names. In its simplest form, each /etc/

usermap.cfgentry contains a pair of names: the Windows name and the UNIX name. Data

ONTAP can translate the Windows name to the UNIX name or vice versa.
About this task

When CIFS is started, if the /etc/usermap.cfgfile is missing, a default file is created. It contains
commented-out sample map entries that are useful for improving security.
When Data ONTAP receives a connection request from a CIFS user, it searches the /etc/
usermap.cfgfile to see whether an entry matches the users Windows domain name and user
name.
If an entry is found, Data ONTAP uses the UNIX name specified in the entry to look up the UID and
GID from the UNIX password database. If the UNIX name is a null string, Data ONTAP denies
access to the CIFS user.
If an entry is not found, Data ONTAP converts the Windows name to lowercase and considers the
UNIX name to be the same as the Windows name. Data ONTAP uses this UNIX name to look up the
UID and GID from the UNIX password database.
Data ONTAP scans the file sequentially. It uses the first matching entry for mapping.
@@

MULTIPROTOCOL
The NetApp storage controller can present files via the CIFS protocol and the NFS protocol
simultaneously. Because the controller includes sophisticated mappings between Windows and
UNIX user names and file system permissions, the operation is seamless.
CONFIGURATION

The only requirement for multiprotocol access is that CIFS access and NFS access be configured
to the same file system. Of course, some unavoidable complexities arise, because Windows
systems and UNIX systems use different security semantics.
Some security settings and user-name mappings do need to be configured. The mappings that do
not need to be configured are discussed in the Security section.
ADMINISTRATION

The CIFS and NFS protocols are managed separately, even when they refer to the same file
system. Therefore, the protocols should not be the source of any multiprotocol concern. For
detailed information about the administration of the CIFS and NFS protocols, refer to the CIFS
and NFS administration sections.
PERFORMANCE

Multiprotocol access should not be the source of any performance concern. For detailed
performance information, refer to the CIFS and NFS performance sections.
SECURITY

The default security style for all new volumes is controlled by a WAFL option:
options wafl.default_security_style <value>
Where <value> = unix

All files and directories have UNIX permissions.


Where <value> = ntfs
All files and directories have New Technology File System (NTFS) permissions.
Where <value> = mixed
Each file and directory can have either UNIX or NTFS permissions (but not both at the same
time).
NOTE: Because the use of mixed mode can complicate the troubleshooting of file-access
problems, it is recommended that mixed mode be used only when it is needed to accommodate a
particular requirement.
To manually set or view the security style for a volume or qtree, you use the following
commands:
qtree status, displays the list of volumes and qtrees and their security styles
qtree security <path> [ unix | ntfs | mixed ], sets the security mode for a nominated volume
or qtree
Although the security-style setting controls the underlying file systems security type, access via
CIFS or NFS to the file data is controlled by the normal user-authorization process. The
multiprotocol environment introduces additional complexity because the relationships between
the security semantics of the users, the shares and exports, and the file system must be mapped.
Consider the following example:
Evaluate the users SID or user ID against the share or export permissions.
Access to the share or export is either granted or denied.
Evaluate the users SID or user ID against the file or directory permissions.
If the ID and the permissions are of different types (for example, Windows and UNIX), then it
may be necessary to map the user name to the correct type.
The user-name mapping is defined in the /etc/usermap.cfg file. The /etc/usermap.cfg file is a
simple text file in the root volume of the storage controller. The process of mapping user names
between Windows and UNIX contexts is reasonably straightforward:
Automatic, if the Windows and UNIX user names match
Specified (win_user = unix_user), if the user names are defined in /etc/username.cfg file
Default, if the user names differ and there is no specific mapping. In this case, attempt to
use the defined default UNIX or Windows user name (if any).
options wafl.default_nt_user <username>
options wafl.default_unix_user <username>
TROUBLESHOOTING

Most problems with multiprotocol access are caused by incorrect security styles or incorrect
user-name mappings.
To identify how user-name mappings are being resolved, issue one of the following commands:
wcc u <unix_user>
This command displays the UNIX to Windows user-name mapping.
wcc s <windows_user>
This command displays the Windows to UNIX user-name mapping, for example:
Domain\Administrator => root
If you are connecting as the Administrator or root user to a volume with a foreign security style,
the easiest way to overcome an access problem may be to set the following options:
options wafl.nt_admin_priv_map_to_root on
options cifs.nfs_root_ignore_acl on
The wafl and cifs options grant superuser privileges on the foreign volume to Administrator
and root users, respectively.
In some cases, due to variances in user populations and variances in CIFS and NFS file locking
abilities, you may need to debug a file-access problem (for example, an NFS client cant open a
file because it is locked by a CIFS client). You can use the cifs sessions command to list
the clients that have active CIFS connections.
Another possible issue with mixed NFS and CIFS access is that NFS clients support symbolic
links in the file system and CIFS clients generally do not support symbolic links. However, if
you set the cifs.symlinks.enable option to on (the default value), then a CIFS client
can successfully resolve any symbolic-link problem that was created by an NFS client.
NOTE: For detailed information about the interaction of CIFS clients with the various types of
symbolic links, refer to the product documentation.
To resolve (better yet, to avoid) the simplest of all access problems, create both a CIFS share and
an NFS export.
@@

You might also like