AIX stand-alone: Add an LDAP user registry to a federated repository over SSL


Overview

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 only add one LDAP server at a time.

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.

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.


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

Repeat these steps for each additional LDAP user registry that you plan to add:

  1. Add the SSL certificate for the LDAP server to the server trust store and the client trust store:

    1. Add the certificate to the server trust store:

      • Add cert to server trust store

        1. Log in to the WAS console.

        2. Navigate to Security -> SSL certificate and key management -> SSL configurations.

        3. Click the appropriate SSL configuration from the list. For example,

            Stand-alone: NodeDefaultSSLSettings
            Clustered: CellDefaultSSLSettings

        4. Click Key stores and certificates.

        5. Click the appropriate trust store from the list. For example,

            Stand-alone: NodeDefaultTrustStore
            Clustered: CellDefaultTrustStore

        6. Click Signer certificates, click Add, and then enter the following information:

            Alias the key store uses for the signer certificate.

            Type the File name where the signer certificate is located.

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

      • Retrieve cert from port

        1. Log in to the WAS console and navigate to...

            Security | SSL certificate and key managementSSL configurations

        2. Click the appropriate SSL configuration from the list. For example,

            Stand-alone NodeDefaultSSLSettings
            Clustered CellDefaultSSLSettings

        3. Click Key stores and certificates.

        4. Click the appropriate trust store from the list. For example,

            Stand-alone NodeDefaultTrustStore Clustered CellDefaultTrustStore

        5. Click...

          .and then enter the following information:

          • Hostname used when attempting to retrieve the signer certificate from the SSL port.
          • SSL Port used when attempting to retrieve the signer certificate.
          • Alias the key store uses for the signer certificate.

          For Clustered ensure the setting for...

            SSL configuration for outbound connection

          .matches SSL settings.

    2. To retrieve the certificate from the port, click...

        Retrieve signer information

    3. Save changes

  2. Add the LDAP certificate to the client trust store:

    1. Review Secure installation for client signer retrieval.

    2. For any federated node, against the Deployment Manager, run...

      This task might report an error, but it does successfully update the trust store. You can ignore the error message.

      Example task:

      Stand-alone

        ./retrieveSigners.sh NodeDefaultTrustStore ClientDefaultTrustStore -autoAcceptBootstrapSigner -conntype SOAP -port port_number

      Clustered

        ./retrieveSigners.sh CellDefaultTrustStore ClientDefaultTrustStore -autoAcceptBootstrapSigner -conntype SOAP -port port_number

        The following message displays: CWPKI0308I: Add signer alias "alias_name" to local keystore "ClientDefaultTrustStore" with the following SHA digest: ssl_certificate_fingerprint

    3. Update the trust store properties file.

        Clustered:

        • Perform the following steps on the primary node then resynchronize through the Dmgr to propagate the changes.

        • Check each node to ensure that ssl.client.props contains the same values as on the primary node. If the values are not identical to those on the primary node, restart that server to synchronize the changes.

          Edit

            WP_PROFILE/properties/ssl.client.props

          .and set...

            com.ibm.ssl.trustStore

          .and the related trust store parameters to match the trust file specified in the SSL configuration. For example,

        Stand-alone: To use the default trust store...

              com.ibm.ssl.trustStore=WP_PROFILE/config/cells/cell_name/trust.p12


        Clustered: To use the default trust store...

          com.ibm.ssl.trustStore=WP_PROFILE/config/cells/cell_name/trust.p12

      • Save changes.

  3. Edit WP_PROFILE/ConfigEngine/properties/wkplc.properties

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

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

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

  7. Enter a value for the following parameters to enable Secure Socket Layers (SSL):

      Required parameters:

        federated.ldap.sslEnabled
        federated.ldap.sslConfiguration
      Optional parameters:

        federated.ldap.certificateMapMode
        federated.ldap.certificateFilter

  8. Save changes to wkplc.properties.

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

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

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

  11. Stop and restart the appropriate servers to propagate the changes.

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

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

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

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

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

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

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

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

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

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


Parent

Configure a default federated user registry


Related tasks

Adapt the attribute configuration
Start and stop servers, dmgrs, and node agents
User IDs and passwords
Delete the repository on AIX

 


+

Search Tips   |   Advanced Search