Manually map Profile DB fields to LDAP fields

Manually map Profile DB fields to LDAP fields

Overview

To populate the Profiles database with data from LDAP, map the content of the fields in the database to the fields in the LDAP directory.
To map fields between the Profiles database, and the LDAP directory, edit...
map_dbrepos_from_source.properties

To see mapping options, check profiles_functions.js. We can add our own functions if necessary.
Running the Profiles population wizard in interactive mode generates two property files...

Wizards/TDIPopulation/tdisetting.properties
Wizards/TDIPopulation/mappings.properties

Map fields

Install LDAP viewer software, such as Apache Directory Studio, on your client PC.

Create the TDI Solutions directory. On the system hosting TDI...
mkdir TDI_HOME/TDISOL
cp $CNX_INSTALL_MEDIA/TDISOL/tdisol.tar TDI_HOME/TDISOL
cd $TDI_HOME/TDISOL
tar xvf tdisol.tar

This creates a subdirectory ./TDI.

Copy the directory to...
TDI_HOME/jvm/jre/lib/ext

Rename the directory to TDI. This directory becomes the TSI solution directory.
Edit...
$TDI_HOME/TDISOL/TDI/tdienv.sh

...and set...
export TDIPATH=/opt/IBM/TDI/V7.1.1

Edit...
map_dbrepos_from_source.properties

...and set...

1:1 mapping If a field in the Profiles database matches a field in the LDAP, set DB field equal to LDAP property. For example:
bldgId=buildingname

Complex mapping Split content into multiple fields in the Profiles database. Define the function in profiles_functions.js, and wrap the name of the JavaScript function in braces {}. Begin function names with func_. For example:
bldgId={func_map_to_db_bldgId}

Values omitted or set to null are not populated in the database.
The uid, guid, dn, surname, and displayName attributes are always required.
Edit...
$TDI_HOME/TDISOL/TDI/conf/LotusConnections-config/tdi-profile-config.xml

...and set extension attributes, specifying the property's name and mapping from the source....

Parameter Description
extensionId ID of the extension attribute. Required.
sourceKey Name of the attribute from the source. Required.

For example, to add attribute spokenLangs...
<simpleAttribute extensionId="spokenLangs" sourceKey="spokenLang"/>

The formatting between tdi-profiles-config.xml and profiles-config.xmls is compatible, so we can copy and paste configuration information between the files. For the extension to be displayed in the user interface, make modifications in profiles-config.xml.
We can leverage the custom attribute in the Profiles user interface or REST API

Save the changes to tdi-profiles-config.xml.

Write a JavaScript function that combines different attributes from the LDAP directory to map a customized extension attribute for the Profiles database:

Add the extension attribute function definition in the map_dbrepos_from_source.properties file, using the following format:

extattr.spokenLangs={func_map_to_langs}

The extensionAttribute name must match the specified extensionId in the tdi-profiles-config.xml extension attribute definition.

Add a new func_map_to_db_extensionAttribute JavaScript function in...
$TDI_HOME/TDISOL/TDI/profiles_functions.js

Write logic for the function that specifies the new extension attribute mapping.

Repeat these steps for each JavaScript function.

What to do next

The properties in map_dbrepos_from_source.properties have the default values defined in the following table. Many of them are null. You must determine which LDAP properties to map to the database fields and edit this file to specify values that apply to your configuration. Any values that you omit or set to null are not populated in the database.
See Attribute mapping for Profiles for a table of additional attribute mapping field values.

TDI property LDAP attribute mapping Notes
alternateLastname null

bldgId null

blogUrl null

calendarUrl null

countryCode c

courtesyTitle null

deptNumber null

description null

displayName cn Required.
distinguishedName $dn Required. Default is TDI distinguishedName mapped to the $dn function, This executes a DN lookup based on the directory type.
email
mail
employeeNumber employeenumber

employeeTypeCode employeetype

experience null

faxNumber facsimiletelephonenumber

floor null

freeBusyUrl null

givenName givenName

givenNames gn

groupwareEmail null

guid See below Required
ipTelephoneNumber null
isManager null

jobResp null

loginId See below

logins null

managerUid $manager_uid Represent UID lookup of the manager using the Distinguished Name in the manager field.
mobileNumber mobile

nativeFirstName null

nativeLastName null

officeName physicaldeliveryofficename

orgId ou

pagerId null

pagerNumber null

pagerServiceProvider null

pagerType null

preferredFirstName null

preferredLanguage preferredlanguage

preferredLastName null

prof_type customer
employee
contractor See the Profile-types topic
secretaryUid null

shift null

surname sn The Search application expects to find this in the Profiles database. Required.
surnames sn

telephoneNumber telephonenumber

timezone null

title null

uid See below Required.
workLocationCode postallocation

Map guid, uid, and loginId

The guid property identifies the global unique ID of a user. This property's value is created by the LDAP directory, and is unique, complex, and never changes. It is essential in that it maps each user's IBM Connections data to their User ID when using the Profiles database as the user repository. The mapping of the guid property must be handled differently depending on the type of LDAP directory that we are using:

Microsoft Active Directory

guid={function_map_from_objectGUID}

We must use a JavaScript function to define the value for Active Directory because objectGUID is stored in Active Directory as a binary value, but is mapped to guid, which is stored as a string in the Profiles database. Also, the samAccountName property used by Active Directory has a 20 character limit, as opposed to the 256 character limit of the other IDs used by IBM Connections.

Lotus Domino

guid={function_map_from_dominoUNID}

IBM Directory Server

guid=ibm-entryUuid

Sun Java System Directory Server

guid=nsUniqueID

Novelle Directory

guid={function_map_from_GUID}

If we edited either...

wimconfig.xml
LotusConnections-config.xml

...to use a custom global unique ID, specify that custom ID here. If we specify an attribute here other than the default, edit the federated directory configuration to match the guid used here. See also...

Specify the global ID attribute for users and groups
Specify a custom ID attribute for users or groups

If the custom ID is different for users and groups, see Configure the custom ID attribute for users or groups.
The uid property defines the unique ID of a user. This property differs from a guid in that it is the organization-specific permanent identifier for a user – often a login ID or some value based on the user's employee code. The uid is a critical field in the Profiles database. By default, this property links a given person's user record back to LDAP data.
Value mapped to uid must..

Be present in every entry that is to be added to the database.
Be unique.
Unique across LDAP directories.
256 characters or fewer in length.

With Active Directory, the available UID field is not not guaranteed to be present for all entries. For mapping, use sAMAccountName as it general does exists for all entries. Other values are acceptable also, as long as they meet requirements.

If we are mapping the uid from an LDAP field, specify the name of the field. However, if parse it from the distinguished name and it is in the DN in the form of uid=value, use the following mapping function:
{func_map_to_db_UID}

Use the isManager and managerUid properties to set up the organizational structure of the organization. The isManager field determines whether the current person is a manager or not. You must assign a Y (Yes) or N (No) value to this property for each entry. Y identifies the person as a manager. The managerUid identifies the UID of the current person's manager. By default, managerUid is mapped to $manager_uid, which represents a lookup of the UID of the manager (using the Distinguished Name contained in the LDAP manager field). If a user's manager information is not contained in the $manager_uid field, you should adjust the mapping accordingly. These two properties work together to identify manager/employee relationships and create a report-to chain out of individual user entries.

If users intend to log into Profiles using a single-valued user name other than the value specified in the uid or email properties, we must map that user name value to the loginId property. To do so, complete the following step:

Set the loginId property in map_dbrepos_from_source.propeties equal to the LDAP property to use as the login ID. For example, to use employeeNumber as the login property, edit the property value :

loginId=employeeNumber

If we have more than one additional login ID (such as with a long and short form user ID) and to allow users to login with either of their login IDs, we can populate multiple additional login IDs by using one of the following settings:

logins=multiValuedLdapAttribute

or

logins={function_to_get_multiple_ldap_values}

See Tivoli Directory Integrator product documentation.
Add profile types.
Connections supports the ability to classify a profile using a
profile type, which allows the application to provide the set of properties for a given profile object.

Parent topic:
Populate peopledb with LDAP info

Related:
Example complex mapping of Profiles data
Choose login values
Customize Profiles
Create a simple profile data model and template customization
Synchronize Profiles and LDAP
Configure the custom ID attribute for users or groups
Specifying a custom ID attribute for users or groups
Update Profiles when changing LDAP directory
Batch files for processing Profiles data
Profile-types
Extension properties in the data model
Customize the Profiles data model

Parameter	Description
extensionId	ID of the extension attribute. Required.
sourceKey	Name of the attribute from the source. Required.

TDI property	LDAP attribute mapping	Notes
alternateLastname	null
bldgId	null
blogUrl	null
calendarUrl	null
countryCode	c
courtesyTitle	null
deptNumber	null
description	null
displayName	cn	Required.
distinguishedName	$dn	Required. Default is TDI distinguishedName mapped to the $dn function, This executes a DN lookup based on the directory type.
email		mail
employeeNumber	employeenumber
employeeTypeCode	employeetype
experience	null
faxNumber	facsimiletelephonenumber
floor	null
freeBusyUrl	null
givenName	givenName
givenNames	gn
groupwareEmail	null
guid	See below	Required
ipTelephoneNumber	null
isManager	null
jobResp	null
loginId	See below
logins	null
managerUid	$manager_uid	Represent UID lookup of the manager using the Distinguished Name in the manager field.
mobileNumber	mobile
nativeFirstName	null
nativeLastName	null
officeName	physicaldeliveryofficename
orgId	ou
pagerId	null
pagerNumber	null
pagerServiceProvider	null
pagerType	null
preferredFirstName	null
preferredLanguage	preferredlanguage
preferredLastName	null
prof_type	customer employee contractor	See the Profile-types topic
secretaryUid	null
shift	null
surname	sn	The Search application expects to find this in the Profiles database. Required.
surnames	sn
telephoneNumber	telephonenumber
timezone	null
title	null
uid	See below	Required.
workLocationCode	postallocation