WebSphere Portal – Change WCM AD Group permissions using memberFixer
this time again WebSphere Portal stuff on this blog 😉
One of our customers uses AD Groups to control access to WCM content. Since there was a change in their AD hierarchy they asked me to replace all old AD Groups with new ones. So far no problem using WebSphere Portal memberFixer. The challenge… it was not possible to first delete the “old” group from AD (prerequisite for memberFixer) and then let memberFixer do the change. I had to find a way to change the group mappings without deleting anything in the AD.
From IBMs official Knowledge Center entry it says:
Anyway I tried to run the memberFixer with the result that no single group was changed…
Then I thought about changing the LDAP search filter and exclude those “old” groups… I was able to do this and VMM did not see those groups anymore. But it seems that memberFixer directly uses the PUMA to access LDAP – there the filter does not seem to work. MemberFixer did not change anything…
From a colleague I got a hint about a more or less hidden command line option “treatAllUsersAsMissing” – described here
Using this option indicates WCM that all users / groups do not exist in the current repository – thus causing a full remapping of users. As the text says this is quite tricky and in a way dangerous to use. If you specify invalidDN=remove then invalid user entries will be removed… invalidDN=update replaces invalid references if an alternative DN has not been found with the administrator account.
I did not use this option as I was sure that memberfixer is able to find the references to all users. For the new groups I created a manual mapping in the MemberFixerModule.properties file.
You should have a full backup of the environment in place.
For me the following steps worked:
1.Create a manual mapping of “old group” –> “new group” in the file D:/IBM/WebSphere/wp_profile/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties
2.disable the WCM user object cache “user.cache.enable=false” in the “WCM WCMConfigService” Resource environment provider
3.Restart the Portal Server
4. I used a LDAP search filter that excludes the old group – even though I`m not sure if this is mandatory…
5.run the WCM memberfixer Task
<wp_profile>/ConfigEngine/ConfigEngine.bat run-wcm-admin-task-member-fixer -DPortalAdminId=wpadmin -DPortalAdminPwd=xxx -DWasUserId=wpadmin -DWasPassword=xxx -Dlibrary=news_content -DaltDn=update -Dfix=true -DmismatchedId=update -DpreserveDates=true -DnoRealmDn=true -DtreatAllUsersAsMissing=true -DsessionTimeout=36000
Furthermore, I had to change the group mapped to the base of the library “manager” role as this gets inherited to all subsequent content.
6. Enable the user object cache again, remove the search filter and restart the Portal Server
That`s all. It might take quite a long time for memberfixer to process all libraries if you have large libraries.