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 ZFS, 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 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 [email protected] to danas, the Solaris user. Note that [email protected] maps to danas, and danas maps to [email protected].
[email protected] == danas
Unidirectional mapping. Map the names only in the specified direction.
The following example combines unidirectional and bidirectional mappings to map between Windows users [email protected] and [email protected] and Solaris user danas. The bidirectional rule maps between Windows user [email protected] and Solaris user danas. The unidirectional rule maps Windows user [email protected] to the Solaris user danas. When Solaris user danas needs to map to the appropriate Windows user, it maps to [email protected].
[email protected] == danas
[email protected] => 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:
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.
