Add an LDAP user registry over SSL on AIX
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.
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: Use the wp_add_federated_xxx.properties helper file, located in...
WP_PROFILE/ConfigEngine/config/helpers
...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 the SSL certificate for the LDAP server to the server trust store and the client trust store:
- Add the certificate to the server trust store:
Options for adding the LDAP SSL certificate to the server trust store
Option Steps Add cert to server trust store
- Log in to the WAS console.
- Navigate to Security -> SSL certificate and key management -> SSL configurations.
- Click the appropriate SSL configuration from the list. For example,
Stand-alone: NodeDefaultSSLSettings
Clustered: CellDefaultSSLSettings
- Click Key stores and certificates.
- Click the appropriate trust store from the list. For example,
Stand-alone: NodeDefaultTrustStore
Clustered: CellDefaultTrustStore
- 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.
- Click OK and then click Save to save the changes to the master configuration.
Retrieve cert from port
- Log in to the WAS console.
- Navigate to Security -> SSL certificate and key management -> SSL configurations.
- Click the appropriate SSL configuration from the list. For example,
Stand-alone: NodeDefaultSSLSettings
Clustered: CellDefaultSSLSettings
- Click Key stores and certificates.
- Click the appropriate trust store from the list. For example,
Stand-alone: NodeDefaultTrustStore
Clustered: CellDefaultTrustStore
- Click Signer certificates, click Retrieve from port, and then enter the following information:
Host name 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.
Clusters: Verify SSL configuration for outbound connection matches SSL settings.
- Click Retrieve signer information to retrieve the certificate from the port.
- Click OK and then click Save to save the changes to the master configuration.
- Add the LDAP certificate to the client trust store:
- See Secure installation for client signer retrieval.
- Run the retrieveSigners task.
In a deployed environment, run the retrieveSigners task, for any federated node, against the Deployment Manager
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
When prompted...
Realm/Cell Name: name
The following message displays: CWPKI0308I: Add signer alias "alias_name" to local keystore "ClientDefaultTrustStore" with the following SHA digest: ssl_certificate_fingerprint
Username: user_ID
Password: password
- 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
- Change the com.ibm.ssl.trustStore parameter 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/nodes/node_name/trust.p12
- Save changes.
- Edit WP_PROFILE/ConfigEngine/properties/wkplc.properties
- 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
- 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
- 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
- Enter a value for the following parameters to enable Secure Socket Layers (SSL):
Required parameters:
federated.ldap.sslEnabled
Optional parameters:
federated.ldap.sslConfigurationfederated.ldap.certificateMapMode
federated.ldap.certificateFilter
- Save changes to wkplc.properties.
- 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.
- 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.
- Stop and restart the appropriate servers to propagate the changes.
- 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:
- Edit WP_PROFILE/ConfigEngine/properties/wkplc.properties
- 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:
- 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.
- Stop and restart all necessary servers to propagate changes.
- Optional. Run the ./ConfigEngine.sh wp-query-repository -DWasPassword=foo from the WP_PROFILE/ConfigEngine, to list the names and types of configured repositories.
- 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.
- 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.
- Edit WP_PROFILE/ConfigEngine/properties/wkplc.properties
- Enter a value under the VMM supported entity types configuration heading:
personAccountParent
The parameters groupParent and personAccountParent must be set to the same value. For example:
groupParent
personAccountRdnProperties
groupRdnPropertiespersonAccountParent=dc=yourco,dc=com
groupParent=dc=yourco,dc=com
- 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.
- Stop and restart all necessary servers to propagate changes.
- Optional. To enable the full distinguished name login if the short names are not unique for the realm:
- Edit WP_PROFILE/ConfigEngine/properties/wkplc.properties
- Enter a value for realmName or leave blank to update the default realm.
- 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.
- Stop and restart all necessary servers to propagate changes.
- 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.
- Edit...
WP_PROFILE/PortalServer/wcm/shared/app/config/wcmservices/MemberFixerModule.properties
- 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.
- 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.
Optional. Assign access to the Web content libraries.
- Log in as a portal administrator.
- Navigate to Administration -> Portal Content -> Web Content Libraries.
- Click the Set permissions icon for the Web library.
- Click the Edit Role icon for Editor.
- Add the group you specified for content_authors_group_DN as an Editor for the Intranet and Internet libraries.
- Click Apply then Done.
If you have created any additional WCM libraries, run the Web content member fixer task to update the member names used by the libraries.
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:
If you run these tasks after you create cluster, run them on all nodes in the cluster.
- 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.
- 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.
- 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.
- 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.
- 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.
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