CWWIM4538E occurs on login after configuring for federated repository

Technote (troubleshooting)


Problem

When the security of IBM WebSphere Portal is configured for the federated repository, the login to WebSphere Portal or the Integrated Solutions Console (ISC) can fail with the following error in the SystemOut.log:

[datetime] 0000004d exception E com.ibm.ws.wim.ProfileManager loginImpl CWWIM4538E Multiple principals were found for the 'wpsadmin' principal name.

[datetime] 0000004d exception E com.ibm.ws.wim.ProfileManager loginImpl
com.ibm.websphere.wim.exception.DuplicateLogonIdException: CWWIM4538E Multiple principals were found for the 'wpsadmin' principal name.

Cause

Duplicate user names were found across repositories in the federated environment.

Environment

Security configured for federated repository.

Resolving the problem

WebSphere Virtual Member Manager (VMM) has a restriction that the login attribute must be unique across all participating repositories in a federated repository environment. It is therefore recommended that you choose a user name for your administration user during installation of WebSphere Portal or WebSphere Deployment Manager that will not conflict with your potential LDAP users. This user name by default is written to the fileregistry.xml file, located under <wp_profile_root>/cells/<cellname>/.

If you have duplicate user names across the LDAP and file repositories in your environment, you may not be able to log in as the respective administrative user in WebSphere Portal and/or via the WebSphere Integrated Solutions Console (ISC, aka the admin console).


Prior to implementing any solution from scenarios 1-5 below, consider adding a search filter that can distinguish a user in one registry from others, for example:

<config:ldapEntityTypes name="PersonAccount" searchFilter="(&(objectclass=inetOrgPerson)(!(uid=wpsadmin)))">
(This negative search filter excludes wpsadmin from the LDAP repository . The wpsadmin from the file repository could then log in without encountering a duplicate ID error.)

or:
<config:ldapEntityTypes name="PersonAccount" searchFilter="(employeeNumber=12345)">
(This positive search filter allows only 12345 to log in from this repository.)

Refer to Internet Engineering Task Force (IETF) RFC 4515 for a specification of LDAP search filter syntax.

Once you can log in using the actual administrative IDs, remove or rename the users with duplicate IDs from the other repositories. Remove the search filter when it is no longer needed.

Use a similar approach to work around duplicate group names.


If you cannot work around the problem using a search filter, choose the scenario below which matches your conditions and follow the recommended resolution.


Scenario #1
Conditions:

  • WebSphere Application Server administrative user is not affected (login to ISC succeeds using login attribute).
  • WebSphere Portal administrative user fails to log into WebSphere Portal.

Resolution:
a) You should be able to run the following configuration task to set the WebSphere Portal admin user to be different from the user name in the file registry:
ConfigEngine.sh wp-change-portal-admin-user - DnewAdminId= newadminid  -DnewAdminPw= newpassword -DnewAdminGroupI newadmingroup
    NOTE: The configuration tasks above assume that you have the WasUserid and WasPassword values populated in the wkplc.properties file with the information for your WebSphere Application Server administrative user.

b) Restart the servers. In a clustered environment, restart the Deployment Manager, the node agent, and WebSphere_Portal servers. In a standalone environment, restart the server1 and WebSphere_Portal servers. Confirm that logging into WebSphere Portal with the login attribute succeeds.

Scenario #2
Conditions:
  • WebSphere Application Server administrative user fails to log into the ISC when using the login attribute.
  • WebSphere Application Server administrative user successfully logs in when using the full DN (uid=wasadmin,o=ibm).
  • WebSphere Portal administrative user login to WebSphere Portal can fail or succeed in this scenario.
  • You are able to choose different LDAP users for your administrative users that are unique across all of the repositories.

Resolution:
a) Run the following configuration task(s):
ConfigEngine.sh wp-change-was-admin-user - DnewAdminId= newadminid  -DnewAdminPw= newpassword
    If the WebSphere Portal administrative user fails, run the following:
    ConfigEngine.sh wp-change-portal-admin-user - DnewAdminId= newadminid  -DnewAdminPw= newpassword -DnewAdminGroupId= newadmingroup
    NOTE: The configuration tasks above assume that you have the WasUserid and WasPassword values populated in the wkplc.properties file. These values match the credentials that succeed on the login to the ISC when using the DN.

b) Restart the servers (using the full DN for the -username parameter) and then retest the login. In a clustered environment, restart the Deployment Manager, the node agent, and WebSphere_Portal servers. In a standalone environment, restart the server1 and WebSphere_Portal servers.

Scenario #3
Conditions:
  • WebSphere Application Server administrative user fails to log into the ISC when using the login attribute.
  • WebSphere Application Server administrative user fails to log into the ISC when using the full DN (uid=wasadmin,o=ibm).
  • WebSphere Portal administrative user login to WebSphere Portal can fail or succeed in this scenario.
  • You are able to choose different LDAP users for your administrative users that are unique across all of the repositories.

Resolution:
a) Run the following configuration task(s) to reference the unique entries in LDAP:
ConfigEngine.sh wp-change-was-admin-user - DnewAdminId= newadminid  -DnewAdminPw= newpassword -Dskip.ldap.validation=true
    If the WebSphere Portal administrative user fails, run the following:
    ConfigEngine.sh wp-change-portal-admin-user - DnewAdminId= newadminid  -DnewAdminPw= newpassword -DnewAdminGroupId= newadmingroup  -Dskip.ldap.validation=true

b) In the current state, it is not possible to stop the servers cleanly via the command line. You must kill the Java processes for the respective servers via your operating system administrative utilities (in a standalone environment: WebSphere_Portal and server1; in a clustered environment: Deployment Manager, node agent, and cluster members such as WebSphere_Portal.).

c) Start the servers. In a clustered environment, restart the Deployment Manager, the node agent, and WebSphere_Portal servers. In a standalone environment, restart the server1 and WebSphere_Portal servers. Confirm that your unique administrative user(s) can log in using the login attribute.

Scenario #4
Conditions:
  • WebSphere Application Server administrative user fails to log into the ISC when using the login attribute.
  • WebSphere Application Server administrative user successfully logs in when using the full DN (uid=wasadmin,o=ibm).
  • WebSphere Portal administrative user login to WebSphere Portal can fail or succeed in this scenario.
  • You are not able to choose different LDAP users for your administrative users that are unique across all of the repositories. You want to use the LDAP user name(s) that are in conflict with the file registry user.

Resolution:
NOTE: The following resolution will remove the file registry from the federated repository so that there are no longer duplicate entries found for the user(s). If you setting up a non-production environment and want to keep the file registry, the alternative to the following steps would be to rename the user in the file registry so that the login attribute is unique.

a) Remove the file registry from the federated repository by doing the following:
    -- Ensure the following properties are specified in the wkplc.properties file:
      federated.delete.baseentry=o=defaultWIMFileBasedRealm
      federated.delete.id=InternalFileRepository
    -- Run the following ConfigEngine task:
      ConfigEngine.sh wp-delete-repository
    NOTE: The configuration task above assumes that you have the WasUserid and WasPassword values populated in the wkplc.properties file with the information for your WebSphere Application Server administrative user.

b) Restart the servers. In a clustered environment, restart the Deployment Manager, the node agent, and WebSphere_Portal servers. In a standalone environment, restart the server1 and WebSphere_Portal servers. Confirm that login with the login attribute succeeds to the ISC.

Scenario #5
Conditions:
  • WebSphere Application Server administrative user fails to log into the ISC when using the login attribute.
  • WebSphere Application Server administrative user fails to log into the ISC when using the full DN (uid=wasadmin,o=ibm).
  • WebSphere Portal administrative user login to WebSphere Portal can fail or succeed in this scenario.
  • You are not able to choose different LDAP users for your administrative users that are unique across all of the repositories. You want to use the LDAP username(s) that are in conflict with the file registry user.

Resolution:
NOTE: The following resolution will remove the file registry from the federated repository so that there are no longer duplicate entries found for the user(s). If you setting up a non-production environment and want to keep the file registry, the alternative to the following steps would be to rename the user in the file registry so that the login attribute is unique.

a) Enable DN login by modifying wimconfig.xml under <wp_profile_root>/config/cells/<cellname>/wim/config/ to set the following property in the realm where the problem occurs:
    from
    <config:userSecurityNameMapping propertyForInput="principalName" propertyForOutput="externalName"/>
    to
    <config:userSecurityNameMapping propertyForInput="uniqueName" propertyForOutput="uniqueName"/>

b) In the current state, it is not possible to stop the servers cleanly via the command line. You must kill the Java processes for the respective servers via your operating system administrative utilities (in a standalone environment: WebSphere_Portal and server1; in a clustered environment: Deployment Manager, node agent, and cluster members such as WebSphere_Portal.)

c) Start the servers. In a clustered environment, restart the Deployment Manager, the node agent, and WebSphere_Portal servers. In a standalone environment, restart the server1 and WebSphere_Portal servers. Confirm you can now log into the ISC by using the full DN for your administrative user.

d) Remove the file registry from the federated repository by doing the following:
    -- Ensure the following properties are specified in wkplc.properties:
      federated.delete.baseentry=o=defaultWIMFileBasedRealm
      federated.delete.id=InternalFileRepository
    -- Run the following ConfigEngine task:
      ConfigEngine.sh wp-delete-repository

e) Disable the DN login from step (a) above by running the following ConfigEngine task:
    ConfigEngine.sh wp-modify-realm-disable-dn-login
    NOTE: The configuration tasks above assume that you have the WasUserid and WasPassword values populated in the wkplc.properties file. These values match the credentials that succeed on the login to the ISC when using the DN.

f) Restart the servers. In a clustered environment, restart the Deployment Manager, the node agent, and WebSphere_Portal servers. In a standalone environment, restart the server1 and WebSphere_Portal servers. Confirm that login with the login attribute succeeds to the ISC.

Related information

IETF RFC 4515


Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

WebSphere Portal
Security

Software version:

6.1, 7.0, 8.0

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows, i5/OS, z/OS

Software edition:

Enable, Express, Extend, Server

Reference #:

1380286

Modified date:

2012-12-07

Translate my page

Machine Translation

Content navigation