Use the web content member fixer task

Use the web content member fixer task

Use the member fixer task to check whether users or groups referenced in WCM items have been renamed or deleted, and then...

Fix references to users in item level access settings who have been deleted from the user repository.

Fix references to users in library and item level access settings with an altered structure. For example, an LDAP transfer may have been executed, or the LDAP schema may have changed, or users and groups may have been moved in the LDAP.

In report mode, member fixer will report all the references to members. In fix mode, these references can be fixed, either by replacing them with references to members that exist, or by removing the references. The fix parameter determines whether the member fixer task runs in report or fix mode.
References to members in library items contain...

Distinguished name (DN) of the member
Unique ID for the member

This unique ID is an internal id unique over time. If a member is deleted, and another member is created with the same DN, the two members will have different unique IDs.
When a member given permissions on a library is deleted, the member permissions are entirely removed from the library. Inherited permissions for items in the library will also be removed. Member fixer task cannot be used to update these permissions to a different member.
When an LDAP transfer is carried out, the member permissions on the library are maintained. Member fixer can be run after an LDAP transfer to update or remove these permissions

Enable the member fixer tool

First enable the member fixer by adding the following parameters to the WCM WCMConfigService service using the WAS Console:

connect.businesslogic.module.memberfixer.class=com.aptrix.pluto.security.MemberFixerModule
connect.businesslogic.module.memberfixer.remoteaccess=true
connect.businesslogic.module.memberfixer.autoload=false

Custom Mapping

To update a reference to a member that does not exist with a member that does exist, member mappings can be defined in a custom mapping file. Where the member fixer task does not find a mapping in this file for a member, it will search the user repository for members with the same ID as the member that no longer exists. If such a member is found, it will update the reference with this user or group, or remove the reference, as specified by the altDn parameter. If no such member is found, this member is classified as 'invalid' and will be updated or removed as specified by the invalidDn parameter.
If custom mapping is required, perform the following steps to map the user and group domain names before running the member fixer task:

Edit...
WP_PROFILE/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties

...and set...

cn=contentAuthors,dc=lotus,o=ibm->cn=contentEditors,dc=rational,o=ibm

This format is used to completely replace one DN with another.

cn=[ID],dc=websphere,o=ibm->cn=[ID],dc=tivoli,o=ibm

This format is used to replace part of a DN. This example will change all of the DN except the common name.

We then run the member fixer task using the -DaltDn option as details in the following section.

For an example, see Member Fixer with Syndication

Run the Member Fixer task:
If the query parameter "library" is omitted, the default library configured with the defaultLibrary property in WCM WCMConfigService is used.

Create a report of users or groups referenced in WCM items that need fixing
cd WP_PROFILE/ConfigEngine
./ConfigEngine.sh run-wcm-admin-task-member-fixer -DPortalAdminId=username -DPortalAdminPwd=foo -DWasUserId=username -DWasPassword=foo -Dlibrary="MyLibrary"

An administrator user name and password is not required if PortalAdminId and PortalAdminPwd are set in wkplc.properties.
Before running the member fixer task in fix mode, ensure the report mode indicates the updates will happen as required. A detailed report containing the updates that will be made for each item can be found in...
WP_PROFILE\logs\WebSphere_Portal/SystemOut.log

If the report indicates the update will not happen as required, change the member fixer task parameters, and run the report mode again. Repeat until satisfied. Fixes made by the member fixer may not be easy to undo if incorrect fixes are applied.
If there have been changes to users and groups, update the items that reference them by running...
run-wcm-admin-task-member-fixer

If mismatched member conditions exist, append the specified parameters to the command.

Condition To Correct
Nonexistent users or groups have alternate DNs available.

To update references to nonexistent users or groups with the DN values mapped in MemberFixerModule.properties, append -DaltDn=update.
To remove references to nonexistent users or groups append -DaltDn=remove

Invalid users and groups are listed. The DN does not exist. There is no alternate DN available.

To remove references append -DinvalidDn=remove

To update references for invalid DNs with the portal administrator user DN, append -DinvalidDn=update

Users or groups have been found with mismatched unique IDs.

To fix the mismatched unique IDs append -DmismatchedId=update
To remove mismatched unique IDs append -DmismatchedId=remove
./ConfigEngine.sh run-wcm-admin-task-member-fixer \
                  -DPortalAdminId=username \
                  -DPortalAdminPwd=foo \
                  -DWasUserId=username \
                  -DWasPassword=foo \
                  -Dlibrary="MyLibrary" \
                  -Dfix=true
After the member fixer task runs, review the log output to verify the task ran correctly.
The member fixer task may not be able to save items that fail validation, such as items containing invalid fields. Edit these items to make them valid and then run the member fixer task again.
Run the Member Fixer in a federated security environment

In a federated security environment with multiple realms, we can specify the realm to run the member fixer task on by adding...
-Drealm=realmName

If omitted, the default realm will be used.

The member fixer task will check whether there are any members and groups referenced in items containing any of the base DNs defined for the specified realm and fix these references. References to members can only be updated with references to members in the specified realm.
Additionally, the member fixer task can be used to check whether there are any members and groups referenced in items that are not under any of the base DNs defined for any of the realms in the environment and fix these references. To do this, follow the same steps described for a single realm environment and add...
-DnoRealmDn=true

In a federated security environment with multiple realms, the member fixer task should be run for each realm in turn to make sure that all of the references are fixed.

Preserve dates

We can preserve the last modified date of items updated by the member fixer task by adding -DpreserveDates=true to the command. Otherwise, the last modified date is updated when the member fixer task is run.

Restrict which items types to fix

We can restrict which objects types are processed by appending -DrestrictOn=ItemType to the command. For example:

content
folder
project
style for presentation templates
template for authoring templates
taxonomy
category
SiteArea
Workflow
WorkflowStage
WorkflowAction
Cmpnt for components

We can restrict multiple object types by separating the types with a comma (,). For example, to restrict workflows and workflow stages, we can specify -DrestrictOn=Workflow,WorkflowStage.
If not specified, all object types will be updated.

Run the task for all libraries

We can run this task for all libraries by replacing the option -Dlibrary=libraryName with the option -DallLibraries=true in the command. If neither option is specified, this task will process the default library that has been configured in the WCM WCMConfigService service using the WAS console.

Run the task on a virtual portal

When running this task on a virtual portal add either...

-DVirtualPortalHostName=name
-DVirtualPortalContext=context

Parameters to set for large repositories

To prevent the session timing out before the task has finished, we can append the option...
-DsessionTimeOut=timeOut

This sets the number of seconds in which the task must complete before its session will timeout. The default session timeout is 14,440 seconds, which is 4 hours. For large repositories we should increase this setting. For example, for 10 hours:
-DsessionTimeOut=36000

Examples

These options can be combined when the conditions occur at the same time. For example, if alternate DNs are available for nonexistent users and groups and there are mismatched unique IDs, we would use the following command:
./ConfigEngine.sh run-wcm-admin-task-member-fixer \
                  -DPortalAdminId=username \
                  -DPortalAdminPwd=foo \
                  -DWasUserId=username \
                  -DWasPassword=foo-Dlibrary="MyLibrary" \
                  -Dfix=true \
                  -DaltDn=update \
                  -DmismatchedId=update
If there have been changes to users and groups that are within the specified realm or that are not within any realm, update the items that reference them by entering the following command:
./ConfigEngine.sh run-wcm-admin-task-member-fixer -DPortalAdminId=username -DPortalAdminPwd=foo -DWasUserId=username -DWasPassword=foo -Drealm=MyRealm -Dlibrary="MyLibrary" -Dfix=true -DnoRealmDn=true

Member Fixer with Syndication

Portal v8 managed pages are treated like content. We can syndicate a managed page from one environment to another We no longer have to manually export and import the portal pages from one environment to another using xmlaccess.
With Portal 8 we can schedule the member fixer to be run automatically after each syndication.
For example, we syndicate two pages

Once without configuring member fixer to run after syndication
Once running member fixer after syndication

I created a portal page under...
Home -> Welcome -> TestSyndication

...with default page permission.

Now I updated the subscriber in my delivery server to pick up this change. In the delivery system once the syndication was completed this is how my portal site looked like...

The author, portaladmin, does not exist in the destination system, and is displayed as full dn.
We can use member fixer to update the DN.
After enabling the member fixer to run after each syndication, in the source system I created a new user, SrcUser, and group, SrcGrp, assigned the user and the group to a newly created Portal page TestSyndication2. In the destination server I edit...
WP_PROFILE/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties

...and map the member fixer module for the SrcUser to be replaced with TgtUser, and the SrcGrp group with TgtGrp.
cn=SrcGrp,o=defaultWIMFileBasedRealm -> cn=TgtGrp,dc=demos,dc=ibm,dc=com
uid=SrcUser,o=defaultWIMFileBasedRealm -> cn=TgtUser,dc=demos,dc=ibm,dc=com

After syndication the users and groups who do not exist in the destination syndication are replaced by valid users based on contents of member fixer modules
This saves a lot of manual work when syndicating portal pages from one lower environment to higher environment configured to different user repositories and helps faster time to market.

Use multiple LDAP servers across Web Content Management environments

The member fixer with syndication method should be able to handle multiple LDAPs. Other options include...

Use the same LDAP database for all environments over which WCM is syndicating, e.g federate the multiple LDAPs into one.
Remap the WMM external ID to a unique LDAP attribute on each user record.
Is this still valid for Portal v8.0?
If we have existing data, then run the MemberFixer after implementing this option
Some customers set their WMM external ID to the DN, however if the DN contains the name of the user, then this isn't a good idea as if a user leaves and another joins the company with the same name, then the new user will gain access to the old users information. Periodically running the MemberFixer to remove non-existant users (which is already a best practice) will help mitigate this, however its best if the WMM external ID is set to something unique in the first place, say the users 'employee number'.
Create another common LDAP tree across all LDAP servers that just contains your WCM groups, then use those groups to set your WCM security
The LDAP groups must have the same DN and Ext Id across all servers but can contain different members.
This approach is useful when we must maintain different user groups in different environments under different trees
Set up user access on the portal server with virtual groups like All Users, Anonymous, All Authenticated Portal Users. •For all environments, we can set access on objects using the [All Users] group and anonymous access or any other virtual group because the entry is not stored in the LDAP database. So, to have specific users develop in one WCM installation, but not have access to objects in another installation, we could give access to the virtual group and the security would be retained. If you adopt this solution, we might still want to run the WCM member fixer to clean up the data becuase there will warning messages in the logs. The limitation to this solution is that it only works for virtual users/groups because they are not stored in WMM. Any user/group definition stored in WMM/LDAP will not work.
In this scenario, we should remove any references to non-virtual groups/users in the security preferences of published Sites / Site Areas, Content, Presentation / Authoring Templates, Taxonomies / Categories and Components, including any non-virtual groups/users set via Workflow Stage security, in the authoring environment, to minimise security errors (and thus maxi mise performance) during rendering
Using non-virtual groups/users in the security of non-published items is ok
Ensure that all user/groups and their unique IDs are synchronized across all the LDAP servers that are a part of the WCM syndication scenario. One solution is to export LDAP LDIF files and maintaining LDAP replication across servers.

We can always fix Portal Access Control settings after LDAP data have changed
See also:

Member Fixer with Syndication
Redbook: Multiple LDAP Directories and WCM

Configure Portal to use distinguished name as LDAP unique identifier (extID)

WebSphere Portal leverages the Virtual Member Manager (VMM) component to access the configured user registries. Every profile repository used with VMM 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 as extId. 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

WebSphere Portal and Web Content Manager use the extId to map permissions (roles), page and portlet customizations, private pages, tags and ratings, 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 WCM 8 it is possible to configure member fixer to run as part of syndication.
If there issues using 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 our 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, we might want to consider the same backup for the subscriber.

Stop all WebSphere Portal and Deployment Manager and nodeagent JVMs involved.
In all involved profiles, edit...
profile/config/cells//wim/config/wimconfig.xml

Find the tag...
<config:attributeConfiguration>

...for the LDAP in question and in there add the following tag before the closing <config:attributeConfiguration> tag:
<config:externalIdAttributes name="distinguishedName"/>

Save the file.
Restart the involved JVMs - in a cell/cluster starting with the Deployment Manager, nodeagents and then WebSphere Portal JVMs.

See: Configuring Portal to use distinguished name as LDAP unique identifier (extID)

Multiple LDAP Directories and WCM

See also: Multiple LDAP realms with Active Directory
The following article discusses aggregation of users from one or more LDAP trees of the user registry and how to expose them as a coherent user population. This is achieved using realms. This can also be referred as horizontal partitioning. WebSphere Portal and Web Content management allows aggregation of users from one or more LDAP trees of the user registry and exposes them as a coherent user population. This is achieved using realms. Users can belong to more than one realm.
Consider a case where an organization has LDAP A with the following prefix...
o=test.com

...and LDAP B with the following prefixes...
o=mycorp
o=externals

Sample configurations steps...

Add both repositories to vmm using wp-create-ldap
Add a second baseEntry to LDAP B using wp-create-base-entry
Add realms...
wp-create-realm realmname=LDAP_A addBaseEntry=o=foo.bar
wp-create-realm realmname=LDAP_B addBaseEntry=o=mycorp
wp-create-realm realmname=LDAP_B_mycorp addBaseEntry=o=mycorp
wp-create-realm realmname=LDAP_B_external addBaseEntry=o=externals "

Now we have 4 Realms with each one containing a single BaseEntry.
Add the second BaseEntry for LDAP B
wp-add-realm-baseentry realmname=LDAP_B addBaseEntry=o=externals"

Parent Web content administration tools

IBM Tivoli Directory Server	ibm-entryUUID
Microsoft Active Directory	objectGUID
Novell eDirectory	GUID
IBM Domino Server	dominoUNID
SunOne Directory Server	nsuniqueId