Skip Navigation Links | |
Exit Print View | |
Managing SMB File Sharing and Windows Interoperability in Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library |
1. Sharing Files Between Windows and Oracle Solaris Systems
2. Setting Up Identity Mapping Between Windows and Oracle Solaris Systems
Mapping User and Group Identities
Managing Directory-Based Name Mapping for Users and Groups (Task Map)
How to Extend the Active Directory Schema, and User and Group Entries
How to Extend the Native LDAP Schema, and User and Group Entries
How to Configure Directory-Based Mapping
How to Add a Directory-Based Name Mapping to a User Object
How to Add a Directory-Based Name Mapping to a Group Object
How to Remove a Directory-Based Name Mapping From a User Object
How to Remove a Directory-Based Name Mapping From a Group Object
Managing Directory-Based Identity Mapping by Using Identity Management for UNIX (Task Map)
How to Enable Identity Management for UNIX Support
Managing Rule-Based Identity Mapping for Users and Groups (Task Map)
How to Add a User Mapping Rule
How to Add a Group Mapping Rule
How to Import User Mappings From a Rule-Mapping File
How to Show a Mapping for a Particular Identity
How to Show All Established Mappings
How to Remove a User Mapping Rule
How to Remove a Group Mapping Rule
Troubleshooting the Identity Mapping Service
Viewing Identity Mapping Service Property Settings
Saving and Restoring Name-Based Mapping Rules
Viewing Details About Mappings
Debugging the Identity Mapping Service
3. Setting Up a Oracle Solaris SMB Server to Manage and Share Files
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.
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.
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:
Use the Windows Server Manager to install IDMU on the Active Directory domain controller.
Use the UNIX Attributes tab in the Active Directory Users and Computers tool to specify UIDs and GIDs for your users.
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.
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.
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.
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