+

Search Tips   |   Advanced Search


Map VMM attributes to LDAP user attributes

The Domino and Extended Products Portlets rely on a predefined set of Virtual Member Manager (VMM) user and group attributes to function properly, while your LDAP server may use a different set of predefined user and group attributes. If a portal attribute is available under a different name on the LDAP server, you can map the portal attribute to the corresponding LDAP attribute. Portal attributes that do not correspond to an LDAP attribute should be flagged as unsupported.

The Domino and Extended Products Portlets use these attributes:

Mapping the attributes below ensures that users see the appropriate values when People Finder displays an individual's User Profile, or when they search by attribute (for example, to find all users who have the same preferred language or whose telephone number starts with the same area code).

# name of the portal attribute
standalone.ldap.attributes.mapping.portalName=ibm-primaryEmail, ibm-jobTitle, stateOrProvinceName, countryName, localityName, street, employeeNumber, roomNumber, preferredLanguage, labeledURI, ibm-personalTitle

# name of the LDAP attribute
standalone.ldap.attributes.mapping.ldapName=mail, title, st, c, l, OfficeStreetAddress, EmployeeID, physicalDeliveryOfficeName, preferredLanguage, url, personalTitle

For a federated LDAP user registry instead of standalone LDAP, the parameter names are federated.ldap.attributes.mapping.portalName and federated.ldap.attributes.mapping.ldapName. For detailed instructions, see Adapting the attribute configuration under the section of the contents that explains how to configure WebSphere Portal to use a user registry on a particular platform.

For example, if the portal server is running on Windows, locate the topic called Configuring WebSphere Portal to use a user registry on Windows and from there, navigate to Adapting the attribute configuration.


Issue

Attempting to perform updates against certain attributes that are inherently defined (per specification) as multi-valued in the LDAP...

These attributes are defined by default in Portal (presumably as single value). When attempting to update (setAttributes) with a new value, the value is added so that the original value exists plus the new value. When attempting to update (setAttributes) an exception is thrown indicating that the attribute already exists. Attempts to remove the attribute (removeAttributes) do not result in any exceptions, but also do not remove the attribute.

Answer

The problem was traced to two specific attributes...

Using alternate names (from the attribute properties) solved the problem...


Parent topic:

Collaboration and Messaging portlets


Related tasks


Edit the CSEnvironment.properties file