AIX® cluster: Adding an LDAP user registry over SSL

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

Before you begin

In a stand-alone server environment, you can complete the following task when the servers are either stopped or started. In a clustered environment, start the deployment manager and node agent and verify that they are able to synchronize.

About this task

Complete the following steps to add an LDAP user registry over SSL to the default federated repository. You must repeat these steps for each additional LDAP user registry that you plan to add:
Tip: Complete these steps on the primary node only.
Note: Use the wp_add_federated_xxx.properties helper file, in the wp_profile_root/ConfigEngine/config/helpers directory to ensure that the correct properties are entered. In the following instructions, when the step refers to the wkplc.properties file, use your wp_add_federated_xxx.properties helper file. When you run the task, include the -DparentProperties=dir_path_helperfile -DSaveParentProperties=true parameters.

Procedure

  1. Before you configure security, you must use the IBM® WebSphere® Application Server backupConfig task to create and store a backup of the IBM WebSphere Portal configuration; see backupConfig command for information.
  2. Complete the following steps to retrieve the SSL certificate from the port:
    1. Log in to the WebSphere Integrated Solutions 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 your SSL settings.
    4. Click Key stores and certificates.
    5. Click the appropriate truststore from the list. For example, CellDefaultSSLSettings.
    6. Click Signer certificates, click Retrieve from port, and then enter the following information:
      • Type the Host name that is used when you attempt to retrieve the signer certificate from the SSL port.
      • Type the SSL Port used when you attempt to retrieve the signer certificate.
      • Type the Alias the keystore uses for the signer certificate.
    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. Use a text editor to open the wkplc.properties file, in the wp_profile_root/ConfigEngine/properties directory.
  4. Required: Enter a value for the following parameters in the wkplc.properties file under the VMM Federated LDAP Properties heading:
    Note: See the properties file for specific information about the advanced parameters.
    • federated.ldap.id
    • federated.ldap.host
    • federated.ldap.port
    • federated.ldap.bindDN
    • federated.ldap.bindPassword
    • federated.ldap.ldapServerType
    • federated.ldap.baseDN
  5. Required: Enter a value for the following entity types parameters in the wkplc.properties file under the LDAP entity types heading:
    Note: See the properties file for specific information about the advanced parameters.
    • federated.ldap.et.group.objectClasses
    • federated.ldap.et.personaccount.objectClasses
  6. Required: Enter a value for the following group member parameters in the wkplc.properties file under the Group member attribute heading:
    Note: See the properties file for specific information about the advanced parameters.
    • federated.ldap.gm.groupMemberName
    • federated.ldap.gm.objectClass
    • federated.ldap.gm.scope
    • federated.ldap.gm.dummyMember
  7. Enter a value for the following parameters in the wkplc.properties file under the Advanced Properties heading to enable Secure Socket Layers (SSL):
    Note: See the properties file for specific information about the advanced parameters.
    Required parameters:
    • federated.ldap.sslEnabled
    • federated.ldap.sslConfiguration
    Tip: To enable the SSL configuration for the LDAP user registry, change the value of the federated.ldap.sslEnabled parameter to true.
    Optional parameters:
    • federated.ldap.certificateMapMode
    • federated.ldap.certificateFilter
  8. Save your changes to the wkplc.properties file.
  9. Run the ./ConfigEngine.sh validate-federated-ldap -DWasPassword=password task to validate your LDAP server settings.
    Note: In an environment that is configured with an LDAP with SSL, during the validation task, you are 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=password task, from the wp_profile_root/ConfigEngine directory to add an LDAP user registry to the default federated repository.
    Note: Users who are not in an LDAP do not have awareness and cannot see whether 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 the appropriate servers to propagate the changes. For specific instructions, see Starting and stopping servers, deployment managers, and node agents.
  12. Optional: Complete the following steps to create more base entries within the LDAP user registry. Repeat these steps for each base entry that you want to create for multiple realm support:
    1. Use a text editor to open the wkplc.properties file, in the wp_profile_root/ConfigEngine/properties directory.
    2. Enter a value for the following parameters in the wkplc.properties file under the VMM repository base entry configuration heading. To create more base entries within the LDAP user registry to use, when you create realms:
      Note: See the properties file for specific information about the advanced parameters.
      • id
      • baseDN
      • nameInRepository
    3. Save your changes to the wkplc.properties file.
    4. Run the ./ConfigEngine.sh wp-create-base-entry -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory to create a base entry in a repository.
    5. Stop and restart all necessary servers to propagate your changes.
  13. Optional: Run the ./ConfigEngine.sh wp-query-repository -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory to list the names and types of configured repositories.
  14. Run the ./ConfigEngine.sh wp-validate-federated-ldap-attribute-config -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory to check that all defined attributes are available in the configured LDAP user registry.
    Important: When you finish configuring your LDAP user registry, see "Adapting the attribute configuration" for information about adding and mapping attributes to ensure communication between WebSphere Portal and the LDAP server.
  15. Complete the following steps to update the user registry where new users and groups are stored:
    Note: If you have multiple LDAP user registries or a database user registry, run this task for the user registry that you want to define as the default user registry.
    1. Use a text editor to open the wkplc.properties file, in the wp_profile_root/ConfigEngine/properties directory.
    2. Enter a value for the following parameters in the wkplc.properties file under the VMM supported entity types configuration heading:
      Note: See the properties file for specific information about the advanced parameters.
      • personAccountParent
      • groupParent
      • personAccountRdnProperties
      • groupRdnProperties
      The parameters groupParent and personAccountParent must be set to the same value.
      • personAccountParent=dc=yourco,dc=com
      • groupParent=dc=yourco,dc=com
    3. Save your changes to the wkplc.properties file.
    4. Run the ./ConfigEngine.sh wp-set-entitytypes -DWasPassword=password task, from the wp_profile_root/ConfigEngine directory to delete the old attributes before you add the new attributes.
    5. Stop and restart all necessary servers to propagate your changes.
  16. Optional: Complete the following steps to enable the full distinguished name login if the short names are not unique for the realm:
    Tip: 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. Use a text editor to open the wkplc.properties file, in the wp_profile_root/ConfigEngine/properties directory.
    2. Enter a value for realmName or leave blank to update the default realm.
    3. Save your changes to the wkplc.properties file.
    4. Run the ./ConfigEngine.sh wp-modify-realm-enable-dn-login -DWasPassword=password task, in the wp_profile_root/ConfigEngine directory to enable the distinguished name login.
      Note: After you run this task to enable the full distinguished name login, run the ./ConfigEngine.sh wp-modify-realm-disable-dn-login -DWasPassword=password task to disable the feature.
    5. Stop and restart all necessary servers to propagate your changes.
  17. Optional: Run the Member Fixer task to update the member names that are used by Web Content Manager with the corresponding members in the LDAP directory.
    Note: This step is only needed if you installed the product with Web Content Manager and intend to use the Intranet and Internet Site Templates. These templates that were installed with the product by running the configure-express task.
    1. Edit the wp_profile_root/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties file.
    2. Add the following lines to the file:
      uid=wpsadmin,o=defaultWIMFileBasedRealm -> portal_admin_DN
      cn=contentauthors,o=defaultWIMFileBasedRealm -> content_authors_group_DN
      Where portal_admin_DN is the distinguished name of the portal administrator and content_authors_group_DN is the distinguished name of the content authors group that is used during LDAP configuration.
      Note: The MemberFixerModule.properties file already contains lines for xyzadmin. You can ignore this line.
    3. Save your 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 -Drealm=realm_name -DnoRealmDn=true -DPortalAdminPwd=wpsadmin task, which is in the wp_profile_root/ConfigEngine directory.
      Note: Choose the appropriate value to enter for realm_name depending on the type of LDAP user registry you configured. Search wkplc.properties for .realm and find the appropriate parameter for your LDAP user registry configuration:
      Table 1. Value for realm_name when you run the Member Fixer task to update the member names used by Web Content Manager
      Type of LDAP Value
      Stand-alone LDAP The value that is specified for realm_name must match the value for standalone.ldap.realm in the wkplc.properties file.
      Federated LDAP The value that is specified for realm_name must match the value for federated.realm in the wkplc.properties file. If the value for federated.realm is empty, use defaultWIMFileBasedRealm as the default value.
  18. Optional: Assign access to the web content libraries.
    1. Log in as a portal administrator.
    2. Go to Administration > Portal Content > Web Content Libraries.
    3. Click the Set permissions icon for the web library.
    4. Click the Edit Role icon for Editor.
    5. Add the group that you specified for content_authors_group_DN as an Editor for the intranet and Internet libraries.
    6. Click Apply then Done.
  19. If you created any additional Web Content Manager libraries, run the web content member fixer task to update the member names that are used by the libraries.
  20. Optional: This step is needed in a production environment. Before you remove the file system repository, complete the following steps. These steps replace the WebSphere Application Server and WebSphere Portal administrator user ID and administrative group ID with users and groups that exist in the LDAP user registry:
    Important:
    • Before you change the user ID and password, review Special characters in user ID and passwords in the Planning for WebSphere Portal section.
    • Ensure the new user ID of the WebSphere Application Server administrator is not identical to the one that you are replacing. Duplicate user IDs cause authentication problems with the WebSphere Integrated Solutions Console.
    Note: If you run these tasks after you create your cluster, run the tasks on the primary node only. Afterward, synchronize the nodes in the cluster. Then, run the update-jcr-admin task on the additional nodes.
    1. Run the following task from the wp_profile_root/ConfigEngine directory:

      ./ConfigEngine.sh wp-change-was-admin-user -DWasUser=adminid -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword

      Important: You must provide the full distinguished name (DN) for the newAdminId parameter.
    2. Verify that the task completed successfully. Stop and restart all servers.
    3. Run the following task from the wp_profile_root/ConfigEngine directory:

      ./ConfigEngine.sh wp-change-portal-admin-user -DWasPassword=password -DnewAdminId=newadminid -DnewAdminPw=newpassword -DnewAdminGroupId=newadmingroupid

      Important: You must provide the full distinguished name (DN) for the newAdminId and newAdminGroupId parameters.
      Additional parameter for stopped servers: This task verifies the user against a running server instance. If the server is stopped, add the -Dskip.ldap.validation=true parameter to the task to skip the validation.
    4. Update the SearchAdminUser alias to match your WebSphere Portal administrator information. See the related links for information.
    5. Verify that the task completed successfully. Stop and restart all servers.
  21. Optional: This step is needed in a production environment. Remove the file system repository if you do not use it.
    Important: Do not delete the file system repository if you plan to use IBM Connections.
    The federated file system user repository that was the default security setting might not be needed after you federate the user repository. If the file system repository is no longer needed, removing it can help prevent conflicts that are created by duplicate user identities that exist in multiple repositories. Review the following topic in the Related information section for instructions: Deleting the repository, which is listed with the appropriate operating system.

What to do next

If you created your clustered environment, including the additional nodes, and then completed the steps in this task, you must now run the update-jcr-admin task on the secondary node. See the related links section for instructions.