JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris SMB and Windows Interoperability Administration Guide     Oracle Solaris 11 Express 11/10
search filter icon
search icon

Document Information

Preface

1.  Windows Interoperability (Overview)

2.  Identity Mapping Administration (Tasks)

Mapping User and Group Identities

Creating Your Identity Mapping Strategy

Mapping Well-Known Account Names

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 Mappings

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

3.  Solaris SMB Server Administration (Tasks)

4.  Solaris SMB Client Administration (Tasks)

Glossary

Index

Managing Directory-Based Name Mapping for Users and Groups (Task Map)

The following table points to the tasks that you can use to manage directory-based identity mapping for the Solaris SMB server in a Windows environment.

These tasks use the idmap(1M) command to manage identity mapping.

Task
Description
For Instructions
Extend the Active Directory (AD) schema with user and group name attributes.
This procedure describes how to extend the AD schema and populate the user and group objects with UNIX user and group name information.
Extend the native LDAP schema with user and group name attributes.
This procedure describes how to extend the native LDAP schema and populate the user and group objects with Windows user and group name information.
Configure directory-based name mapping.
Use this procedure to enable directory-based mapping. This procedure also informs the idmap service about the new AD schema attributes that are used by the user and group objects.
Add a directory-based name mapping to a user object.
Use this procedure to add a directory-based name mapping to a user object in AD or native LDAP.
Add a directory-based name mapping to a group object.
Use this procedure to add a directory-based name mapping to a group object in AD or native LDAP.
Remove a directory-based name mapping from a user object.
Use this procedure to remove a directory-based name mapping from a user object in AD or native LDAP.
Remove a directory-based name mapping from a group object.
Use this procedure to remove a directory-based name mapping from a group object in AD or native LDAP.

For more information about user and group identities, see Mapping User and Group Identities.

For more information about how to determine your identity mapping strategy, see Creating Your Identity Mapping Strategy.


Note - In a cluster configuration, changes made to user maps and to group maps on one server are immediately propagated to the other server.


How to Extend the Active Directory Schema, and User and Group Entries

This procedure shows how to extend the AD schema and populate the user and group objects with the associated Oracle Solaris names.


Note - Perform this task before enabling directory-based mapping on your Oracle Solaris system.


  1. (Optional) Extend the AD schema to add the new UNIX user and group attributes.

    Note - If you do not want to extend the AD schema, you can use an existing AD schema attribute to store UNIX user and group name information. For instance, if you already have schema that is comparable to what is described in Example 2-1, you can use your attributes instead of creating new ones.


    1. Create an LDAP Data Interchange Format (LDIF) file to describe the AD schema changes.

      For sample LDIF file contents, see Example 2-1. Also see Extending Your Active Directory Schema in Windows Server 2003 R2 and Step-by-Step Guide to Using Active Directory Schema and Display Specifiers on the Microsoft technet web site.

    2. Use the ldifde tool to load the schema changes into AD from the Windows server.
      C:\> ldifde -v -i -f input-file
  2. Use the ldapmodify command to populate the AD user and group objects with the new attributes and their values.

    You can also use the idmap set-namemap command to populate user and group objects. See How to Add a Directory-Based Name Mapping to a User Object and How to Add a Directory-Based Name Mapping to a Group Object.

    You can also use any of the Windows AD utilities to populate these objects.

    1. Create an LDIF file to record the updates to the AD user and group objects.

      See a sample LDIF file in Example 2-2. For more information about the LDIF file format, see RFC 2849.

    2. Use the kinit command to obtain a Kerberos ticket-granting ticket (TGT) for a privileged AD principal.

      This principal will be used by the ldapmodify command to update the AD objects described in the file you created in the previous substep.

      For example:

      $ kinit Administrator
      Password for Administrator@EXAMPLE.COM: 
    3. Use the ldapmodify command to update the user objects on the AD server.
      $ ldapmodify -h AD-server-name -o mech=gssapi -o authzid='' -f input-file

Example 2-1 Extending the AD Schema

The following LDIF example file, ad_namemap_schema.ldif, describes the AD schema changes:

dn: CN=unixUserName, CN=Schema, CN=Configuration, DC=example, DC=com
changetype: add
attributeID: 1.3.6.1.4.1.42.2.27.5.1.60
attributeSyntax: 2.5.5.3
isSingleValued: TRUE
searchFlags: 1
lDAPDisplayName: unixUserName
adminDescription: This attribute contains the object's UNIX username
objectClass: attributeSchema
oMSyntax: 27

dn: CN=unixGroupName, CN=Schema, CN=Configuration, DC=example, DC=com
changetype: add
attributeID: 1.3.6.1.4.1.42.2.27.5.1.61
attributeSyntax: 2.5.5.3
isSingleValued: TRUE
searchFlags: 1
lDAPDisplayName: unixGroupName
adminDescription: This attribute contains the object's UNIX groupname
objectClass: attributeSchema
oMSyntax: 27

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=unixNameInfo, CN=Schema, CN=Configuration, DC=example, DC=com
changetype: add
governsID: 1.3.6.1.4.1.42.2.27.5.2.15
lDAPDisplayName: unixNameInfo
adminDescription: Auxiliary class to store UNIX name info in AD
mayContain: unixUserName
mayContain: unixGroupName
objectClass: classSchema
objectClassCategory: 3
subClassOf: top

Use the ldifde tool to load the schema changes into AD from the Windows server:

C:\> ldifde -v -i -f ad_namemap_schema.ldif

Example 2-2 Populating AD User and Group Objects

The following example has Windows users terry, cal, and dana stored in Active Directory. These Windows users are associated with the Oracle Solaris users tmw, crj, and dab, respectively.

This example shows how to add the Oracle Solaris user names to the appropriate user objects in AD by using the ldapmodify command.

First, create an input file, updateUsers, that associates the Windows names with the Oracle Solaris names:

$ cat updateUsers
dn: CN=Terry Walters,CN=Users,DC=example,DC=com
changetype: modify
add: unixUserName
unixUserName: tmw

dn: CN=Cal Jamieson,CN=Users,DC=example,DC=com
changetype: modify
add: unixUserName
unixUserName: crj

dn: CN=Dana Bloom,CN=Users,DC=example,DC=com
changetype: modify
add: unixUserName
unixUserName: dab
$

Next, use the kinit command to obtain a TGT for a privileged principal:

$ kinit Administrator
Password for Administrator@EXAMPLE.COM: 

Finally, run the ldapmodify command to update the user objects on the AD server, saturn:

$ ldapmodify -h saturn -o mech=gssapi -o authzid='' -f updateUsers

How to Extend the Native LDAP Schema, and User and Group Entries

This procedure shows how to extend the native LDAP schema and populate the user and group objects with the associated Windows names.


Note - Perform this task before enabling directory-based mapping on your Oracle Solaris system.


  1. (Optional) Extend the native LDAP schema to add the new Windows user and group attributes.

    Note - If you do not want to extend the native LDAP schema, you can use an existing native LDAP schema attribute to store Windows user and group name information. For instance, if you already have schema that is comparable to what is described in Example 2-3, you can use your attributes instead of creating new ones.


    1. Create an LDAP Data Interchange Format (LDIF) file to describe the native LDAP schema changes.

      For sample LDIF file contents, see Example 2-3.

    2. Use the ldapmodify tool to load the schema changes into native LDAP.
      $ ldapmodify -D cn=admin -w p -f input-file
  2. Use the ldapmodify command to populate the native LDAP user and group objects with the new attributes and their values.

    You can use the idmap set-namemap command to populate user and group objects. See How to Add a Directory-Based Name Mapping to a User Object and How to Add a Directory-Based Name Mapping to a Group Object.

    1. Create an LDIF file to record the updates to the native LDAP user and group objects.

      See a sample LDIF file in Example 2-4. For more information about the LDIF file format, see RFC 2849.

    2. Use the ldapmodify command to update the user objects on the native LDAP server.
      $ ldapmodify -h LDAP-server-name -o mech=gssapi -o authzid='' -f input-file

Example 2-3 Extending the Native LDAP Schema

The following LDIF example file, nldap_namemap_schema.ldif, describes the native LDAP schema changes:

dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.42.2.27.5.1.62
   NAME 'winAccountName'
   DESC 'Windows user or group name corresponding to a Unix user or group'
   EQUALITY caseIgnoreMatch
   SUBSTRINGS caseIgnoreSubstringsMatch
   ORDERING caseIgnoreOrderingMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
add: objectClasses
objectClasses: ( 1.3.6.1.4.1.42.2.27.5.2.16
   NAME 'winAccount'
   DESC 'Auxiliary class to store Windows name mappings in Unix user/group objects'
   SUP top
   AUXILIARY
   MAY winAccountName )

Use the ldapmodify tool to load the schema changes into native LDAP:

$ ldapmodify -D cn=admin -w - -f f nldap_namemap_schema.ldif
Enter bind password:
modifying entry cn=schema

Example 2-4 Populating Native LDAP User and Group Objects

The following example has Oracle Solaris users tmw, crj, and dab stored in native LDAP. These Oracle Solaris users are associated with the Windows users terry, cal, and dana, respectively, all in the domain example.com.

This example shows how to add the Windows user names to the appropriate user objects in native LDAP by using the ldapmodify command.

First, create an input file, updateUsers, that associates the Oracle Solaris names with the Windows names:

$ cat updateUsers
dn: uid=tmw,ou=passwd,dc=example,dc=com
changetype: modify
add: winAccountName
winAccountName: terry@example.com

dn: uid=crj,ou=passwd,dc=example,dc=com
changetype: modify
add: winAccountame
winAccountame: cal@example.com

dn: uid=dab,ou=passwd,dc=example,dc=com
changetype: modify
add: winAccountame
winAccountame: dana@example.com
$

Then, run the ldapmodify command to update the user objects on the native LDAP server, neptune:

$ ldapmodify -h neptune -o mech=gssapi -o authzid='' -f updateUsers

How to Configure Directory-Based Mapping

Before You Begin

Before you can enable directory-based mapping on your Oracle Solaris system, you must extend the AD schema, the native LDAP schema, or both, and populate the user and group objects with the associated Oracle Solaris names. 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.

  1. Enable directory-based mapping.
    # svccfg -s svc:/system/idmap setprop config/directory_based_mapping=astring: name

    The directory_based_mapping property controls support for identity mapping that uses data stored in a directory service. The value of the directory_based_mapping property can be one of the following:

    • none Disables directory-based mapping.

    • name Enables name-based mapping by using the config/ad_unixuser_attr, config/ad_unixgroup_attr, and config/nldap_winname_attr properties. These properties are described in the idmap(1M) man page.

    • idmu Enables mapping by using Identity Management for UNIX (IDMU). IDMU is a Windows component that permits the administrator to specify a UNIX user ID for each Windows user, and then have the Windows identity mapped to the corresponding UNIX identity. Note that only IDMU data is used from the domain of which the Oracle Solaris system is a member.

  2. Inform the idmap service about the new user and group attributes.

    Note - To fully enable directory-based mapping, you must specify values for the following properties depending on the directory service or services you plan to use:

    • config/ad_unixuser_attr

    • config/ad_unixgroup_attr

    • config/nldap_winname_attr

    These properties do not have default values. If the properties are not set, directory-based mapping is effectively disabled for the corresponding naming service.


    In an environment that stores user and group name information in both Active Directory and native LDAP, perform the steps for each naming service.

    • For Active Directory, inform the idmap service about the new Active Directory UNIX user and group attributes.
      # svccfg -s svc:/system/idmap setprop config/ad_unixuser_attr=astring: \ attribute-name
      # svccfg -s svc:/system/idmap setprop config/ad_unixgroup_attr=astring: \ attribute-name

      attribute-name is the attribute name you choose for the UNIX user or group name to be stored in AD.

      For example, the following specifies the unixGroupName and unixUserName attribute names for the UNIX group and user names, respectively:

      # svccfg -s svc:/system/idmap setprop config/ad_unixgroup_attr=astring: \ unixGroupName
      # svccfg -s svc:/system/idmap setprop config/ad_unixuser_attr=astring: \ unixUserName
    • For native LDAP, inform the idmap service about the new native LDAP Windows name attribute.
      # svccfg -s svc:/system/idmap setprop \ config/nldap_winname_attr=astring: attribute-name

      attribute-name is the attribute name you choose for the Windows name to be stored in native LDAP.

      For example, the following specifies the winAccountName attribute name for the Windows name:

      # svccfg -s svc:/system/idmap setprop \ config/nldap_winname_attr=astring: winAccountName
  3. Refresh the identity mapping service.
    # svcadm refresh svc:/system/idmap

How to Add a Directory-Based Name Mapping to a User Object

This procedure shows how to perform the following directory-based name mapping:

For more information about the idmap set-namemap command and its options, see the idmap(1M) man page.

  1. Become an administrator, obtain the solaris.admin.idmap.rules RBAC authorization, or use the Idmap Service Management RBAC profile.

    For more information, see How to Obtain Administrative Rights in System Administration Guide: Security Services.

  2. Determine whether to augment a user object in AD or in the native LDAP service.
    • To augment the Windows user object in AD, type:
      # idmap set-namemap winuser:username@domain-name unixuser:username

      For example, the following command maps Windows user danab@example.com to Oracle Solaris user dana by adding the Oracle Solaris name to the AD object for danab@example.com:

      # idmap set-namemap winuser:danab@example.com unixuser:dana
    • To augment the Oracle Solaris user object in native LDAP, type:
      # idmap set-namemap unixuser:username winuser:username@domain-name

      For example, the following command maps Oracle Solaris user dana to Windows user danab@example.com by adding the Windows name to the native LDAP object for dana:

      # idmap set-namemap unixuser:dana winuser:danab@example.com

How to Add a Directory-Based Name Mapping to a Group Object

This procedure shows how to perform the following directory-based name mapping:

  1. Become an administrator, obtain the solaris.admin.idmap.rules RBAC authorization, or use the Idmap Service Management RBAC profile.

    For more information, see How to Obtain Administrative Rights in System Administration Guide: Security Services.

  2. Determine whether to augment a group object in AD or in the native LDAP service.
    • To augment the Windows group object in AD, type:
      # idmap set-namemap wingroup:group-name@domain-name unixgroup:group-name

      For example, the following command maps Windows group salesgrp@example.com to Oracle Solaris group sales by adding the Oracle Solaris name to the AD object for salesgrp@example.com:

      # idmap set-namemap wingroup:salesgrp@example.com unixgroup:sales
    • To augment the Oracle Solaris group object in native LDAP, type:
      # idmap set-namemap unixgroup:group-name wingroup:group-name@domain-name

      For example, the following command maps Oracle Solaris group sales to Windows group salesgrp@example.com by adding the Windows name to the native LDAP object for sales:

      # idmap set-namemap unixgroup:sales wingroup:salesgrp@example.com

How to Remove a Directory-Based Name Mapping From a User Object

  1. Become an administrator, obtain the solaris.admin.idmap.rules RBAC authorization, or use the Idmap Service Management RBAC profile.

    For more information, see How to Obtain Administrative Rights in System Administration Guide: Security Services.

  2. View the directory-based name mapping information for the specified user.
    # idmap get-namemap username
  3. Remove the user name stored in the user object of AD or native LDAP.
    • Remove the Oracle Solaris name from the AD object for the specified user.
      # idmap unset-namemap winuser:username@domain-name

      For example, the following command removes the Oracle Solaris name from the AD object for Windows user danab@example.com:

      # idmap unset-namemap winuser:danab@example.com
    • Remove the Windows name from the native LDAP object for the specified user.
      # idmap unset-namemap unixuser:username

      For example, the following command removes the Windows name from the native LDAP object for Oracle Solaris user dana:

      # idmap unset-namemap unixuser:dana

How to Remove a Directory-Based Name Mapping From a Group Object

  1. Become an administrator, obtain the solaris.admin.idmap.rules RBAC authorization, or use the Idmap Service Management RBAC profile.

    For more information, see How to Obtain Administrative Rights in System Administration Guide: Security Services.

  2. View the directory-based name mapping information for the specified group.
    # idmap get-namemap group-name
  3. Remove the group name stored in the group object of AD or native LDAP.
    • Remove the Oracle Solaris name from the AD object for the specified group.
      # idmap unset-namemap wingroup:group-name@domain-name

      For example, the following command removes the Oracle Solaris name from the AD object for Windows group salesgrp@example.com:

      # idmap unset-namemap wingroup:salesgrp@example.com
    • Remove the Windows name from the native LDAP object for the specified group.
      # idmap unset-namemap unixgroup:group-name

      For example, the following command removes the Windows name from the native LDAP object for Oracle Solaris group sales:

      # idmap unset-namemap unixgroup:sales