Creating Your Identity Mapping Strategy

Your SMB server can use directory-based mapping, rule-based mapping, both, or neither. By default, Windows users and groups do not need to be associated with Oracle Solaris users and groups. Without any mapping, Windows users and groups can still own files, be listed in ACLs, and such. Identity mapping is required when users need access to files from both Windows and Oracle Solaris operating systems or NFS. These mappings enable a user to be treated the same whether locally logged in or connected from a Windows system or through NFS.

If your Windows environment includes a parallel Oracle Solaris naming service infrastructure, such as NIS, consider using name-based mappings to associate Windows users with Oracle Solaris users, and Windows groups with Oracle Solaris groups.

A directory-based mapping uses name mapping information that is stored in user or group objects in the Active Directory (AD), in the native LDAP directory service, or both, to map users and groups.

• Using directory-based name mapping. Directory-based name mappings are stored globally, and each mapping is configured individually. However, the setup is rather difficult and time-consuming. This method is more suitable if many SMB servers are being used in your environment.

  If you decide to use directory-based mappings, use one of the following guidelines to determine which naming service or services to employ:

  • If you have already deployed AD or native LDAP, use that naming service.

  • For one-to-one mappings, choose either AD-only or native LDAP-only modes as follows:

    • If you have few native LDAP domains and do most of your administration in AD, choose AD-only mode.

    • Otherwise, choose native LDAP-only mode.

  • If you need more flexibility than one-to-one mappings offer, choose mixed mode.

    For example, to map Windows entities to one native LDAP user, group, or both, use mixed mode. Similarly, use mixed mode to map multiple native LDAP users or groups to one Windows entity.

    Alternatively, you can employ directory-based mapping and name-based rules.

  1. Extend the AD schema, the native LDAP schema, or both, with new attributes to represent a UNIX user name, a UNIX group name, or a Windows name. Also, populate the AD or native LDAP user and group objects, or both types of objects, with the appropriate attribute and value. 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.

     ---

     Note - If you do not want to modify the schema and suitable attributes already exist in either AD or native LDAP, use those attributes.

     ---

  2. Enable directory-based mapping and to inform the idmap service about the attributes to be used. See How to Configure Directory-Based Mapping.

• Using Identity Management for UNIX. IDMU is an optional Active Directory feature that enables administrators to specify UNIX-specific information for Active Directory users and groups. When IDMU support is enabled, idmap uses the UID and GID information maintained by IDMU to map Windows users and groups to the equivalent Oracle Solaris users and groups. Use IDMU in the following situations:

  • You want to use a user interface that is integrated into the Active Directory user interface.

  • You are using IDMU and a Windows NIS server to provide UNIX naming services.

  IDMU data is used only for users and groups in the domain to which the Oracle Solaris system is joined. If it is necessary to provide mappings for users and groups from other domains, you must use a different strategy, either in addition to or instead of IDMU.

  To use IDMU, do the following:

  1. Use the Windows Server Manager to install IDMU on the Active Directory domain controller.

  2. Use the UNIX Attributes tab in the Active Directory Users and Computers tool to specify UIDs and GIDs for your users.

  3. Enable idmap IDMU support. See How to Enable Identity Management for UNIX Support.

• Using rule-based mapping. A rule-based mapping uses rules to associate Windows users and groups with equivalent Oracle Solaris users and groups by name rather than by identifier.

  These mappings are easy to configure and can be configured with a single wildcard rule. However, the mapping rules are only stored on a particular system rather than being global. This method is more suitable if only one SMB server is being used in your environment.

  1. Create a bidirectional rule-based mapping to map all users in the Windows domain to users of the same name in the Oracle Solaris domain.

     # idmap add 'winuser:*@example.com' 'unixuser:*'
     # idmap add 'wingroup:*@example.com' 'unixgroup:*'

     The first command maps the Windows user called pat@example.com to the Oracle Solaris user pat. The second command maps the Windows group called staff@example.com to the Oracle Solaris group staff.

     ---

     Note - You can only have one bidirectional rule-based mapping to map all users in a single Windows domain to all Oracle Solaris users in the local Oracle Solaris domain. If you instead had wildcard mappings for two domains, it would not be possible to determine which domain to use when mapping an Oracle Solaris user to a Windows user.

     ---

  2. Create bidirectional rule-based mappings for users and groups whose Windows names do not exactly match the Oracle Solaris names.

     # idmap add winuser:terry@example.com unixuser:terrym

     The previous command maps a Windows user called terry@example.com to the Oracle Solaris user terrym.

Mapping Well-Known Windows Account Names

The idmap service supports the mapping of well-known Windows account names, such as the following:

• Administrator

• Guest

• Network

• Administrators

• Guests

• Computers

When idmap rules are added, these well-known account names are expanded to canonical form, which adds either the default domain name (for names that are not well known) or an appropriate built-in domain name. Depending on the particular well-known name, this domain name might be null, BUILTIN, or the local host name.

The following sequence of idmap commands shows the treatment of the name dana, which is not well known, and the well-known names administrator and guest:

# idmap add winname:dana unixuser:danam
add     winname:dana    unixuser:danam
# idmap add winname:administrator unixuser:root
add     winname:administrator   unixuser:root
# idmap add winname:guest unixuser:nobody
add     winname:guest   unixuser:nobody
# idmap add wingroup:administrators sysadmin
add     wingroup:administrators unixgroup:sysadmin
# idmap list
add     winname:Administrator@examplehost  unixuser:root
add     winname:Guest@examplehost  unixuser:nobody
add     wingroup:Administrators@BUILTIN unixgroup:sysadmin
add     winname:dana@example.com       unixuser:danam