However, in certain scenarios in which an LDAP server is changed or users or groups are removed and re-added directly to the LDAP, the external identifiers are no longer the same. Such scenarios cause duplicate users/groups to be created in the Portal database. These duplicates are then used for access control calculations on the Portal server when users log in, while the original user and access control information is considered orphaned.
Symptom
When checking access control settings using the Resource Permission portlet, you may see blank entries or users will no longer be able to view resources to which they previously had access.
Cause
The attribute value (or attribute itself) in the LDAP that is mapped as the external identifier has changed.
Resolving the problem
There are two conditions necessary for the following procedure to work.
(1) The LDAP schema should not be changed, meaning user and group distinguished names remain the same.
(2) Apply the interim fix, PK59896, if running WebSphere Portal 6.0.1.3 or earlier, and PK83289 if running Portal 6.0.1.3. Before following this procedure, IBM Support recommends backing up your Portal databases.
Step 1: Run XMLaccess with CleanupUsers.xml as input file:
xmlaccess.sh -in CleanupUsers.xml -user wpsadmin -pwd wpsadmin -url localhost:10038/wps/config -out invalidusersgroups.xml
where CleanupUsers.xml can be found in directory
Step 2. The decision must be made whether to delete the invalid users and groups using this step or a later step. We recommend you leave them in the Portal database temporarily.
Make the following changes to the file invalidusersgroups.xml in the "request" tag:
(a) Set "cleanup-users" to false. Add "migrate-users" and set it to true.
(b) Make sure the schema version shown in the XML file is "PortalConfig_6.0.1_1.xsd" or later. invalidusersgroups.xml should now look like this:
Example:
(c) If the schema version is not exactly "PortalConfig_6.0.1_1.xsd" or later, open the file wp.xml.jar (in directory
NOTE: If you see references to users or groups based on the original out-of-the-box user registry (uid=wpsadmin,o=default organization), remove the references from the XML file or they could potentially cause the next step to fail.
Step 3. Run XMLaccess with invalidusersgroups.xml as the input file:
xmlaccess.sh -in invalidusersgroups.xml -user wpsadmin -pwd wpsadmin -url localhost:10038/wps/config -out migration_out.xml
At this point, the access control mappings have been migrated to the current external identifier used by the users and groups in the LDAP. However, there are still orphaned user and group entries in the USER_DESC table of the Portal database that should be removed, which is addressed in next step.
Step 4. (Optional but recommended) Run XMLaccess with
xmlaccess.sh -in CleanupUsers.xml -user wpsadmin -pwd wpsadmin -url localhost:10038/wps/config -out removeusersgroups.xml
where removeusersgroups.xml is essentially the same as invalidusersgroups.xml which contains the set of orphaned user and group references in the Portal database.
Step 5. (Optional but recommended) Run XMLaccess with removeusersgroups.xml as input to delete the orphaned users and groups:
xmlaccess.sh -in removeusersgroups.xml -user wpsadmin -pwd wpsadmin -url localhost:10038/wps/config -out cleanedDB_out.xml
NOTE: Ensure that "cleanup-users" is set to true (the default setting) in removeusersgroups.xml for this step.
Step 6. Verify the Portal access control settings by logging into the Portal server and confirming that users can view the resources to which they have permission.
If you have WCM content, you should run the WCM MemberFixer tool. Before running MemberFixer, complete Steps 4 and 5. Reference the appropriate 6.0 or 6.1 Information Center link below depending on the version of your Portal for further details on the MemberFixer tool.
NOTE: If the LDAP user or group DNs are different after the LDAP change, the above procedure will not work. Contact IBM Support for further details if your user and/or group domain names will change.
