test

Solaris CIFS Administration Guide

Chapter 2 Identity Mapping Administration (Tasks)

This chapter describes the identity mapping service that maps Windows security identifiers (SIDs) to Solaris user identifiers (UIDs) and group identifiers (GIDs). The chapter also includes instructions on how to manage name-based mappings.

This chapter covers the following topics:

The idmapd service can run in the global zone or in non-global zones. However, if Solaris Trusted Extensions software is enabled, the idmapd service must run in the global zone.

Note –

CIFS is an enhanced version of the SMB protocol, which allows CIFS clients to access files and resources on CIFS servers. The terms SMB and CIFS can be considered interchangeable.

Up-to-date troubleshooting information is available from the OpenSolaris CIFS Server project page.

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:


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

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.

Configuring DNS for Identity Mapping in Domain Mode

The idmap service requires that DNS be configured properly before you join a Solaris system to an AD domain.

Note –

This DNS configuration is only required for domain mode though the idmap service operates in workgroup mode as well. When in workgroup mode, domain name-based mapping is not performed.

The idmapd daemon uses DNS information that is specified in the /etc/resolv.conf configuration file to discover its domain.

The domain is specified by the value of the domain or search configuration directive.

If both the domain and search directives are used, the last directive that is specified determines the domain to be used for auto-discovery.

The idmapd daemon discovers the domain controller and the global catalog by performing DNS lookups for SRV records. These SRV records are generated by the DNS server that is part of AD on the Windows domain controller. Therefore, the simplest way to configure DNS is to point to the DNS server on the Windows domain controller.

The idmap service looks for the following SRV records:


_ldap._tcp.dc._msdcs.domain-name
_ldap._tcp.site-name._sites.dc._msdcs.domain-name
_ldap._tcp.gc._msdcs.forest-name
_ldap._tcp.site-name._sites.gc._msdcs.forest-name

You can verify that the configuration is working properly by running the following, which should return the name of the Windows domain controller:


# dig _ldap._tcp.domain-name SRV +short

For example, the following returns the domain controller for the sales.example.com domain:


# dig _ldap._tcp.sales.example.com SRV +short
0 100 389 test-win2k3.sales.example.com.

After DNS is correctly configured, you can join the Solaris system to an AD domain by using the smbadm or kclient utility. For more information about using the smbadm command see, How to Configure the Solaris CIFS Service in Domain Mode and the smbadm(1M) man page. For information about the kclient command, see the kclient(1M) man page.

Note –

If the idmap service is unable to discover an AD server, the service only handles mappings for well-known SIDs and local SIDs.

Creating Your Identity Mapping Strategy

Windows SID to Solaris UID and GID mapping is required when the Solaris CIFS service is deployed to a Windows environment. The identity mapping enables Windows clients to transparently access CIFS shares and remote services from the Solaris CIFS service.

Your Solaris CIFS service can use name-based mapping, ephemeral ID mapping, or both. By default, the server uses ephemeral ID mapping, which dynamically assigns an ephemeral ID as a UID or a GID for a particular Windows SID. The identity mapping strategy you choose depends on the type of Windows environment you have.

Managing Directory-Based Identity Mapping for Users and Groups (Task Map)

The following table points to the tasks that you can use to manage directory-based identity mapping for the Solaris CIFS service in a Windows environment.

These tasks use the idmap(1M) command to manage identity mapping.

Task 

Description 

For Instructions 

Extend the Active Directory (AD) schema with user and group name attributes. 

This procedure describes how to extend the AD schema and populate the user and group objects with UNIX user and group name information. 

How to Extend the Active Directory Schema, and User and Group Entries

Extend the native LDAP schema with user and group name attributes. 

This procedure describes how to extend the native LDAP schema and populate the user and group objects with Windows user and group name information. 

How to Extend the Native LDAP Schema, and User and Group Entries

Configure directory-based name mapping. 

Use this procedure to enable directory-based mapping. This procedure also informs the idmap service about the new AD schema attributes that are used by the user and group objects.

How to Configure Directory-Based Mapping

Add a directory-based name mapping to a user object. 

Use this procedure to add a directory-based name mapping to a user object in AD or native LDAP. 

How to Add a Directory-Based Name Mapping to a User Object

Add a directory-based name mapping to a group object. 

Use this procedure to add a directory-based name mapping to a group object in AD or native LDAP. 

How to Add a Directory-Based Name Mapping to a Group Object

Remove a directory-based name mapping from a user object. 

Use this procedure to remove a directory-based name mapping from a user object in AD or native LDAP. 

How to Remove a Directory-Based Name Mapping From a User Object

Remove a directory-based name mapping from a group object. 

Use this procedure to remove a directory-based name mapping from a group object in AD or native LDAP. 

How to Remove a Directory-Based Name Mapping From a Group Object

For more information about user and group identities, see Mapping User and Group Identities.

For more information about how to determine your identity mapping strategy, see Creating Your Identity Mapping Strategy.

Note –

In a cluster configuration, changes made to user maps and to group maps on one server are immediately propagated to the other server.

ProcedureHow to Extend the Active Directory Schema, and User and Group Entries

This procedure shows how to extend the AD schema and populate the user and group objects with the associated Solaris names.

Note –

Perform this task before enabling directory-based mapping on your Solaris system.

  1. (Optional) Extend the AD schema to add the new UNIX user and group attributes.

    Note –

    If you do not want to extend the AD schema, you can use an existing AD schema attribute to store UNIX user and group name information. For instance, if you already have schema that is comparable to what is described in Example 2–1, you can use your attributes instead of creating new ones.

    1. Create an LDAP Data Interchange Format (LDIF) file to describe the AD schema changes.

      For sample LDIF file contents, see Example 2–1. Also see Extending Your Active Directory Schema in Windows Server 2003 R2 and Step-by-Step Guide to Using Active Directory Schema and Display Specifiers on the Microsoft technet web site.

    2. Use the ldifde tool to load the schema changes into AD from the Windows server.


      C:\> ldifde -v -i -f input-file

  2. Use the ldapmodify command to populate the AD user and group objects with the new attributes and their values.

    You can use the idmap set-namemap command to populate user and group objects. See How to Add a Directory-Based Name Mapping to a User Object and How to Add a Directory-Based Name Mapping to a Group Object.

    You can also use any of the Windows AD utilities to populate these objects.

    1. Create an LDIF file to record the updates to the AD user and group objects.

      See a sample LDIF file in Example 2–2. For more information about the LDIF file format, see RFC 2849.

    2. Use the kinit command to obtain a Kerberos ticket-granting ticket (TGT) for a privileged AD principal.

      This principal will be used by the ldapmodify command to update the AD objects described in the file you created in the previous substep.

      For example:


      $ kinit Administrator
Password for Administrator@EXAMPLE.COM:

    3. Use the ldapmodify command to update the user objects on the AD server.


      $ ldapmodify -h AD-server-name -o mech=gssapi -o authzid='' -f input-file
Example 2–1 Extending the AD Schema

The following LDIF example file, ad_namemap_schema.ldif, describes the AD schema changes:


dn: CN=unixUserName, CN=Schema, CN=Configuration, DC=example, DC=com
changetype: add
attributeID: 1.3.6.1.4.1.42.2.27.5.1.60
attributeSyntax: 2.5.5.3
isSingleValued: TRUE
searchFlags: 1
lDAPDisplayName: unixUserName
adminDescription: This attribute contains the object's UNIX username
objectClass: attributeSchema
oMSyntax: 27

dn: CN=unixGroupName, CN=Schema, CN=Configuration, DC=example, DC=com
changetype: add
attributeID: 1.3.6.1.4.1.42.2.27.5.1.61
attributeSyntax: 2.5.5.3
isSingleValued: TRUE
searchFlags: 1
lDAPDisplayName: unixGroupName
adminDescription: This attribute contains the object's UNIX groupname
objectClass: attributeSchema
oMSyntax: 27

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=unixNameInfo, CN=Schema, CN=Configuration, DC=example, DC=com
changetype: add
governsID: 1.3.6.1.4.1.42.2.27.5.2.15
lDAPDisplayName: unixNameInfo
adminDescription: Auxiliary class to store UNIX name info in AD
mayContain: unixUserName
mayContain: unixGroupName
objectClass: classSchema
objectClassCategory: 3
subClassOf: top

Use the ldifde tool to load the schema changes into AD from the Windows server:


C:\> ldifde -v -i -f ad_namemap_schema.ldif
Example 2–2 Populating AD User and Group Objects

The following example has Windows users terry, cal, and dana stored in Active Directory. These Windows users are associated with the Solaris users tmw, crj, and dab, respectively.

This example shows how to add the Solaris user names to the appropriate user objects in AD by using the ldapmodify command.

First, create an input file, updateUsers, that associates the Windows names with the Solaris names:


$ cat updateUsers
dn: CN=Terry Walters,CN=Users,DC=example,DC=com
changetype: modify
add: unixUserName
unixUserName: tmw

dn: CN=Cal Jamieson,CN=Users,DC=example,DC=com
changetype: modify
add: unixUserName
unixUserName: crj

dn: CN=Dana Bloom,CN=Users,DC=example,DC=com
changetype: modify
add: unixUserName
unixUserName: dab
$

Next, use the kinit command to obtain a TGT for a privileged principal:


$ kinit Administrator
Password for Administrator@EXAMPLE.COM:

Finally, run the ldapmodify command to update the user objects on the AD server, saturn:


$ ldapmodify -h saturn -o mech=gssapi -o authzid='' -f updateUsers

ProcedureHow to Extend the Native LDAP Schema, and User and Group Entries

This procedure shows how to extend the native LDAP schema and populate the user and group objects with the associated Windows names.

Note –

Perform this task before enabling directory-based mapping on your Solaris system.

  1. (Optional) Extend the native LDAP schema to add the new Windows user and group attributes.

    Note –

    If you do not want to extend the native LDAP schema, you can use an existing native LDAP schema attribute to store Windows user and group name information. For instance, if you already have schema that is comparable to what is described in Example 2–3, you can use your attributes instead of creating new ones.

    1. Create an LDAP Data Interchange Format (LDIF) file to describe the native LDAP schema changes.

      For sample LDIF file contents, see Example 2–3.

    2. Use the ldapmodify tool to load the schema changes into native LDAP.


      $ ldapmodify -D cn=admin -w p -f input-file

  2. Use the ldapmodify command to populate the native LDAP user and group objects with the new attributes and their values.

    You can use the idmap set-namemap command to populate user and group objects. See How to Add a Directory-Based Name Mapping to a User Object and How to Add a Directory-Based Name Mapping to a Group Object.

    1. Create an LDIF file to record the updates to the native LDAP user and group objects.

      See a sample LDIF file in Example 2–4. For more information about the LDIF file format, see RFC 2849.

    2. Use the ldapmodify command to update the user objects on the native LDAP server.


      $ ldapmodify -h LDAP-server-name -o mech=gssapi -o authzid='' -f input-file
Example 2–3 Extending the Native LDAP Schema

The following LDIF example file, nldap_namemap_schema.ldif, describes the native LDAP schema changes:


dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.42.2.27.5.1.62
   NAME 'winAccountName'
   DESC 'Windows user or group name corresponding to a Unix user or group'
   EQUALITY caseIgnoreMatch
   SUBSTRINGS caseIgnoreSubstringsMatch
   ORDERING caseIgnoreOrderingMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.42.2.27.5.2.16
   NAME 'winAccount'
   DESC 'Auxiliary class to store Windows name mappings in Unix user/group objects'
   SUP top
   AUXILIARY
   MAY winAccountName )

Use the ldapmodify tool to load the schema changes into native LDAP:


$ ldapmodify -D cn=admin -w - -f f nldap_namemap_schema.ldif
Enter bind password:
modifying entry cn=schema
Example 2–4 Populating Native LDAP User and Group Objects

The following example has Solaris users tmw, crj, and dab stored in native LDAP. These Solaris users are associated with the Windows users terry, cal, and dana, respectively.

This example shows how to add the Windows user names to the appropriate user objects in native LDAP by using the ldapmodify command.

First, create an input file, updateUsers, that associates the Solaris names with the Windows names:


$ cat updateUsers
dn: uid=tmw,ou=passwd,dc=example,dc=com
changetype: modify
add: winAccountName
winAccountName: terry@example.com

dn: uid=crj,ou=passwd,dc=example,dc=com
changetype: modify
add: winAccountame
winAccountame: cal@example.com

dn: uid=dab,ou=passwd,dc=example,dc=com
changetype: modify
add: winAccountame
winAccountame: dana@example.com
$

Then, run the ldapmodify command to update the user objects on the native LDAP server, neptune:


$ ldapmodify -h neptune -o mech=gssapi -o authzid='' -f updateUsers

ProcedureHow to Configure Directory-Based Mapping

Before You Begin

Before you can enable directory-based mapping on your Solaris system, you must extend the AD schema, the native LDAP schema, or both, and populate the user and group objects with the associated Solaris names. See How to Extend the Active Directory Schema, and User and Group Entries and How to Extend the Native LDAP Schema, and User and Group Entries.

  1. Enable directory-based mapping.


    # svccfg -s svc:/system/idmap setprop config/ds_name_mapping_enabled=boolean: true

  2. Inform the idmap service about the new user and group attributes.

    Note –

    To fully enable directory-based mapping, you must specify values for the following properties depending on the directory service or services you plan to use:

    • config/ad_unixuser_attr

    • config/ad_unixgroup_attr

    • config/nldap_winname_attr

    These properties do not have default values. If the properties are not set, directory-based mapping is effectively disabled for the corresponding naming service.

    In an environment that stores user and group name information in both Active Directory and native LDAP, perform the steps for each naming service.

    • For Active Directory, inform the idmap service about the new Active Directory UNIX user and group attributes.


      # svccfg -s svc:/system/idmap setprop \
config/ad_unixuser_attr=astring: attribute-name
# svccfg -s svc:/system/idmap setprop \
config/ad_unixgroup_attr=astring: attribute-name

      attribute-name is the attribute name you choose for the UNIX user or group name to be stored in AD.

      For example, the following specifies the unixGroupName and unixUserName attribute names for the UNIX group and user names, respectively:


      # svccfg -s svc:/system/idmap setprop \
config/ad_unixgroup_attr=astring: unixGroupName
# svccfg -s svc:/system/idmap setprop \
config/ad_unixuser_attr=astring: unixUserName

    • For native LDAP, inform the idmap service about the new native LDAP Windows name attribute.


      # svccfg -s svc:/system/idmap setprop \
config/nldap_winname_attr=astring: attribute-name

      attribute-name is the attribute name you choose for the Windows name to be stored in native LDAP.

      For example, the following specifies the winAccountName attribute name for the Windows name:


      # svccfg -s svc:/system/idmap setprop \
config/nldap_winname_attr=astring: winAccountName

ProcedureHow to Add a Directory-Based Name Mapping to a User Object

This procedure shows how to perform the following directory-based name mapping:

For more information about the idmap set-namemap command and its options, see the idmap(1M) man page.

  1. Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or use the “Idmap Service Management” RBAC profile.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Determine whether to augment a user object in AD or in the native LDAP service.

    • To augment the Windows user object in AD, type:


      # idmap set-namemap winuser:username@domain-name unixuser:username

      For example, the following command maps Windows user danab@example.com to Solaris user dana by adding the Solaris name to the AD object for danab@example.com:


      # idmap set-namemap winuser:danab@example.com unixuser:dana

    • To augment the Solaris user object in native LDAP, type:


      # idmap set-namemap unixuser:username winuser:username@domain-name

      For example, the following command maps Solaris user dana to Windows user danab@example.com by adding the Windows name to the native LDAP object for dana:


      # idmap set-namemap unixuser:dana winuser:danab@example.com

ProcedureHow to Add a Directory-Based Name Mapping to a Group Object

This procedure shows how to perform the following directory-based name mapping:

  1. Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or use the “Idmap Service Management” RBAC profile.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Determine whether to augment a group object in AD or in the native LDAP service.

    • To augment the Windows group object in AD, type:


      # idmap set-namemap wingroup:group-name@domain-name unixgroup:group-name

      For example, the following command maps Windows group salesgrp@example.com to Solaris group sales by adding the Solaris name to the AD object for salesgrp@example.com:


      # idmap set-namemap wingroup:salesgrp@example.com unixgroup:sales

    • To augment the Solaris group object in native LDAP, type:


      # idmap set-namemap unixgroup:group-name wingroup:group-name@domain-name

      For example, the following command maps Solaris group sales to Windows group salesgrp@example.com by adding the Windows name to the native LDAP object for sales:


      # idmap set-namemap unixgroup:sales wingroup:salesgrp@example.com

ProcedureHow to Remove a Directory-Based Name Mapping From a User Object

  1. Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or use the “Idmap Service Management” RBAC profile.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. View the directory-based name mapping information for the specified user.


    # idmap get-namemap username

  3. Remove the user name stored in the user object of AD or native LDAP.

    • Remove the Solaris name from the AD object for the specified user.


      # idmap unset-namemap winuser:username@domain-name

      For example, the following command removes the Solaris name from the AD object for Windows user danab@example.com:


      # idmap unset-namemap winuser:danab@example.com

    • Remove the Windows name from the native LDAP object for the specified user.


      # idmap unset-namemap unixuser:username

      For example, the following command removes the Windows name from the native LDAP object for Solaris user dana:


      # idmap unset-namemap unixuser:dana

ProcedureHow to Remove a Directory-Based Name Mapping From a Group Object

  1. Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or use the “Idmap Service Management” RBAC profile.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. View the directory-based name mapping information for the specified group.


    # idmap get-namemap group-name

  3. Remove the group name stored in the group object of AD or native LDAP.

    • Remove the Solaris name from the AD object for the specified group.


      # idmap unset-namemap wingroup:group-name@domain-name

      For example, the following command removes the Solaris name from the AD object for Windows group salesgrp@example.com:


      # idmap unset-namemap wingroup:salesgrp@example.com

    • Remove the Windows name from the native LDAP object for the specified group.


      # idmap unset-namemap unixgroup:group-name

      For example, the following command removes the Windows name from the native LDAP object for Solaris group sales:


      # idmap unset-namemap unixgroup:sales

Managing Rule-Based Identity Mapping for Users and Groups (Task Map)

Windows systems and Solaris systems use different identity schemes to determine who is permitted to access systems and system objects. When the Solaris CIFS service is integrated into an existing Windows domain, the Solaris user IDs and group IDs must find equivalent Windows SIDs to use for authorization and file access. The Solaris CIFS service uses identity mapping software to perform these tasks.

By default, no rule-based mappings are configured. In this case, non-ephemeral Solaris UIDs and GIDs are mapped to local SIDs. Local SIDs are composed of the server's SID and an RID that is derived algorithmically from the UID or GID. Similarly, domain user and group SIDs are mapped to ephemerally, dynamically allocated UIDs and GIDs. A system administrator can also create a set of rule-based mappings to map users and groups by name. Such rule-based mapping requires that Windows uses Active Directory and that the specified users and groups must already exist.

The following table points to the tasks that you can use to manage rule-based identity mapping for the Solaris CIFS service in a Windows environment. These tasks use the idmap(1M) command to manage identity mapping.

Task 

Description 

For Instructions 

Add a user mapping rule. 

Use rules to create identity equivalents for Windows users and Solaris users based on the names in the naming services. 

How to Add a User Mapping Rule

Add a group mapping rule. 

Use rules to create identity equivalents for Windows groups and Solaris groups based on the names in the naming services. 

How to Add a Group Mapping Rule

Import rule-based user mappings from the usermap.cfg file.

Use this procedure to add one or more user mappings from a usermap.cfg file that specifies rule-based mappings.

How to Import User Mappings From a Rule-Mapping File

List all of the mappings. 

Use this procedure to review all mappings or to find particular mappings for users and groups. 

How to Show Mappings

Show the mapping for a particular identity. 

Use this procedure to view how a particular name or ID is mapped. 

How to Show a Mapping for a Particular Identity

Show all the established mappings. 

Use this procedure to view the mappings stored in the cache. 

How to Show All Established Mappings

Remove a user mapping rule. 

Use this procedure to remove a rule-based mapping when a user is no longer part of the naming service in your Windows domain. 

How to Remove a User Mapping Rule

Remove a group mapping rule. 

Use this procedure to remove a rule-based mapping when a group is no longer part of the naming service in your Windows domain. 

How to Remove a Group Mapping Rule

For more information about user and group identities, see Mapping User and Group Identities.

For more information about how to determine your identity mapping strategy, see Creating Your Identity Mapping Strategy.

Note –

In a cluster configuration, changes made to user maps and to group maps on one server are immediately propagated to the other server.

ProcedureHow to Add a User Mapping Rule

The idmap command enables you to create rule-based mappings between Windows users and Solaris users. By default, the Solaris CIFS service uses ephemeral identity mapping.

Shell special characters, such as the double quote character ("), the asterisk character (*), and the backslash character (\), must be quoted when used as user names and domain names.

  1. Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or use the “Idmap Service Management” RBAC profile.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Determine the user names that you want to map.

    1. Determine the domain and name of the Windows user that you want to map to a Solaris user.

      The Windows user name must be specified by using one of the following formats:

      • winuser:username@domain-name

      • winuser:'domain-name\username'

    2. Determine the name of the Solaris user that you want to map to the Windows user.

      The Solaris user name must be specified by using the format unixuser:username.

    If username is the empty string (""), mapping is inhibited. Only directional mappings can have an empty string as their target identity. No mapping is created by the identity mapping service, and the nobody ID is used for access control. Note that a user name of "" should not be used to preclude logins by unmapped Windows users.

    If username uses the wildcard (*), it matches all user names that are not matched by other mappings. Similarly, if username is the wildcard Windows name (*@*), it matches all user names in all domains that are not matched by other mappings.

  3. Create the user mapping.

    By default, identity mappings are bidirectional, which means that the Windows name is mapped to the Solaris name and the Solaris name is mapped to the Windows name. If you want the mapping to be unidirectional, specify the -d option.

    If username uses the wildcard on both sides of the mapping, the user name is the same for both Windows and Solaris users. For example, if the rule is '*@example.com' == '*', the jp@example.com Windows user name would match this rule and map to the jp Solaris user name.

    Caution – Caution –

    Be careful when creating rule-based mappings that use wildcards for the user names. Windows user names are case insensitive, while Solaris user names are case sensitive. Note that the case of Windows names that appear in idmap name rules and in idmap show commands is irrelevant.

    Solaris environments typically use lowercase characters for user names, but uppercase characters are permitted. Therefore, using a wildcard to map Windows names to Solaris user names might not produce the expected results. Rule-based mapping rules that use the unixuser:* target map to the Solaris user name as follows:

    • Map the canonical Windows name, which uses the found in the directory entry, to the matching Solaris user name.

    • If no such Solaris user name exists, fold the case of the canonical Windows name to lower case and use it as the Solaris CIFS user name.

    As a result of this differing treatment of case, user names that appear to be alike might not be recognized as matches. You must create rules to handle such pairings of strings that differ only in case. For example, to map Solaris user Kerry to Windows user kerry@example.com, you must create the following rule:


    # idmap add winuser:'*@example.com' unixuser:'*'
# idmap add winuser:kerry@example.com unixuser:Kerry

    • Create a bidirectional mapping between a Windows user name and a Solaris user name.


      # idmap add winuser:username@domain-name unixuser:username

    • Create a unidirectional mapping between a Windows user name and a Solaris user name.


      # idmap add -d winuser:username@domain-name unixuser:username

    • Create a unidirectional mapping between a Solaris user name and a Windows user name.


      # idmap add -d unixuser:username winuser:username@domain-name

ProcedureHow to Add a Group Mapping Rule

The idmap command enables you to create rule-based mappings between Windows groups and Solaris groups. By default, the Solaris CIFS service uses ephemeral identity mapping.

You can also create diagonal mappings to maps between a Windows group and a Solaris user and between a Solaris group and a Windows user. These mappings are needed when Windows uses a group identity as a file owner or a user identity as a file group.

Shell special characters, such as the double quote character ("), the asterisk character (*), and the backslash character (\), must be quoted when used as group names and domain names.

  1. Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or use the “Idmap Service Management” RBAC profile.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Determine the group names that you want to map.

    1. Determine the domain and name of the Windows group that you want to map to a Solaris group.

      The Windows group name must be specified by using one of the following formats:

      • wingroup:group-name@domain-name

      • wingroup:'domain-name\group-name'

    2. Determine the name of the Solaris user or group that you want to map to the Windows group.

      The Solaris group name must be specified by using the format unixgroup:group-name. The Solaris user name must be specified by using the format unixuser:username.

    If group-name is the empty string (""), mapping is inhibited.

    If group-name uses the wildcard (*), it matches all group names that are not matched by other mappings. Similarly, if group-name is the wildcard Windows name (*@*), it matches all group names in all domains that are not matched by other mappings.

  3. Create the group mapping.

    By default, identity mappings are bidirectional, which means that the Windows group name is mapped to the Solaris group name, and the Solaris group name is mapped to the Windows group name. If you want the mapping to be unidirectional, specify the -d option.

    If group-name uses the wildcard on both sides of the mapping, the group name is the same for both Windows groups and Solaris groups. For example, if the rule is "*@example.com" == "*", the staff@example.com Windows group name would match this rule and map to the staff Solaris group name.

    Caution – Caution –

    Be careful when creating rule-based mappings that use wildcards for the group names. Windows group names are case insensitive, while Solaris group names are case sensitive. Note that the case of Windows names that appear in idmap name rules and in idmap show commands is irrelevant.

    Solaris environments typically use lowercase characters for group names, but uppercase characters are permitted. Therefore, using a wildcard to map Windows names to Solaris group names might not produce the expected results. Rule-based mapping rules that use the unixgroup:* target map to the Solaris group name as follows:

    • Map the canonical Windows name, which uses the found in the directory entry, to the matching Solaris group name.

    • If no such Solaris group name exists, fold the case of the canonical Windows name to lower case and use it as the Solaris CIFS group name.

    As a result of this differing treatment of case, group names that appear to be alike might not be recognized as matches. You must create rules to handle such pairings of strings that differ only in case. For example, to map Solaris group Sales to Windows group sales@example.com, you must create the following rule:


    # idmap add wingroup:'*@example.com' unixgroup:'*'
# idmap add wingroup:sales@example.com unixgroup:Sales

    • Create a bidirectional mapping between a Windows group name and a Solaris group name.


      # idmap add wingroup:group-name@domain-name unixgroup:group-name

    • Create a unidirectional mapping between a Windows group name and a Solaris group name.


      # idmap add -d wingroup:group-name@domain-name unixgroup:group-name

    • Create a unidirectional mapping between a Solaris group name and a Windows group name.


      # idmap add -d unixgroup:group-name wingroup:group-name@domain-name

    • Create a diagonal mapping between a Windows group name and a Solaris user name.


      # idmap add -d wingroup:group-name@domain-name unixuser:username

    • Create a diagonal mapping between a Solaris group name and a Windows user name.


      # idmap add -d unixgroup:group-name winuser:username@domain-name

ProcedureHow to Import User Mappings From a Rule-Mapping File

The idmap import command enables you to import a set of rule-based user mappings that are stored in a file.

The idmap supports these file formats:

  1. Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or use the “Idmap Service Management” RBAC profile.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Import the user mappings from standard input or from a file.


    # idmap import [-F] [-f file] format

    For example, suppose that you have a file called myusermaps that uses the usermap.cfg format to specify the following user name mappings:


    # cat myusermaps
dana@example.com == dana
danab@example.com => dana

    Use one of the following commands to add these mappings to the database:

    • # cat myusermaps | idmap import usermap.cfg

    • # idmap import -f myusermaps usermap.cfg

ProcedureHow to Show Mappings

The idmap list command enables you to view all of the rule-based identity mappings that you created for users and groups. You can also find particular mappings for users and groups.

  1. List all of the mappings.


    $ idmap list
add winuser:terry@example.com unixuser:terrym
add wingroup:members unixgroup:staff

    • To optionally list only the user mappings, type:


      $ idmap list | grep user
add winuser:terry@example.com unixuser:terrym

    • To optionally list only the group mappings, type:


      $ idmap list | grep group
add wingroup:members unixgroup:staff

ProcedureHow to Show a Mapping for a Particular Identity

The idmap show command enables you to view the particular name or ID for a name or ID that you specify.

  1. Show the equivalent identity for a particular name or ID.


    $ idmap show [-c] [-v] identity [target-type]

    By default, the idmap show command only shows mappings that have already been established.

    For example, to view the SID that is mapped to UID 50000, type:


    $ idmap show uid:50000 sid
S-1-5-21-726303253-4128413635-1168184439

    To view the Solaris user name for the Windows user name terry@example.com, type:


    $ idmap show terry@example.com
terrym

    If you specify the -c option, idmap show forces the evaluation of rule-based mapping configurations or the dynamic allocation of IDs. This command also shows mapping information when an error occurs to help diagnose mapping problems.

    The -v option includes additional information about how the identity mapping was generated, which can help with troubleshooting. The following example shows that the mapping is ephemeral and was retrieved from the cache:


    # idmap show -v sid:S-1-5-21-2949573101-2750415176-3223191819-884217
sid:S-1-5-21-2949573101-2750415176-3223191819-884217 -> uid:2175201213
Source: Cache
Method: Ephemeral

    For name-based mappings, the idmap show -v command shows either the mapping rule or the directory distinguished name with the attribute and value that created the mapping.

ProcedureHow to Show All Established Mappings

The idmap dump command enables you to view all of the SID-to-UID and SID-to-GID mappings that are stored in the cache.

  1. List all of the mappings in the cache.

    By default, the idmap dump command only lists the mappings themselves. The -v option includes additional information about how the identity mapping was generated, which can help with troubleshooting.


    $ idmap dump
sid:S-1-5-21-2949573101-2750415176-3223191800-2000    ==     uid:50000
sid:S-1-5-21-2949573101-2750415176-3223191800-2001    ==     uid:50001
sid:S-1-5-21-2949573101-2750415176-3223191800-2006    ==     uid:50010
sid:S-1-5-21-2949573101-2750415176-3223191900-3000    ==     uid:2147491840
sid:S-1-5-21-2949573101-2750415176-3223191900-3001    ==     gid:2147491342
sid:S-1-5-21-2949573101-2750415176-3223191700-4000    =>     uid:60001
sid:S-1-5-21-2949573101-2750415176-3223191700-4001    =>     gid:60001
sid:S-1-5-21-2949573101-2750415176-3223191800-5000    ==     gid:50000
sid:S-1-5-21-2949573101-2750415176-3223191800-5001    ==     gid:50001

    • To optionally list only the user mappings, type:


      $ idmap dump | grep uid
sid:S-1-5-21-2949573101-2750415176-3223191800-2000    ==     uid:50000
sid:S-1-5-21-2949573101-2750415176-3223191800-2001    ==     uid:50001
sid:S-1-5-21-2949573101-2750415176-3223191800-2006    ==     uid:50010
sid:S-1-5-21-2949573101-2750415176-3223191900-3000    ==     uid:2147491840
sid:S-1-5-21-2949573101-2750415176-3223191700-4000    =>     uid:60001

    • To optionally list only the group mappings, type:


      $ idmap dump | grep gid
sid:S-1-5-21-2949573101-2750415176-3223191900-3001    ==     gid:2147491342
sid:S-1-5-21-2949573101-2750415176-3223191700-4001    =>     gid:60001
sid:S-1-5-21-2949573101-2750415176-3223191800-5000    ==     gid:50000
sid:S-1-5-21-2949573101-2750415176-3223191800-5001    ==     gid:50001

ProcedureHow to Remove a User Mapping Rule

The idmap command enables you to remove a rule-based mapping that you created.

  1. Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or use the “Idmap Service Management” RBAC profile.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Find the user mapping that you want to remove.


    # idmap list

    For example, to find all user mappings that map to the Solaris user pat, type:


    # idmap list | grep pat

  3. Remove one or more user mappings.

    • Remove any rule-based mapping that involves the specified user name, username.


      # idmap remove username

    • Remove rule-based mappings between username1 and username2.


      # idmap remove username1 username2

    • Remove all rule-based mappings.


      # idmap remove -a

ProcedureHow to Remove a Group Mapping Rule

The idmap command enables you to remove a rule-based mapping that you created.

  1. Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or use the “Idmap Service Management” RBAC profile.

    Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

  2. Find the group mapping that you want to remove.


    # idmap list

    For example, to find all unidirectional group mappings that map to the Solaris group staff, type:


    # idmap list | grep staff

  3. Remove one or more group mappings.

    • Remove any rule-based mapping that involves the specified group name, group-name.


      # idmap remove group-name

    • Remove rule-based mappings between group-name1 and group-name2.


      # idmap remove group-name1 group-name2

    • Remove all rule-based mappings.


      # idmap remove -a