Solaris CIFS Administration Guide

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.

Using name-based mapping. If your Windows environment includes a parallel Solaris naming service infrastructure, such as NIS, you might want to use name-based mappings to associate Windows users with Solaris users, and Windows groups with Solaris groups.

Name-based mappings include directory-based mappings and rule-based mappings. 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. A rule-based mapping uses rules to associate Windows users and groups with equivalent Solaris users and groups by name rather than by identifier.

To use name-based mapping, do the following:
1. Choose a Windows domain that is the most natural counterpart to the Solaris naming service domain.
2. Determine whether to use directory-based or rule-based mappings.
  
  These name-based mapping types have the following strengths and weaknesses:
  - Directory-based 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 CIFS 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 services to employ:
    - If you have already deployed AD or native LDAP, use that naming service.
    - If you want 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.
  - Rule-based mappings. Are easy to configure and can be configured with a single wildcard rule. However, the mapping rules are only stored on a particular computer rather than being global. This method is more suitable if only one CIFS server is being used in your environment.
- Using 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. Use the svccfg command to enable directory-based mapping on the Solaris system. Also, inform the idmap service about the new AD attributes, the native LDAP attributes, or both types of attributes that are used by the user and group objects. See How to Configure Directory-Based Mapping.
- Using rule-based mapping.
  1. Create a bidirectional rule-based mapping to map all users in the Windows domain to users of the same name in the Solaris domain.
    # idmap add 'winuser:*@example.com' 'unixuser:*' # idmap add 'wingroup:*@example.com' 'unixgroup:*'
    The previous commands map not only user names, but group names. For instance, the first command would map the Windows user called pat@example.com to the Solaris user pat. The second command would map the Windows group called staff@example.com to the Solaris group staff.
    
    Note –
    You can only have one bidirectional rule-based mapping to map all users in a single Windows domain to all Solaris users in the local Solaris domain.
  2. Create bidirectional rule-based mappings for users and groups whose Windows names do not exactly match the Solaris names.
    # idmap add winuser:terry@example.com unixuser:terrym
    The previous command would map a Windows user called terry@example.com to the Solaris user terrym.
  Caution –
  Rule-based identity mappings can be used to map Windows users and groups to, for example, the nobody Solaris user and group. In some circumstances, such a mapping can lock a user out of the CIFS service.
  
  The mapping works on both a per-user and a per-group basis and for entire Windows domains. Successfully using this type of mapping to lock out users depends on the rule-based mappings being in sync with the actual names in the naming service, such as AD. As a result, this type of mapping might not be a reliable way to lock users out of the CIFS service, and should not be used for that purpose.
  
  This scheme could be used to lock out a user if the administrator who maintains the user and group namespace is the same administrator who maintains the identity mappings. If not, however, you could get into a situation where one administrator creates the rule to lock the user out and another administrator grants a request to change the user name. In that case, the rule created to lock the user out only applies to his old user name, not to the new name. Thus, the user is no longer locked out of the CIFS service as intended.
  
  To ensure that a user is correctly locked out, lock out the user in the naming services.
  
  For example, creating a bidirectional mapping between the dana@example.com and nobody users does not prevent user dana@example.com from bypassing this attempt to deny him access to the CIFS service. He can simply have his user name changed to something else so that the rule will no longer apply.
Using ephemeral ID mapping. If your Windows environment does not already include a parallel Solaris naming service infrastructure, such as NIS, you do not need to create rule-based identity mappings. Instead, the default identity mapping configuration uses ephemeral IDs to map between Windows SIDs and Solaris UIDs and GIDs.