Chapter 1 Oracle ZFS Storage Appliance Overview
Chapter 3 Initial Configuration
Chapter 4 Network Configuration
Chapter 5 Storage Configuration
Chapter 6 Storage Area Network Configuration
Chapter 8 Setting ZFSSA Preferences
Chapter 10 Cluster Configuration
Configuring Services Using the BUI
Viewing a Specific Service Screen
Viewing a Specific Service Screen
Configuring Services Using the CLI
iSCSI Service Targets and Initiators
SMB Microsoft Stand-alone DFS Namespace Management Tools Support Matrix
Example: Manipulating DFS Namespaces
Adding a User to an SMB Local Group
SMB Users, Groups, and Connections
Active Directory Configuration
Project and Share Configuration
SMB Data Service Configuration
Allowing FTP Access to a share
HTTP Authentication and Access Control
Allowing HTTP access to a share
NDMP Local vs. Remote Configurations
Allowing SFTP access to a share
Configuring SFTP Services for Remote Access
Allowing TFTP access to a share
Configuring virus scanning for a share
Adding an appliance administrator from NIS
Adding an appliance administrator
Active Directory Join Workgroup
Active Directory Domains and Workgroups
Active Directory Windows Server 2012 Support
Active Directory Windows Server 2008 Support
Active Directory Windows Server 2008 Support Section A: Kerberos issue (KB951191)
Active Directory Windows Server 2008 Support Section B: NTLMv2 issue (KB957441)
Active Directory Windows Server 2008 Support Section C: Note on NTLMv2
Configuring Active Directory Using the BUI
Configuring Active Directory Using the CLI
Example - Configuring Active Directory Using the CLI
Identity Mapping Rule-based Mapping
Identity Mapping Directory-based Mapping
Mapping Rule Directional Symbols
Identity Mapping Best Practices
RIP and RIPng Dynamic Routing Protocols
Registering the Appliance Using the BUI
Registering the Appliance Using the CLI
Configuring SNMP to Serve Appliance Status
Configuring SNMP to Send Traps
Receiver Configuration Examples
Configuring a Solaris Receiver
Chapter 12 Shares, Projects, and Schema
The SMB service uses the identity mapping service to associate Windows and Unix identities. When the SMB service authenticates a user, it uses the identity mapping service to map the user's Windows identity to the appropriate Unix identity. If no Unix identity exists for a Windows user, the service generates a temporary identity using an ephemeral UID and GID. These mappings allow a share to be exported and accessed concurrently by SMB and NFS clients. By associating Windows and Unix identities, an NFS and SMB client can share the same identity, thereby allowing access to the same set of files.
In the Windows operating system, an access token contains the security information for a login session and identifies the user, the user's groups, and the user's privileges. Administrators define Windows users and groups in a Workgroup, or in a SAM database, which is managed on an Active Directory domain controller. Each user and group has a SID. An SID uniquely identifies a user or group both within a host and a local domain, and across all possible Windows domains.
Unix creates user credentials based on user authentication and file permissions. Administrators define Unix users and groups in local password and group files or in a name or directory service, such as NIS and LDAP. Each Unix user and group has a UID and a GID. Typically, the UID or GID uniquely identifies a user or group within a single Unix domain. However, these values are not unique across domains.
Windows names are case-insensitive and Unix names are case-sensitive. The user names JSMITH, JSmith, and jsmith are equivalent names in Windows, but they are three distinct names in Unix. Case sensitivity affects name mappings differently depending on the direction of the mapping.
For a Windows-to-Unix mapping to produce a match, the case of the Windows username must match the case of the Unix user name. For example, only Windows user name "jsmith" matches Unix user name "jsmith". Windows user name "Jsmith" does not match.
An exception to the case matching requirement for Windows-to-Unix mappings occurs when the mapping uses the wildcard character, "*" to map multiple user names. If the identity mapping service encounters a mapping that maps Windows user *@some.domain to Unix user "*", it first searches for a Unix name that matches the Windows name as-is. If it does not find a match, the service converts the entire Windows name to lower case and searches again for a matching Unix name. For example, the windows user name "JSmith@some.domain" maps to Unix user name "jsmith". If, after lowering the case of the Windows user name, the service finds no match, the user does not obtain a mapping. You can create a rule to match strings that differ only in case. For example, you can create a user-specific mapping to map the Windows user "JSmith@sun.com" to Unix user "jSmith". Otherwise, the service assigns an ephemeral ID to the Windows user.
For a Unix-to-Windows mapping to produce a match, the case does not have to match. For example, Unix user name "jsmith" matches any Windows user name with the letters "JSMITH" regardless of case.
When the identity mapping service provides a name mapping, it stores the mapping for 10 minutes, at which point the mapping expires. Within its 10-minute life, a mapping is persistent across restarts of the identity mapping service. If the SMB server requests a mapping for the user after the mapping has expired, the service re-evaluates the mappings.
Changes to the mappings or to the name service directories do not affect existing connections within the 10-minute life of a mapping. The service evaluates mappings only when the client tries to connect to a share and there is no unexpired mapping.
A domain-wide mapping rule matches some or all of the names in a Windows domain to Unix names. The user names on both sides must match exactly (except for case sensitivity conflicts, which are subject to the rules discussed earlier). For example, you can create a bidirectional rule to match all Windows users in "myDomain.com" to Unix users with the same name, and vice-versa. For another example you can create a rule that maps all Windows users in "myDomain.com" in group "Engineering" to Unix users of the same name. You cannot create domain-wide mappings that conflict with other mappings.
If no name-based mapping rule applies for a particular user, that user will be given temporary credentials through an ephemeral mapping unless they are blocked by a deny mapping. When a Windows user with an ephemeral Unix name creates a file on the system, Windows clients accessing the file using SMB see that the file is owned by that Windows identity. However, NFS clients see that the file is owned by "nobody".