Sunday, July 19, 2009

How to fix Portal Access Control settings after user/group external identifiers have changed

The access controls on resources in IBM WebSphere Portal are linked to external identifiers associated with each user/group stored in LDAP. The requirements for such an external identifier includes that it be static and unique.

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 /doc/xml-samples. This step generates a set of invalid users and groups in file invalidusersgroups.xml.


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 /shared/app/ if version 6.0.x, or /base/wp.xml/shared/app if 6.1). Verify the schema version file "PortalConfig_6.0.1_1.xsd" is included in wp.xml.jar, and correct the schema in the request tag to 6.0.1_1 or later.
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 /doc/xml-samples/CleanupUsers.xml as input a second time:

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.