Managing Directory-Based Identity 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 CIFS service in a Windows
environment.
These tasks use the idmap(1M) command to manage identity mapping.
For more information about user and group identities, see Mapping User and Group Identities.
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 Solaris names.
Note - Perform this task before enabling directory-based mapping on your Solaris system.
- (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.
- 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.
- Use the ldifde tool to load the schema changes into AD from
the Windows server.
C:\> ldifde -v -i -f input-file
- Use the ldapmodify command to populate the AD 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.
You can also use any of the Windows AD utilities to populate
these objects.
- 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.
- 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:
- 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 Solaris users tmw,
crj, and dab, respectively.
This example shows how to add the 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 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 Solaris system.
- (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.
- Create an LDAP Data Interchange Format (LDIF) file to describe the native
LDAP schema changes.
For sample LDIF file contents, see Example 2-3.
- Use the ldapmodify tool to load the schema changes into native LDAP.
$ ldapmodify -D cn=admin -w p -f input-file
- 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.
- 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.
- 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 Solaris users tmw, crj, and dab stored in
native LDAP. These Solaris users are associated with the Windows users terry,
cal, and dana, respectively.
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 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 Solaris system, you must
extend the AD schema, the native LDAP schema, or both, and populate
the user and group objects with the associated 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.
- Enable directory-based mapping.
# svccfg -s svc:/system/idmap setprop config/ds_name_mapping_enabled=boolean: true
- 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:
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
How to Add a Directory-Based Name Mapping to a User Object
This procedure shows how to perform the following directory-based name mapping:
Map a Windows user to a Solaris user by adding the Solaris user name to the AD object for the specified Windows user.
Map a Solaris user to a Windows user by adding the Windows user name to the native LDAP object for the specified Solaris user.
For more information about the idmap set-namemap command and its options, see the
idmap(1M) man page.
- Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or
use the “Idmap Service Management” RBAC profile.
Roles contain authorizations and privileged commands. For more information about roles, see
Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- 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 Solaris user
dana by adding the Solaris name to the AD object for danab@example.com:
# idmap set-namemap winuser:danab@example.com unixuser:dana
- To augment the Solaris user object in native LDAP, type:
# idmap set-namemap unixuser:username winuser:username@domain-name
For example, the following command maps 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:
Map a Windows group to a Solaris group by adding the Solaris group name to the AD object for the specified Windows group.
Map a Solaris group to a Windows group by adding the Windows group name to the native LDAP object for the specified Solaris group.
- Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or
use the “Idmap Service Management” RBAC profile.
Roles contain authorizations and privileged commands. For more information about roles, see
Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- 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 Solaris group
sales by adding the Solaris name to the AD object for salesgrp@example.com:
# idmap set-namemap wingroup:salesgrp@example.com unixgroup:sales
- To augment the Solaris group object in native LDAP, type:
# idmap set-namemap unixgroup:group-name wingroup:group-name@domain-name
For example, the following command maps 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
- Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or
use the “Idmap Service Management” RBAC profile.
Roles contain authorizations and privileged commands. For more information about roles, see
Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- View the directory-based name mapping information for the specified user.
# idmap get-namemap username
- Remove the user name stored in the user object of AD or
native LDAP.
- Remove the Solaris name from the AD object for the specified user.
# idmap unset-namemap winuser:username@domain-name
For example, the following command removes the 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 Solaris user dana:
# idmap unset-namemap unixuser:dana
How to Remove a Directory-Based Name Mapping From a Group Object
- Become superuser, assume an equivalent role, obtain the solaris.admin.idmap.rules RBAC authorization, or
use the “Idmap Service Management” RBAC profile.
Roles contain authorizations and privileged commands. For more information about roles, see
Configuring RBAC (Task Map) in System Administration Guide: Security Services. To configure a role with the Primary Administrator profile, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.
- View the directory-based name mapping information for the specified group.
# idmap get-namemap group-name
- Remove the group name stored in the group object of AD or
native LDAP.
- Remove the 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 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 Solaris group sales:
# idmap unset-namemap unixgroup:sales