WebSphere Portal leverages the VMM (Virtual Member Manager) component to access the configured user registries. VMM is part of the WebSphere Application Server. For authentication, WebSphere Application Server allows configuration of either the standalone or federated option - the federated option also uses VMM for that purpose. Our recommendation is to use the federated option since with that, one configuration is sufficient and caches can be used for authentication by WebSphere Application Server and user and group lookup by Portal both.
main profile repository that is used with Virtual Member Manager needs to have
an attribute whose value is unique, static, and never reused for any member entry. In VMM,
this attribute is called extId. By default when configuring a LDAP, VMM will leverage the default unique ID from the LDAP (i.e. objectGUID in Microsoft Active Directory) as extId. WebSphere Portal and Web Content Manager use the extId to map permissions (roles), page and portlet customizations, private pages, tags and ratings, web content manager content ownership, or other artifacts to the extId of groups or users. The value is different between different LDAPs - so even if the "same" group or user exists in a staging and production LDAP, they can have different extIds. Syndication is a process that transfers WCM artifacts between systems. If those systems have different LDAPs configured, the mapping of the artifact will no longer function after the item has been syndicated. To fix this it is possible to run the member fixer task. With Web Content Manager 8 it is possible to configure member fixer to run as part of syndication.
If the extId chosen by default is not unique or if there are issues with member fixer, an option is to change the mapping of the extId to another value that is identical between multiple LDAPs but still unique and static. An ideal value can be the distinguished name value in the LDAP since it is identical between different LDAPs for the same group or user. The following steps describe how to change the configured extId. Note, ideally the steps should be performed directly after configuring the LDAP in the environment. If the change is made at a later point in time, when artifacts in Portal and WCM are already mapped to the extId values, it is non-trivial to change the mappings. Also consider that in your environment the distinguished name might be changed in the LDAP by some process and in that case the mapping in Portal / WCM would be lost too.
In a cluster the VMM configuration files exist in multiple locations - in the deployment manager profile and in the profile of each JVM belonging to the cell / cluster. For a standalone system, only the VMM config files in the single profile need to be adjusted.
It is important to take a backup of all involved servers' file systems and Portal databases before proceeding. In case syndication is used after configuring the steps, you might want to consider the same backup for the subscriber.
1. Stop all WebSphere Portal and Deployment Manager and nodeagent JVMs involved.
2. In all involved profiles, edit the file <profile>/config/cells/<cellname>/wim/config/wimconfig.xml making the following adjustments:
Find the tag <config:attributeConfiguration> for the LDAP in question and in there add the following tag before the closing </config:attributeConfiguration> tag:
Save the file.
3. Restart the involved JVMs - in a cell/cluster starting with the Deployment Manager, nodeagents and then WebSphere Portal JVMs.
The default unique identifiers for the supported LDAP types are:
IBM Tivoli Directory Server: ibm-entryUUID
Microsoft Active Directory: objectGUID
Novell eDirectory: GUID
IBM Domino Server: dominoUNID
SunOne Directory Server: nsuniqueId