openSolaris 2008 - Managing Directory-Based Identity Mapping for Users and Groups (Task Map)

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.

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.	How to Extend the Active Directory Schema, and User and Group Entries
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.	How to Extend the Native LDAP Schema, and User and Group Entries
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.	How to Configure Directory-Based Mapping
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.	How to Add a Directory-Based Name Mapping to a User Object
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.	How to Add a Directory-Based Name Mapping to a Group Object
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.	How to Remove a Directory-Based Name Mapping From a User Object
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.	How to Remove a Directory-Based Name Mapping From a Group Object

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.
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
```
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.
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 [email protected]: 
```
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 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 [email protected]:

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.
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
```
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 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: [email protected]

dn: uid=crj,ou=passwd,dc=example,dc=com
changetype: modify
add: winAccountame
winAccountame: [email protected]

dn: uid=dab,ou=passwd,dc=example,dc=com
changetype: modify
add: winAccountame
winAccountame: [email protected]
$

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:
- 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
```

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 [email protected] to Solaris user dana by adding the Solaris name to the AD object for [email protected]:
```
# idmap set-namemap winuser:[email protected] 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 [email protected] by adding the Windows name to the native LDAP object for dana:
```
# idmap set-namemap unixuser:dana winuser:[email protected]
```

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 [email protected] to Solaris group sales by adding the Solaris name to the AD object for [email protected]:
```
# idmap set-namemap wingroup:[email protected] 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 [email protected] by adding the Windows name to the native LDAP object for sales:
```
# idmap set-namemap unixgroup:sales wingroup:[email protected]
```

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 [email protected]:
```
# idmap unset-namemap winuser:[email protected]
```
- 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 [email protected]:
```
# idmap unset-namemap wingroup:[email protected]
```
- 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
```