+

Search Tips   |   Advanced Search


Troubleshoot the enable federated security option

To go through the wizard again, download the wizard selections, then, cancel the configuration. Start the process over and upload the saved selections. Correct or enter values for the parameters that caused the failure.

The Enable Federated Security option modifies wimconfig.xml. Make a backup copy of this file before running ConfigEngine tasks.

    WP_PROFILE/config/cells/CellName/wim/config/wimconfig.xml


Manual Step: Retrieve the SSL certificate from the SSL port

Actions Notes
Run the step again Not applicable
Skip the step Yes, if you completed this manual step successfully, we can skip the step in subsequent configuration attempts
Clean up step None required


Validate the LDAP server settings

During this step, the wizard attempts to connect to the LDAP server and authenticate using the provided credentials and LDAP information.

Actions Notes
Run step again We can run the step repeatedly without causing any harm.
Skip step If this step is successful, we can skip it if we run the configuration process again.
Clean up step None required

Verify the values used to connect with the LDAP were entered correctly. Click View Step Command to see which values are used.


Add an LDAP user registry to the default federated repository

During this step, the wizard attempts to add the LDAP to the federated repository. This step uses the same parameters as the step that validates the LDAP server settings.

Actions Notes
Run step again We can run the step repeatedly without causing any harm.
Skip step If this step is successful, we can skip it if we run the configuration process again.
Clean up step To remove the configured repository:

  1. Go to...

      Security | Global Security | Configure

  2. Remove the repository from the realm.

  3. Go to Manage repositories and delete the repository configuration.


Update the user registry where new users and groups are stored

Actions Notes
Run step again We can run the step repeatedly without causing any harm.
Skip step If the current user repository is correct for new users and groups, we can skip this step.
Clean up step To change the repository:

  1. Go to...

      Security | Global Security | Federated repositories | Supported entity types

  2. Click one of the following options to edit the Base Entry for the Default Parent to the specific Base Entry for the target repository:


Register the WAS scheduler tasks

Actions Notes
Run step again We can run this step again after you clean up the issue.
Skip step If this step is successful, we can skip it if we run the configuration process again.
Clean up step Log in to the WAS console. Go to Resources > Schedulers and delete the WPSTaskScheduler.

If this task fails because of the administrator ID, change the federated.ldap.bindDN and optionally the newAdminId value. These values must be unique. Then, rerun this task. If this action does not resolve the issue, run the wp-change-portal-admin-user and wp-change-was-admin-user tasks. These tasks change the PortalAdminId and WasUserId so the file system administrators are different from the LDAP users.


Replace the file-based WebSphere Portal and WebSphere Application Server users and groups with users and groups from the LDAP server

During this step, the wizard attempts to configure the portal to use the administrative user and user group stored in the LDAP server. The administrative ID and group must exist in the LDAP server. If the ID and group do not exist, create them and try the step again.

Actions Notes
Run step again We can run the step repeatedly without causing any harm.
Skip step If this step is successful, we can skip it if we run the configuration process again.
Clean up step We can log in to the WAS console. However, the portal administrative user does not work as expected. We do not need to deactivate security with the file-based repository.

If the WAS administrative user is not functional, it is likely the WAS console is not accessible. If we cannot log in to the WAS console, disable security in the security.xml file in the WP_PROFILE/config/cells/cellname directory. Restart WebSphere Application Server and log in. Then, complete the following steps:

  1. Go to Users and Groups > Administrative user roles.

  2. Validate the current admin ID or set a new user.

  3. Go to Resources > Resource Environment > Resource Environment Providers > WP AccessControlDataManagementService > Custom properties.

  4. Validate the values for the administrative users and groups of the different domains. If necessary, update the values to a valid user.

    Valid users: To find valid users, go to Users and Groups > Manage Users to search for valid users.


Recycle the servers after a security change

During this step, the wizard stops and starts the portal server.

Actions Notes
Run step again Yes, run this step again under the following conditions.

  • If this step fails, run the step again.

  • If we are running the configuration again.

Skip step If we are running the configuration again, we can skip this step only if you skipped all the previous steps.
Clean up step None required


Update the search administration user

The wizard updates the user ID used to manage the search collections.

Actions Notes
Run step again

Yes, run this step again under the following conditions.

  • If this step fails, run the step again.

  • If we are running the configuration again.

Skip step If we are running the configuration again, we can skip this step only if you skipped all the previous steps.
Clean up step Log in to the WAS console and go to...

    Security \ Global security \ Java Authentication and Authorization Service \ J2C authentication data

Change the user ID and password for the SearchAdminUser and the alias.


After we change the security model, the servers need to be restarted

During this step, the wizard stops and starts the portal server.

Actions Notes
Run step again Yes, run this step again under the following conditions.

  • If this step fails, run the step again.

  • If we are running the configuration again.

Skip step If we are running the configuration again, we can skip this step only if you skipped all the previous steps.
Clean up step None required


Verify that all defined attributes are available in the configured LDAP user registry

Actions Notes
Run step again Yes, run this step again under the following conditions:

  • If this step fails, run the step again.

  • If we are running the configuration again.

Skip step If we are running the configuration again, we can skip this step if both of the following conditions are true:

  • The step completed successfully before

  • You did not change any attributes when you corrected other failures

Clean up step None required


Manual Step: Update the appropriate MemberFixerModule.properties file with the values for the LDAP users

Actions Notes
Run step again Not applicable
Skip step Yes, if you previously modified the properties file, we can skip this step.
Clean up step None required


Run the member fixer tool.

During this step, the wizard runs the member fixer tool to clean up the entries in the portal server.

Actions Notes
Run step again Yes, run this step again under the following conditions.

  • If this step fails, run the step again.

  • If we are running the configuration again.

Skip step If we are running the configuration again, we can skip this step only if you skipped all the previous steps.
Clean up step None required


Manual Step: Map attributes to ensure proper communication between WebSphere Portal and the LDAP server

Actions Notes
Run step again Not applicable
Skip step If we successfully completed the step before, then skip this step.
Clean up step None required


Parent Troubleshooting the Configuration Wizard