How to fix Portal Access Control settings after LDAP data 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, the data in the Portal database may no longer be current with the data in the LDAP. 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.
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.
Either the attribute value (or attribute itself) in the LDAP that is mapped as the external identifier has changed or the full distinguished name of the user has changed.
Resolving the problem
Before following this procedure, IBM Support strongly recommends backing up your Portal databases.
Step 1: Run XMLaccess with CleanupUsers.xml as input file:
xmlaccess.bat -in CleanupUsers.xml -user wpsadmin -pwd wpsadmin -url http://localhost:10039/wps/config -out c:\invalidusersgroups.xml
./xmlaccess.sh -in CleanupUsers.xml -user wpsadmin -pwd wpsadmin -url http://localhost:10039/wps/config -out /tmp/invalidusersgroups.xml
where CleanupUsers.xml can be found in the PortalServer/doc/xml-samples directory. 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.
NOTE: If you see references to users or groups based on the original out-of-the-box user registry (uid=wpsadmin,o=defaultWIMFileBasedRealm), remove the entries 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/.bat -in invalidusersgroups.xml -user wpsadmin -pwd wpsadmin -url localhost:10039/wps/config -out migration_out.xml
At this point, the access control mappings have been migrated to the current external identifiers used by the users and groups in the LDAP. However, there are still orphaned user and group entries in the tables of the Portal databases that should be removed, which is addressed in next step.
Step 4. (Optional but recommended) Run XMLaccess with <wp_root>/doc/xml-samples/ CleanupUsers.xml as input a second time:
xmlaccess.sh/.bat -in CleanupUsers.xml -user wpsadmin -pwd wpsadmin -url localhost:10039/wps/config -out removeusersgroups.xml
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/.bat -in removeusersgroups.xml -user wpsadmin -pwd wpsadmin -url localhost:10039/wps/config -out cleanedDB_out.xml
NOTE: Ensure that "cleanup-users" is set to invalid in removeusersgroups.xml for this step.
Check cleanedDB_out.xml for any error messages.
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 Portal version Information Center links below depending on the version of your Portal for further details on the MemberFixer tool.
- If the system has been configured for a VMM federated database, application groups may exist in the database which that contain LDAP users. The procedure described above will not clean up the VMM database tables which contain outdated LDAP users. A separate procedure is needed - documented in the WebSphere Application Server Knowledge Center - to cleanup the groups in the VMM database of the stale LDAP users.
- 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 distinguished names are different before and after the LDAP change.
|Organizational Productivity- Portals & Collaboration||WebSphere Portal End of Support Products||AIX, HP-UX, IBM i, Linux, Solaris, Windows, z/OS||7.0, 6.1|
More support for:
Software version: 8.0, 8.5
Operating system(s): AIX, HP-UX, IBM i, Linux, Solaris, Windows, z/OS
Software edition: Enable, Express, Extend, Server
Reference #: 1377025
Modified date: 08 March 2011