Detailed steps for mapping LDAP attributes in WebSphere Portal 6.1

Technote (FAQ)   Question How can you map attributes in IBM WebSphere Portal 6.1? It appears that there are unmapped attributes by default when initially configuring WebSphere Portal to an LDAP. WebSphere Portal Information Center does not provide detailed steps to explain the process.     Answer The following step-by-step instructions address attribute mapping in WebSphere Portal and should be considered as supplemental information to the WebSphere Portal Information Center page, Mapping attributes. The instructions in this technote use a stand-alone security setup on Linux with Tivoli Directory Server as the LDAP. However, they can be adjusted to address other LDAPs or operating systems, and can be modified for federated repository setups by using the appropriate properties as outlined on the Information Center page. ------------------ 1. Run "ldapsearch" from the Linux console to determine available attributes in LDAP. If you do not have an ldapsearch tool, refer to the related information at the bottom of this technote for a link to a command-line tool. Command: ldapsearch -h <ldap_hostname> -x -D uid=wpsadmin,cn=users,dc=raleigh,dc=ibm,dc=ibm -w mypassword -b cn=users,dc=raleigh,dc=ibm,dc=com uid=wpsadmin Results: dn: uid=wpsadmin,cn=users,dc=raleigh,dc=ibm,dc=com objectclass: organizationalPerson objectclass: person objectclass: top objectclass: inetOrgPerson objectclass: ibm-appuuidaux uid: wpsadmin userpassword:: e1NIQX0zxMQFlWTsNZy1siIH9y/6FDSfGw== sn: admin givenName: wps cn: wps admin ibm-appuuid: f1943b30-dc32-11da-b62a-832d445b4568 mail: wpsadmin@us.ibm.com preferredlanguage: en Command: ldapsearch -h wshasb.rtp.raleigh.ibm.com -x -D uid=wpsadmin,cn=users,dc=raleigh,dc=ibm,dc=com -w mypassword -b dc=raleigh,dc=ibm,dc=com cn=wpsadmins Results: dn: cn=wpsadmins,cn=groups,dc=raleigh,dc=ibm,dc=com objectclass: groupOfUniqueNames objectclass: top cn: wpsadmins uniquemember: uid=wpsadmin,cn=users,dc=raleigh,dc=ibm,dc=com uniquemember: uid=jeff,cn=users,dc=raleigh,dc=ibm,dc=com ------------------ 2. Run ./ConfigEngine.sh wp-query-attribute-config to produce output similar to the following in the <wp_profile>/ConfigEngine/log/Configtrace.log: [wplc-validate-ldap-attribute-config] Possible problems for PersonAccount: [wplc-validate-ldap-attribute-config] The following attribues are defined in Portal but not in LDAP - You should either flag them as unsupported or define an attribute mapping: [wplc-validate-ldap-attribute-config] [groups, identifier, ibm-jobTitle, entitlementInfo, realm, viewIdentifiers, certificate, stateOrProvinceName, createTimestamp, modifyTimestamp, ibm-primaryEmail, children, parent, c, partyRoles, principalName, countryName, localityName] and then use the above information to modify the wkplc.properties file: standalone.ldap.attributes.nonSupported=groups, identifier, ibm-jobTitle, entitlementInfo, realm, viewIdentifiers, certificate, stateOrProvinceName, createTimestamp, modifyTimestamp, children, parent, c, partyRoles, principalName, countryName, localityName standalone.ldap.attributes.mapping.portalName=ibm-primaryEmail standalone.ldap.attributes.mapping.ldapName=mail ------------------ Additional output in the ConfigTrace.log: [wplc-validate-ldap-attribute-config] The following attributes are flagged as required in LDAP but not in Portal - You should flag them as required in Portal, too: [wplc-validate-ldap-attribute-config] [sn, cn] Modifiy the wkplc.properties file accordingly: user.attributes.required=sn,cn ----------------- Additional output in the ConfigTrace.log: [wplc-validate-ldap-attribute-config] FYI: The following attributes have a diffenrent type in Portal and in LDAP - No action is required: [wplc-validate-ldap-attribute-config] jpegPhoto: Base64Binary <> 1.3.6.1.4.1.1466.115.121.1.5 [wplc-validate-ldap-attribute-config] password: Base64Binary <> 1.3.6.1.4.1.1466.115.121.1.5 [wplc-validate-ldap-attribute-config] seeAlso: String <> 1.3.6.1.4.1.1466.115.121.1.12 No modifications are required in the wkplc.properties file. ------------------- Additional output in the ConfigTrace.log: [wplc-validate-ldap-attribute-config] Possible problems for Group: [wplc-validate-ldap-attribute-config] The following attribues are defined in Portal but not in LDAP - You should either flag them as unsupported or define an attribute mapping:[wplc-validate-ldap-attribute-config] [modifyTimestamp, groups, members, identifier, displayName, parent, children, entitlementInfo, partyRoles, viewIdentifiers, createTimestamp] Modify the wkplc.properties file accordingly: standalone.ldap.attributes.nonSupported=groups, identifier, ibm-jobTitle, entitlementInfo, realm, viewIdentifiers, certificate, stateOrProvinceName, createTimestamp, modifyTimestamp, ibm-primaryEmail, children, parent, c, partyRoles, principalName, countryName, localityName, modifyTimestamp, groups, identifier, displayName, parent, children, entitlementInfo, partyRoles, viewIdentifiers, createTimestamp standalone.ldap.attributes.mapping.ldapName=ibm-primaryEmail,members standalone.ldap.attributes.mapping.portalName=mail,uniquemember ----------------- Additional output in the ConfigTrace.log: [wplc-validate-ldap-attribute-config] The following attributes are flagged as required in LDAP but not in Portal - You should flag them as required in Portal, too: [wplc-validate-ldap-attribute-config] [] No modifications are required in the wkplc.properties file. ----------------- NOTE: Leave the following line unchanged in the wkplc.properties file: standalone.ldap.attributes.mapping.entityTypes=PersonAccount,Group ----------------- 3. Run ./ConfigEngine.sh wp-update-standalone-ldap-attribute-config and ensure you receive a BUILD SUCCESSFUL message. 4. Run ./ConfigEngine.sh wp-query-attribute-config and ensure you receive a BUILD SUCCESSFUL message. 5. Once all required attributes are mapped, run the following tasks to propagate the security changes in a standalone (non-clustered) environment: a) ./stopServer.sh server1 -username admin_userid -password admin_password, from the wp_profile_root/bin directory. b) ./stopServer.sh WebSphere_Portal -username admin_userid -password admin_password, from the wp_profile_root/bin directory. c) ./startServer.sh server1, from the wp_profile_root/bin directory. d) ./startServer.sh WebSphere_Portal, from the wp_profile_root/bin directory. Note that if VMM is not already aware of the attribute (e.g. a custom attribute), you will need to add the attribute before you can map it. Refer to the solution in this technote: http://www.ibm.com/support/docview.wss?rs=688&ca=portall2&uid=swg21365605     Related information Mapping Attributes Using ldapsearch to debug LDAP configuration problems Exception related to attributes