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

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

The flat-naming convention is...

cn=groupName

...the hierarchical format is...

cn=groupName,o=root

Ensure IDs are unique between the default federated repository and the LDAP we are adding. For example, if the default federated repository contains an ID such as wpsadmin, this ID cannot exist in the LDAP we are adding.

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

Add an LDAP user registry to the default federated repository; repeat these steps for each additional LDAP user registry to add:

Complete these steps on the primary node only.

Use the helper file...

WP_PROFILE/ConfigEngine/config/helpers/wp_add_federated_xxx.properties

1. Run backupConfig

2. Edit wkplc.properties

3. Set parameters under the VMM Federated LDAP Properties heading:
   federated.ldap.id
   federated.ldap.host
   federated.ldap.port
   federated.ldap.bindDN
   federated.ldap.bindPassword
   federated.ldap.ldapServerType
   federated.ldap.baseDN

4. Set entity types parameters...
   
   federated.ldap.et.group.objectClasses
   federated.ldap.et.personaccount.objectClasses

5. Set group member parameters...
   
   federated.ldap.gm.groupMemberName
   federated.ldap.gm.objectClass
   federated.ldap.gm.scope
   federated.ldap.gm.dummyMember

6. Save changes to wkplc.properties.

7. 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.

8. 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.

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

10. 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.

       • id
       • baseDN
       • nameInRepository

    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.
       

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

12. 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

13. 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:
       • personAccountParent
       • groupParent
       • personAccountRdnProperties
       • groupRdnProperties

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

       For example:

       • personAccountParent=dc=myco,dc=com
       • groupParent=dc=myco,dc=com

    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.
       

14. 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.

15. 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.

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

17. 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.
       

18. 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