Add an LDAP user registry on AIX

Add an LDAP user registry to the default federated repository to store user account information for authorization. You can add multiple LDAP user registries to the default federated repository although you can only add one LDAP server at a time. If IBMLotus Dominowill be one of user registries in a multiple registry configuration and will share a realm with another user registry, ensure that the groups are stored in a hierarchical format in the Domino Directory as opposed to the default flat-naming structure. For example, the flat-naming convention is cn=groupName and the hierarchical format is cn=groupName,o=root. You must also ensure that the IDs that are unique between the default federated repository and the LDAP you are adding. For example, if the default federated repository contains an ID such as wpsadmin, this ID cannot exist in the LDAP you are adding.

In single server environments, you do not have to start or stop the WebSphere_Portal and server1 servers to complete the following steps. In clustered environments, stop all application servers on system, including WebSphere_Portal, then start the nodeagent and dmgr servers before you begin any of the following steps.

Add an LDAP user registry to the default federated repository; repeat these steps for each additional LDAP user registry that you plan to add: Use the wp_add_federated_xxx.properties helper file, located in...

...when performing this task to ensure the correct properties are entered. In the instructions below, when the step refers to wkplc.properties, you will use wp_add_federated_xxx.properties helper file.

  1. Prior to configuring security, use the IBM WAS backupConfig task to create and store a backup of the portal configuration; see backupConfig command for information.

  2. Edit WP_PROFILE/ConfigEngine/properties/wkplc.properties

  3. Required: Enter a value 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. Required: Enter a value under the LDAP entity types heading:

        federated.ldap.et.group.objectClasses
        federated.ldap.et.group.objectClassesForCreate
        federated.ldap.et.group.searchBases
        federated.ldap.et.personaccount.objectClasses
        federated.ldap.et.personaccount.objectClassesForCreate
        federated.ldap.et.personaccount.searchBases

  5. Required: Enter a value under the Group member attribute heading:

        federated.ldap.gm.groupMemberName
        federated.ldap.gm.objectClass
        federated.ldap.gm.scope
        federated.ldap.gm.dummyMember

  6. Save changes to wkplc.properties.

  7. Validate LDAP server settings.

      ./ConfigEngine.sh validate-federated-ldap -DWasPassword=foo

    If you have not deleted the default file repository, WasPassword is the value entered during installation and not a value found in LDAP user registry. During the validation task, you may receive the following prompt: Add signer to the trust store now?. Press y then Enter.

  8. Add an LDAP user registry to the default federated repository.

      WP_PROFILE/ConfigEngine
      ./ConfigEngine.sh wp-create-ldap -DWasPassword=foo

      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 the appropriate servers to propagate the changes.

  10. Optional. Create additional base entries within the LDAP user registry; repeat these steps for each base entry that you want to create for multiple realm support:

    1. Edit WP_PROFILE/ConfigEngine/properties/wkplc.properties

    2. Enter a value under the VMM repository base entry configuration heading to create additional base entries within the LDAP user registry to use when creating realms:

          id

          baseDN
          nameInRepository

    3. Save changes to wkplc.properties.


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

    4. Stop and restart all necessary servers to propagate changes.

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

  12. Check that all defined attributes are available in the configured LDAP user registry...

      ./ConfigEngine.sh wp-validate-federated-ldap-attribute-config

    See "Adapting the attribute configuration" for information about adding and mapping attributes to ensure proper communication between WebSphere Portal and the LDAP server.

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

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

      1. Edit WP_PROFILE/ConfigEngine/properties/wkplc.properties

      2. Enter a value 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=yourco,dc=com

            groupParent=dc=yourco,dc=com

      3. Save changes to wkplc.properties.


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

      4. Stop and restart all necessary servers to propagate changes.

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

    1. Edit WP_PROFILE/ConfigEngine/properties/wkplc.properties

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

    3. Save changes to wkplc.properties.


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

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

    4. Stop and restart all necessary servers to propagate changes.

  15. Run the Member Fixer task to update the member names used by WCM with the corresponding members in the LDAP directory.

    This step ensures that access to the Web content libraries for the Intranet and Internet Site Templates for the contentAuthors group is correctly mapped to the appropriate group in the LDAP directory.

      This step is only needed if you intend to use the Intranet and Internet Site Templates that were optionally installed using configure-express.

      1. Edit...

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

      2. Add the following lines to the file: 

          uid=xyzadmin,o=defaultWIMFileBasedRealm -> portal_admin_DN
cn=contentauthors,o=defaultWIMFileBasedRealm -> content_authors_group_DN

          • Ensure the portal administrator you specify for portal_admin_DN is a member of the group you specify for content_authors_group_DN, otherwise the portal administrator cannot access the Web content libraries for the Intranet and Internet Site Templates.

          • If you plan to run the express-memberfixer task in an environment with multiple realms, if it exists, remove group...

              cn=contentauthors,o=defaultWIMFileBasedRealm

            If this group exists in an environment with multiple realms, the Member Fixer task does not have any effect.

      3. Save changes and close the file.


        ./ConfigEngine.sh express-memberfixer -DmemberfixerRealm=realm_name -DPortalAdminPwd=foo -DWasPassword=foo located in the WP_PROFILE/ConfigEngine.

          Choose the appropriate value to enter for realm_name depending on the type of LDAP user registry you configured:

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

  16. Optional. Assign access to the Web content libraries.

    1. Log in as a portal administrator.

    2. Navigate 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 you specified for content_authors_group_DN as an Editor for the Intranet and Internet libraries.

    6. Click Apply then Done.

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

  18. Optional. This step is required in a production environment. Before removing the file system repository, perform the following steps to replace the WAS and WebSphere Portal administrator user ID and administrative group ID with users and groups that exist in the LDAP user registry:

    • Before changing the user ID and password, review Special characters in user ID and passwords located under Plan for WebSphere Portal.

    • Ensure the new user ID of the WAS administrator is not identical to the one that you are replacing. Duplicate user IDs cause authentication problems with the administrative console.

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

    1. Run the following task from the WP_PROFILE/ConfigEngine: ./ConfigEngine.sh wp-change-was-admin-user -DWasPassword=foo -DnewAdminId=newadminid -DnewAdminPw=newpassword

      You must provide the full distinguished name (DN) for the newAdminId parameter.

    2. Verify that the task completed successfully. In a clustered environment, restart the dmgr, the node agent(s), and WebSphere_Portal servers. In a standalone environment, restart the server1 and WebSphere_Portal servers.

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

      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. Verify that the task completed successfully. In a clustered environment, restart the dmgr, the node agent(s), and WebSphere_Portal servers. In a standalone environment, restart the server1 and WebSphere_Portal servers.

  19. Optional. 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, which is organized by OS, for instructions: Delete the repository.


Related tasks


Adapt the attribute configuration


User IDs and passwords
Delete the repository on AIX

 


+

Search Tips   |   Advanced Search