Mapping User and Group Identities

The SMB server is designed to reside in a multiprotocol environment and provide an integrated model for sharing data between Windows and Oracle Solaris systems. Although files can be accessed simultaneously from both Windows and Oracle Solaris systems, no industry-standard mechanism is available to define a user in both Windows and Oracle Solaris environments. Objects can be created in either environment, but traditionally the access control semantics for each environment are vastly different. The Oracle Solaris OS has adopted the Windows model of access control lists (ACLs) by using ACLs in NFSv4 and the ZFS file system, and by providing the idmap identity mapping service.

The SMB server uses identity mapping to establish an equivalence relationship between an Oracle Solaris user or group and a Windows user or group in which both the Oracle Solaris and Windows identities are deemed to have equivalent rights on the system.

The SMB server determines the Windows user's Oracle Solaris credentials by using the idmap service to map the SIDs in the user's Windows access token to UIDs and GIDs, as appropriate. The service checks the mappings and if a match for the Windows domain name and Windows entity name is found, the Oracle Solaris UID or GID is taken from the matching entry. If no match is found, an ephemeral UID or GID is dynamically allocated. An ephemeral ID is a dynamic UID or GID mapping for an SID that is not already mapped by name. An ephemeral ID does not persist across Oracle Solaris system reboots. Ephemeral mappings enable the SMB server to work in a Windows environment without having to configure any name-based mappings.

The idmap service supports the following types of mappings between Windows security identifiers (SIDs) and Oracle Solaris user IDs and group IDs (UIDs and GIDs):

• Directory-based mapping. If configured, idmap first attempts to use mapping information that is stored in a directory with other user and group information.

  • Directory-based name mapping. In this mode, idmap attempts to use name mapping information that is stored in user or group objects in the Active Directory (AD), in the native LDAP directory service, or in both. For instance, an AD object for a particular Windows user or group can be augmented to include the corresponding Oracle Solaris user or group name. Similarly, the native LDAP object for a particular Oracle Solaris user or group can be augmented to include the corresponding Windows user or group name.

    You can configure idmap to use AD, native LDAP directory-based name mappings, or both, by setting the idmap service properties in the Service Management Facility (SMF). See Service Properties in the idmap(1M) man page.

  • Identity Management for UNIX (IDMU). In this mode, idmap attempts to use UID or GID information that is stored in the AD data for the Windows user or group. IDMU is an optional AD component that was added to Windows Server 2003R2. IDMU adds a UNIX Attributes tab to the Active Directory Users and Computers user interface.

  If directory-based name mapping is not configured, or if it is configured but the user or group entry does not include mapping data, idmap will continue to try additional mapping mechanisms.

• Rule-based mapping. This mechanism allows the administrator to define rules that associate Windows and Oracle Solaris users and groups by name.

• Ephemeral ID mapping. Windows users and groups that have no corresponding Oracle Solaris user or group are assigned temporary UIDs and GIDs. Over two billion identifiers are available for use. This mechanism is largely transparent if you have the ad source configured for the passwd and group databases in SMF. For more information, see Chapter 4, Setting Up Oracle Solaris Active Directory Clients (Tasks), in Oracle Solaris Administration: Naming and Directory Services.

You can use the idmap command to create and manage the rule-based mappings. These rules map the specified Windows name to the specified Oracle Solaris name, and map the specified Oracle Solaris name to the specified Windows name. By default, rule-based mappings that you create are bidirectional.

The following example shows a bidirectional mapping of the Windows user dana@example.com to danas, the Oracle Solaris user. Note that dana@example.com maps to danas, and danas maps to dana@example.com.

dana@example.com == danas

For more information about other mapping types, see the idmap(1M) man page.