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.
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:
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.
Enable directory-based mapping and inform the idmap service about the attributes to be used. See How to Configure Directory-Based Mapping.
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.
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.
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.
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.
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