+

Search Tips   |   Advanced Search

Add an LDAP user registry over SSL on IBM i in a clustered environment


Add an LDAP user registry over SSL to the default federated repository to store user account information for secure authorization. We can add multiple LDAP user registries to the default federated repository although we can only add one LDAP server at a time.

In a clustered environment, start the dmgr and nodeagent and verify they are able to synchronize.

Use the helper file...


Add an LDAP user registry over SSL to the default federated repository

You must repeat these steps for each additional LDAP user registry to add:

Complete these steps on the primary node only. In the following instructions, where the step refers to wkplc.properties, use the wp_add_federated_xxx.properties helper file.

  1. Run backupConfig

  2. Retrieve the SSL certificate from the port:

    1. Log in to the WAS admin console.

    2. Go to...

        Security | SSL certificate and key management | SSL configurations

    3. Click the appropriate SSL configuration from the list. for example...

        CellDefaultSSLSettings

      Clustered environments: Ensure the setting for SSL configuration for outbound connection matches the SSL settings.

    4. Click Key stores and certificates.

    5. Click the appropriate truststore from the list; for example...

        CellDefaultSSLSettings

    6. Click...

      ...and then enter the following information:

    7. Click Retrieve signer information to retrieve the certificate from the port.

    8. Click OK and then click Save to save the changes to the master configuration.

  3. Edit wkplc.properties

  4. Set parameters under the VMM Federated LDAP Properties heading:

  5. Set entity types parameters...

  6. Set group member parameters...

  7. Set advanced parameters for SSL:

    Required...

    To enable the SSL configuration for the LDAP user registry, set federated.ldap.sslEnabled=true.

    Optional...

  8. Save changes to wkplc.properties.

  9. Run the ConfigEngine.sh validate-federated-ldap -DWasPassword=foo task to validate the LDAP server settings.

    In an environment configured with an LDAP with SSL, during the validation task, you will be prompted to add a signer to the truststore.

    For example...

      Add signer to the truststore now?

    If you do, press y then Enter.

  10. Run the ConfigEngine.sh wp-create-ldap -DWasPassword=foo task, from WP_PROFILE/ConfigEngine, to add an LDAP user registry to the default federated repository.

    Users who are not in an LDAP do not have awareness and cannot see if other users are online. This can happen if you install WebSphere Portal and then enable a Federated LDAP or Federated database user repository that does not contain that user. Also, users who sign up using the Self Care portlet do not have awareness.

  11. Stop and restart servers, dmgrs, and node agents.

  12. To create additional base entries within the LDAP user registry; repeat these steps for each base entry :

    1. Edit wkplc.properties

    2. To create additional base entries within the LDAP user registry to use when creating realms, set parameters.

    3. Save changes to wkplc.properties.

    4. Run the ConfigEngine.sh wp-create-base-entry -DWasPassword=foo task, from WP_PROFILE/ConfigEngine, to create a base entry in a repository.

    5. Stop and restart all necessary servers to propagate the changes.

  13. Optional: Run the ConfigEngine.sh wp-query-repository -DWasPassword=foo task, from WP_PROFILE/ConfigEngine, to list the names and types of configured repositories.

  14. Run the ConfigEngine.sh wp-validate-federated-ldap-attribute-config -DWasPassword=foo task, from WP_PROFILE/ConfigEngine, to check that all defined attributes are available in the configured LDAP user registry.

    See Adapting the attribute configuration

  15. To update the user registry where new users and groups are stored:

    If we are using multiple LDAP user registries and/or a database user registry, only run this task for the user registry to define as the default user registry where new users and groups are stored.

    1. Edit wkplc.properties

    2. Set the following required parameters under the VMM supported entity types configuration heading:

      The parameters groupParent and personAccountParent must be set to the same value.

      For example:

    3. Save changes to wkplc.properties.

    4. Run the ConfigEngine.sh wp-set-entitytypes -DWasPassword=foo task, from WP_PROFILE/ConfigEngine, to delete the old attributes before adding the new attributes.

    5. Stop and restart all necessary servers to propagate the changes.

    To enable the full distinguished name login if the short names are not unique for the realm:

    Run this task if the administrator name is in conflict with another user name in the attached repository. This command allows the Administrator to log in using the fully distinguished name instead of the short name.

    1. Edit wkplc.properties

    2. Enter a value for realmName or leave blank to update the default realm.

    3. Save changes to wkplc.properties.

    4. Run the ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=foo task, located in the WP_PROFILE/ConfigEngine, to enable the distinguished name login.

      After running this task to enable the full distinguished name login, we can run the ConfigEngine.sh wp-modify-realm-disable-dn-login -DWasPassword=foo task to disable the feature.

    5. Stop and restart all necessary servers to propagate the changes.

  16. Optional: Update the member names used by WCM with the corresponding members in the LDAP directory.

    This step is only needed if you have installed the portal with WCM and intend to use the Intranet and Internet Site Templates that were optionally installed with the product by running configure-express.

    1. Edit...

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

    2. Add the following lines to the file:
      uid=wpsadmin,o=defaultWIMFileBasedRealm -> portal_admin_DN 
      cn=contentauthors,o=defaultWIMFileBasedRealm -> content_authors_group_DN

      The MemberFixerModule.properties file already contains lines for xyzadmin. We can ignore this line.

    3. Save the changes and close the file.

    4. Run the ConfigEngine.sh run-wcm-admin-task-member-fixer -DallLibraries=true -Dfix=true -DaltDn=update -DmismatchedId=update -DinvalidDn=update -DnoRealmDn=true -DPortalAdminPwd=wpsadmin task, located in the WP_PROFILE/ConfigEngine.

      LDAP Value
      Standalone realm_name should match the value for standalone.ldap.realm in wkplc.properties.
      Federated realm_name should match the value for federated.realm in wkplc.properties. If value is empty, use defaultWIMFileBasedRealm.

  17. Optional: Assign access to the Web content libraries.

    1. Log in as a portal administrator and navigate to...

        Administration | Portal Content | Web Content Libraries | web_library | Set permissions

    2. Click the Edit Role icon for Editor.

    3. Add the group specified for content_authors_group_DN as an Editor for the Intranet and Internet libraries.

    4. Click Apply then Done.

  18. If you have created any additional WCM libraries, run the Web content member fixer task to update the member names used by the libraries.

  19. Optional. Replace the WAS and portal administrator user and group IDs with users and groups that exist in the LDAP user registry.

    Before starting...

    • Review Special characters in user ID and passwords located under Planning for WebSphere Portal.
    • Ensure the new user ID of the WAS administrator is not identical to the one that we are replacing.

    This step is required in a production environment.

    If you run these tasks after you create the cluster, run them on all nodes in the cluster.

    1. Run the following ConfigEngine.sh wp-change-was-admin-user -DWasUser=adminid -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword

      Provide the full DN for the newAdminId parameter.

    2. Verify the task completed successfully. Stop and restart all required servers.

    3. Run the following ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

      Provide the full DN for the newAdminId and newAdminGroupId parameters.

      This task verifies the user against a running server instance. If the server is stopped, to skip the validation...

        -Dskip.ldap.validation=true

    4. Update the SearchAdminUser alias to match the WebSphere Portal administrator information.

    5. Verify the task completed successfully. Stop and restart all required servers.

  20. This step is required in a production environment. Remove the file system repository if you do not use it. The federated file system user repository that was the default security setting might not be required after federating the user repository. If the file system repository is no longer needed, removing it can help prevent conflicts created by duplicate user identities existing in multiple repositories.

    See the following topic under Related for instructions: Delete the repository, which is listed with the appropriate operating system.

If you created a cluster, including additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.


Parent: Configure a federated LDAP user registry on IBM i in a clustered environment
Related:
Start and stop servers, dmgrs, and node agents
Enable LDAP security after cluster creation
Replace the search administrator user ID
Related:
User IDs and passwords

How to fix Portal Access Control settings after user/group external identifiers have changed