Go to main content

Managing SMB File Sharing and Windows Interoperability in Oracle® Solaris 11.3

Exit Print View

Updated: December 2017
 
 

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 so forth. Identity mapping is required only 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. Use this method 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, 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 what one-to-one mappings offer, use both the above options.

    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.

  • You can employ directory-based mapping and name-based rules.

Use the following method to configure the directory-based mapping:

  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 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 you have to provide mappings for users and groups from other domains, you must use a different strategy, either in addition to or instead of IDMU. See How to Enable Identity Management for UNIX Support.

Using Rule-Based Mapping

This strategy 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 stored only on a particular system rather than being global. Use this method 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 have only 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. Wildcard mappings for two domains would make determining which domain to use when mapping an Oracle Solaris user to a Windows user impossible.
  2. Create bidirectional rule-based mappings for users and groups whose Windows names do not exactly match the Oracle Solaris names.

    # idmap add winuser:john@example.com unixuser:johnm

    This command maps a Windows user called john@example.com to the Oracle Solaris user johnm.

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. This process 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 mary, which is not well known, and the well-known names administrator and guest:

# idmap add winname:mary unixuser:marym
add     winname:mary    unixuser:marym
# 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:mary@example.com       unixuser:marym