Professional Documents
Culture Documents
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.
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.
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.
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.
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
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
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.)
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.
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
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.
@@