Mapping User and Group Identities

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

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

The Solaris CIFS service determines the Windows user's Solaris credentials by using the idmapd 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 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 Solaris system reboots. Ephemeral mappings enable the Solaris CIFS service to work in a Windows environment without having to configure any name-based mappings.

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

• Name-based mapping. Maps Windows and Solaris users and groups by name when the Solaris CIFS service is in domain mode. For more information, see The Solaris CIFS Service. Name-based mapping works in the following ways:

  • Directory-based mapping. If configured, idmapd first tries 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 Solaris user or group name. Similarly, the native LDAP object for a particular Solaris user or group can be augmented to include the corresponding Windows user or group name.

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

    If directory-based name mapping is not configured or if it is configured but not found, idmapd will process locally stored rule-based mappings.

  • Rule-based mapping. An administrator maps Windows and Solaris users and groups by name.

• Ephemeral ID mapping. A UID or GID is dynamically allocated for every SID that is not mapped by name.

• Local SID mapping. A non-ephemeral UID or GID is mapped to an algorithmically generated local SID if it is not mapped by name.

You can use the idmap command to create and manage the rule-based mappings.

When you specify rule-based mappings, you must specify the direction in which the mapping occurs, as follows:

• Bidirectional mapping. Map the specified Windows name to the specified Solaris name, and map the specified 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 Solaris user. Note that dana@example.com maps to danas, and danas maps to dana@example.com.

  dana@example.com == danas

• Unidirectional mapping. Map the names only in the specified direction.

  The following example combines unidirectional and bidirectional mappings to map between Windows users dana@example.com and danasan@example.com and Solaris user danas. The bidirectional rule maps between Windows user dana@example.com and Solaris user danas. The unidirectional rule maps Windows user danasan@example.com to the Solaris user danas. When Solaris user danas needs to map to the appropriate Windows user, it maps to dana@example.com.

  dana@example.com == danas danasan@example.com => danas

On Windows and Solaris systems, files have an owner attribute and a group attribute. A Solaris file owner attribute must be a UID, and the group attribute must be a GID. Unlike the Solaris OS, Windows has no such restrictions. Windows permits either a user SID or a group SID to be a file owner or a file group. In fact, Windows uses the Administrator Group as a file owner in many instances, and any Windows application can set the file owner and group attributes to any SID.

The Solaris system cannot interchange UIDs and GIDs like Windows can. Therefore, the Solaris system must be able to perform the following types of mappings:

• Map a group SID to a UID when the group SID occurs in an owner field

• Map a user SID to a GID when the user SID occurs in group field

These are called diagonal mappings, which use naming rules to set up the mappings.

Solaris Users and Groups

Solaris users and groups can be defined in local files (/etc/passwd and /etc/group) or in a naming or directory service, such as NIS and LDAP. The naming services you configure are listed in the Solaris naming services switch file /etc/nsswitch.conf. For more information, see Chapter 2, The Name Service Switch (Overview), in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

The Solaris CIFS service can be configured as a client of the various distributed naming services, such as NIS and LDAP. For information about configuring the Solaris CIFS service as a client for these naming services, see System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Each user and group is assigned a 32-bit identifier known, respectively, as a user ID (UID) and a group ID (GID). The Solaris OS has extended the uid_t and gid_t types from signed to unsigned 32-bit integers. Now that the uid_t and gid_t types are unsigned, the upper half of these namespaces is available for ephemeral dynamic ID mapping. This mapping process enable IDs to be assigned dynamically and ephemerally on demand. An ephemeral mapping is one that does not survive a Solaris system reboot. Typically, the UID or GID uniquely identifies a user or group within a single Solaris domain. However, these values are not unique across domains.

Traditionally, UID 0 or GID 0 is assigned to the root user or group. The root user is granted almost unlimited access to system objects in order to perform administration tasks.

Windows Users and Groups

Windows users and groups are defined in a Security Account Manager (SAM) database, which is managed on a Windows domain controller. Each user and group is identified by a security identifier (SID). An SID is a variable-length structure that uniquely identifies a user or group both within a host and a local domain, and across all possible Windows domains.

The text form of an SID is represented as follows:

S-R-I-SA-SA-..-SA

The following describes the fields in the SID text string:

• S – Identifies the string as an SID.

• R – Identifies the revision number, which is currently 1.

• I – Identifies the 48-bit identifier authority value, which is the agent or namespace that issued the SID.

• SA – Is one or more subauthorities, such as a relative identifier (RID).

In a domain SID, the RIDs identify the domain. In a user or group SID, except for the last RID, the RIDs identify the machine or the domain that issues the SID. The last RID identifies the user or group.

For example, the S-1-5-32-500 SID contains a version number of 1. The identifier authority value is 5, and it contains the 32 and 500 subauthorities. The value 500 is the RID.

The idmapd service generates a unique SID for the host on which it runs. This SID is used to represent both users and groups that cannot be mapped by name to SIDs. This SID is stored in the equivalent of a local SAM database. The Solaris computer SID is generated randomly.

The idmap service generates a unique SID, machine-SID, for the host on which it runs. This SID is used to generate local SIDs as follows:

local SID for user = machine-SID - 1000 + user's-UID
local SID for group = machine-SID - 2^31 + group's-GID

For instance, the local SID for a user with a UID of 182048 and a machine SID of S-1-5-21-726303253-4128413635 is S-1-5-21-726303253-4128413635-183048.

Local SIDs are used to represent Solaris users or groups that have non-ephemeral UIDs or GIDs and that cannot be mapped by name.