Solaris CIFS Administration Guide

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):

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:

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:

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:


The following describes the fields in the SID text string:

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.