Update the user registry on AIX

Add a database user registry to the default federated repository

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

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

Add a database user registry to the default federated repository

To help ensure correct properties, we can use...

WP_PROFILE/ConfigEngine/config/helpers/wp_add_DB.properties

1. Run backupConfig

2. Set up a new database, including creating a new user with appropriate database privileges:

   • Create a DB2 database:
     1. Install DB2.

     2. Enter the following database tuning commands:

        db2 "CREATE DB dbname using codeset UTF-8 territory us PAGESIZE 8192"
        db2 "UPDATE DB CFG FOR dbname USING applheapsz 4096"
        db2 "UPDATE DB CFG FOR dbname USING app_ctl_heap_sz 1024"
        db2 "UPDATE DB CFG FOR dbname USING stmtheap 32768"
        db2 "UPDATE DB CFG FOR dbname USING dbheap 2400"
        db2 "UPDATE DB CFG FOR dbname USING locklist 1000"
        db2 "UPDATE DB CFG FOR dbname USING logfilsiz 4000"
        db2 "UPDATE DB CFG FOR dbname USING logprimary 12"
        db2 "UPDATE DB CFG FOR dbname USING logsecond 20"
        db2 "UPDATE DB CFG FOR dbname USING logbufsz 32"
        db2 "UPDATE DB CFG FOR dbname USING avg_appls 5"
        db2 "UPDATE DB CFG FOR dbname USING locktimeout 30"
        db2 "UPDATE DB CFG FOR dbname using AUTO_MAINT off"
        

   • Create an Oracle database:

     1. Install Oracle using UNICODE Database and National character sets such as UTF8, AL32UTF8, or AL16UTF16.

     2. Configure the database in Dedicated Server Mode.

     3. Enter the recommended initial buffer pool sizes or set them according to the business needs:
        • db_block_size = 8192
        • db_cache_size = 300M
        • db_files = 1024
        • log_buffer = 65536
        • open_cursors = 1500
        • pga_aggregate_target = 200M
        • pre_page_sga = true
        • processes = 300
        • shared_pool_size = 200M

   • Create a SQL Server database:
     1. Install SQL Server.
     2. Set Collation to case-sensitive.

     Install SQL Server with the appropriate portal database collation so that your tempdb collation setting matches the collation we use for the property extension database. The tempdb collation is inherited from the master database, which you set when you install SQL Server.

3. Define the DbDriver and DbLibrary parameter values:

   1. cd WP_PROFILE/ConfigEngine/properties

   2. Edit wkplc_dbtype.properties

   3. Set the following parameters under the appropriate database type properties heading:
      • db_type.DbDriver
      • db_type.DbLibrary

   4. Save the changes.

4. Edit wkplc.properties

5. Set parameters under the VMM Federated Database Properties heading:
   federated.db.DataSourceName
   federated.db.DbType
   federated.db.DbUrl
   federated.db.id
   federated.db.baseDN
   federated.db.DbUser
   federated.db.DbPassword
   federated.db.DbName

6. Set SOAP request timeout...

   1. cd WP_PROFILE/properties

   2. Edit soap.client.props

   3. Locate com.ibm.SOAP.requestTimeout and ensure the value is greater than 1000.

   4. Save and close soap.client.props.

7. Complete the following steps in a clustered environment:

   1. Create the local dmgr WebSphere variable used to access the database jars...

       
      ./ConfigEngine.sh wp-prep-vmm-db-secured-environment \
                        -DWasPassword=foo \
                        -DDbDomain=federated.db \
                        -Ddb_type.DmgrDbLibrary=/path/to/db/jars \
                        -DDmgrNodeName=dmgr_node_name
      

      Set db_type to your database type, for example db2.

      Set path to DB jar files on the dmgr host:

      DB2 Type 2 driver	db2java.zip
      DB2 Type 4 driver	db2jcc4.jar;db2jcc_license_cu.jar
      DB2 for z/OS Type 2 driver	db2java.zip
      DB2 for z/OS Type 4 driver	db2jcc4.jar;db2jcc_license_cisuz.jar
      Oracle	ojdbc14.jar
      SQL Server JDBC driver	sqljdbc.jar

   2. Include each node name as a comma separated list in the command:

      You do not have to run this task more than once. We can run this task from any node in the cluster.

      Set the property value for federated.db.DbType in wkplc.properties if using a database user registry or if the cell is migrated from a previous version and create the variable used to access the VMM database jars...

       
      ./ConfigEngine.sh wp-node-prep-vmm-db-secured-environment \
                        -DWasPassword=foo \
                        -DDbDomain=federated.db \
                        -DVmmNodeName=node_name \
                        -Ddb_type.NodeDbLibrary=/path/to/db/jars
      

      VmmNodeName is a list of one or more nodes names in the cell which share the same database driver paths. The db_type in db_type.NodeDbLibrary should be set to the type of database we are using, for example db2.

   3. Stop and restart all necessary servers to propagate the changes.

8. To add a database user registry to the default federated repository...
   ./ConfigEngine.sh wp-create-db -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 servers, dmgrs, and node agents.

10. 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. To delete the old attributes before adding the new attributes...
       ./ConfigEngine.sh wp-set-entitytypes -DWasPassword=foo

    5. Stop and restart all necessary servers to propagate the changes.

11. List the names and types of configured repositories...
    ./ConfigEngine.sh wp-query-repository

Configure a property extension database on AIX

Configure a property extension database to store attributes the LDAP directory does not or cannot store, but which to include in the portal user registry. For example, if the LDAP directory does not allow schema extensions for new attributes. A property extension database extends the user registry, making new attributes available as part of the portal user profile.

• Configure portal security with the main user registry before configuring the property extension database.

  The property extension database configuration becomes unavailable if you complete the steps in this task on the out-of-the-box security configuration, and then configure portal security with the main user registry.

• Due to a limitation with VMM, there are no tasks to update attributes.

  To change an attribute, first remove the attribute then add it again. For this reason, ensure you spell all attributes correctly and use caution when adding attributes to the property extension database.

• The VMM database schema has a limit of 36 characters on the repository ID column.

Configure a property extension database

1. This task requires server connections.

   • In a standalone environment, ensure the WebSphere_Portal server is running.

   • In a clustered environment, stop all appservers on the system including the WebSphere_Portal server and then start the nodeagent and dmgr servers.

2. Install the required .ear file on WebSphere Application Server.
   cd WP_PROFILE/ConfigEngine
   ./ConfigEngine.sh wp-la-install-ear -DWasPassword=foo

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

4. Set up a new database, including creating a new user with appropriate database privileges:

   • Create a DB2 database:
     1. Install DB2.

     2. Enter the following database tuning commands:

        db2 "CREATE DB dbname using codeset UTF-8 territory us PAGESIZE 8192"
        db2 "UPDATE DB CFG FOR dbname USING applheapsz 4096"
        db2 "UPDATE DB CFG FOR dbname USING app_ctl_heap_sz 1024"
        db2 "UPDATE DB CFG FOR dbname USING stmtheap 32768"
        db2 "UPDATE DB CFG FOR dbname USING dbheap 2400"
        db2 "UPDATE DB CFG FOR dbname USING locklist 1000"
        db2 "UPDATE DB CFG FOR dbname USING logfilsiz 4000"
        db2 "UPDATE DB CFG FOR dbname USING logprimary 12"
        db2 "UPDATE DB CFG FOR dbname USING logsecond 20"
        db2 "UPDATE DB CFG FOR dbname USING logbufsz 32"
        db2 "UPDATE DB CFG FOR dbname USING avg_appls 5"
        db2 "UPDATE DB CFG FOR dbname USING locktimeout 30"
        db2 "UPDATE DB CFG FOR dbname using AUTO_MAINT off"
        

   • Create an Oracle database:

     1. Install Oracle using UNICODE Database and National character sets such as UTF8, AL32UTF8, or AL16UTF16.

     2. Configure the database in Dedicated Server Mode.

     3. Enter the recommended initial buffer pool sizes or set them according to the business needs:
        • db_block_size = 8192
        • db_cache_size = 300M
        • db_files = 1024
        • log_buffer = 65536
        • open_cursors = 1500
        • pga_aggregate_target = 200M
        • pre_page_sga = true
        • processes = 300
        • shared_pool_size = 200M

   • Create a SQL Server database:

     1. Install SQL Server.

     2. Set Collation to case-sensitive.

     Install SQL Server with the appropriate portal database collation so that your tempdb collation setting matches the collation we use for the property extension database. The tempdb collation is inherited from the master database, which you set when you install SQL Server.

5. Define the DbDriver and DbLibrary parameter values:

   1. cd WP_PROFILE/ConfigEngine/properties

   2. Edit wkplc_dbtype.properties

   3. Set the following parameters under the appropriate database type properties heading:
      • db_type.DbDriver
      • db_type.DbLibrary

   4. Save the changes.

6. Specify values for the data source parameters in wp_add_LA.properties.

   1. cd WP_PROFILE/ConfigEngine/config/helpers

   2. Edit wp_add_LA.properties

   3. Specify values for the following parameters:
      • la.JdbcProviderName
      • la.DbType
      • la.DbUrl
      • la.DbName
      • la.DataSourceName
      • la.DbUser
      • la.DbPassword

      Add the following parameters to wp_add_LA.properties if we are setting up the property extension database on a clustered environment:

      • la.schemaLocation=/path/to/dmgr/AppServer/etc/wim/setup
      • la.laPropXML=/path/to/dmgr/AppServer/etc/wim/setup/wimlaproperties.xml

      where /path/to/dmgr is the local path on the dmgr node.

   4. Save and close wp_add_LA.properties.

7. Set SOAP request timeout...

   1. cd WP_PROFILE/properties

   2. Edit soap.client.props

   3. Locate com.ibm.SOAP.requestTimeout and ensure the value is greater than 1000.

   4. Save and close soap.client.props.

8. If we are completing this task in a single server environment, proceed to the next step. If you have a clustered environment:

   Create the local dmgr WebSphere variable used to access the database jars...

    
   cd WP_PROFILE/ConfigEngine 
   ./ConfigEngine.sh wp-prep-vmm-db-secured-environment \
                     -DWasPassword=foo \
                     -DDbDomain=la \
                     -Ddb_type.DmgrDbLibrary=/path/to/db/jars \
                     -DDmgrNodeName=dmgr_node_name
   

   Set db_type to your database type, for example db2.

   Set path to DB jar files on the dmgr host:

   DB2 Type 2 driver	db2java.zip
   DB2 Type 4 driver	db2jcc4.jar;db2jcc_license_cu.jar
   DB2 for z/OS Type 2 driver	db2java.zip
   DB2 for z/OS Type 4 driver	db2jcc4.jar;db2jcc_license_cisuz.jar
   Oracle	ojdbc14.jar
   SQL Server JDBC driver	sqljdbc.jar

9. Set la.DbType in wp_add_LA.properties then create the variable used to access the VMM database jars...

    
   ./ConfigEngine.sh wp-node-prep-vmm-db-secured-environment \
                     -DWasPassword=foo \
                     -DDbDomain=la \
                     -DVmmNodeName=node_name,node_name,node_name \
                     -Ddb_type.NodeDbLibrary=/path/to/db/jars
   

   VmmNodeName is a list of one or more nodes names in the cell which share the same database driver paths. Include each node name as a comma separated list in the command. The db_type in db_type.NodeDbLibrary should be set to the type of database we are using, for example db2.

10. Stop and restart all necessary servers to propagate the changes.

11. Add a property extension repository to the federated or stand-alone LDAP repository.

     
    cd WP_PROFILE/ConfigEngine 
    ./ConfigEngine.sh wp-configure-la-complete \
                      -DWasPassword=foo \
                      -DparentProperties=/path/to/profiles/wp_profile/ConfigEngine/config/helpers/wp_add_LA.properties
    

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

13. Specify values for the following parameters in wp_add_LA.properties.

    Add several attributes: You must add attributes to the property extension database one at a time. Complete this step to specify the parameters for a specific attribute then complete the next step to run the task to add that attribute. Repeat both steps for each attribute you plan to add.

    1. cd WP_PROFILE/ConfigEngine/config/helpers

    2. Edit wp_add_LA.properties

    3. Specify values for the following parameters:
       • la.providerURL
       • la.propertyName
       • la.entityTypes
       • la.dataType
       • la.multiValued

       Available dataType parameters are defined in com.ibm.websphere.wim.SchemaConstants:

       • String
       • Int
       • Date
       • AnySimpleType
       • AnyURI
       • Boolean
       • Long
       • Double
       • Short

       See: Configure a property extension repository in a federated repository configuration.

       Constant values of DATA_TYPE_* fields are valid input for la.dataType. Only the String data type is valid for displaying attributes in the Profile Management portlet. These attributes can be added to the Profile Management portlet through the configuration mode interface.

14. Add the attribute to the property extension database.

     
    cd WP_PROFILE/ConfigEngine 
    ./ConfigEngine.sh wp-add-la-property \
                      -DWasPassword=foo \
                      -DparentProperties=/path/to/profiles/wp_profile/ConfigEngine/config/helpers/wp_add_LA.properties 
    

    The attributes become available in the property extension database.

15. Add the attributes to Web Content Manager if we use web content user profiling and/or Category selection trees.

    Set la.providerURL in wp_add_LA.properties then run...

     
    cd WP_PROFILE/ConfigEngine 
    ./ConfigEngine.sh add-wcm-la-attributes \
                      -DWasPassword=foo \
                      -DparentProperties=/path/to/profiles/wp_profile/ConfigEngine/config/helpers/wp_add_LA.properties
    

    If the path name contains blank space, enclose the path in quotation marks.

    This task makes an EJB call to WAS, which requires authentication. You may receive a prompt asking for authentication. Enter the appropriate WAS user ID and password.

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

17. If you created the clustered environment, including the additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

Change from a stand-alone repository to a federated repository on AIX

If you originally configured a standalone LDAP user registry but find that you need a more robust security configuration, we can change to the federated user repository.

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

Change from a standalone LDAP user registry to a federated repository

To ensure correct properties, use...

WP_PROFILE/ConfigEngine/config/helpers/wp_security_federated.properties

In the following instructions, where the step refers to wkplc.properties, use the wp_security_federated.properties helper file.

1. Edit wkplc.properties

2. Set the following required parameters under VMM Federated repository properties:
   
   federated.primaryAdminId
   federated.realm
   federated.serverId
   federated.serverPassword

3. Save changes to wkplc.properties.

4. Change the configuration to use a federated repository...

    
   ./ConfigEngine.sh wp-modify-federated-security \
                     -DWasPassword=foo \
                     -Dskip.ldap.validation=true
   

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

If you created the clustered environment, including the additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

Update the base entry on AIX

After creating the base entries, we might need to update the DN in the repository that uniquely identifies the base entry name. This task applies only to federated repository configurations. This task does not update the base DN entry if we use a stand-alone repository.

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

Update the base entry

1. Edit wkplc.properties

2. Set the following parameters:
   • id
   • baseDN
   • nameInRepository

3. Save changes to wkplc.properties.

4. Update a base entry in a repository...
   ./ConfigEngine.sh wp-update-base-entry

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

If you created the clustered environment, including the additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

Update the database user registry on AIX

After creating and using the database user registry, we can run wp-update-db to update the database user ID, password, and/or the database where the data is stored. This task does not change the DN structure stored in the database repository.

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

To change the database where data is stored, populate the new database with all necessary VMM tables and create the data sources in WebSphere Application Server before running wp-update-db.

After populating the new database with the VMM tables and creating the data sources, restart the WebSphere_Portal server.

If we are changing the database administrator password, complete the steps in Change database passwords used by WebSphere Portal before running wp-update-db.

Update the database user registry in the default federated repository

To help ensure correct properties, we can use...

WP_PROFILE/ConfigEngine/config/helpers/wp_add_DB.properties

1. Edit wkplc.properties

2. Update the value for the following required parameters in wkplc.properties under the Federated DB repository heading:
   
   federated.db.DataSourceName
   federated.db.DbType
   federated.db.DbUrl
   federated.db.id
   federated.db.DbUser
   federated.db.DbPassword

3. Save changes to wkplc.properties.

4. Add a database user registry to the default federated repository...
   ./ConfigEngine.sh wp-update-db -DWasPassword=foo

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

If you created the clustered environment, including the additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

Update the federated LDAP user registry on AIX

The update federated LDAP user registry task does not modify the administrative users, the entity types, the LDAP entity types, the LDAP group membership attributes, the LDAP group configuration, or the LDAP context pool. See the separate tasks for updating these parameters.

Update the LDAP user registry in the default federated repository

1. Set your values in the parent properties helper file...
   WP_PROFILE/ConfigEngine/config/helpers/wp_add_federated_xxx.properties

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

3. Edit wkplc.properties

4. Identify the existing LDAP user registry to update:
   federated.ldap.id
   federated.ldap.host
   federated.ldap.baseDN
   federated.ldap.ldapServerType

5. Under the Federated LDAP repository heading set:
   federated.ldap.port
   federated.ldap.bindDN
   federated.ldap.bindPassword

6. Save changes to wkplc.properties.

7. Validate the LDAP server settings...
   ./ConfigEngine.sh validate-federated-ldap -DWasPassword=foo

   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. Update the LDAP user registry in the default federated repository...
   ./ConfigEngine.sh wp-update-federated-ldap -DWasPassword=foo

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

If you created the clustered environment, including the additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

Update the realm configuration on AIX

After creating and using the realm(s) in the default federated repository, you may find that the realm configuration is not working exactly as you would like. We can update the realm configurations and make the necessary changes.

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

Update the realm configuration in the default federated repository

1. Edit wkplc.properties

2. Set the following required parameters under the VMM realm configuration heading:
   • realmName
   • securityUse
   • delimiter

3. Save changes to wkplc.properties.

4. Update a realm configuration...
   ./ConfigEngine.sh wp-update-realm -DWasPassword=foo

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

If you created the clustered environment, including the additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

Create the entity type on AIX

If an entity type exists within IBM WebSphere Portal to use but it does not exist within the LDAP user registry, we can create the entity type within the LDAP user registry and then add the relative distinguished name (RDN) to the entity type to map it between WebSphere Portal and the LDAP user registry.

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

Create entity types in the LDAP user registry

1. List the names and types of configured repositories.
   cd WP_PROFILE/ConfigEngine
   ./ConfigEngine.sh wp-query-repository -DWasPassword=foo

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

3. Enter the following parameters...
   • et.ldap.id
   • et.entityTypeName
   • et.objectClass
   • et.searchFilter
   • et.objectClassesForCreate
   • et.searchBases

4. Save changes wkplc.properties

5. Create an LDAP entity type...
   cd WP_PROFILE/ConfigEngine
   ./ConfigEngine.sh wp-create-ldap-entitytype -DWasPassword=foo

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

7. Edit wkplc.properties and set...
   • et.ldap.id
   • et.entityTypeName
   • et.objectClass
   • et.searchFilter
   • et.objectClassesForCreate
   • et.searchBases
   • et.rdnName

8. Save changes

9. To add an LDAP entity type with a relative DN...
   cd WP_PROFILE/ConfigEngine
   ./ConfigEngine.sh wp-add-ldap-entitytype-rdn -DWasPassword=foo

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

If you created a cluster, including additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

Update an entity type on AIX

After adding the user registry, you may find that update a single entity type with the value of the default parent.

For example, if you delete a repository, you will need to update the entity type if it points to the deleted repository.

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

Update an entity type

1. Edit wkplc.properties

2. Enter the following parameters under VMM supported entity types configuration heading:
   • entityTypeName
   • defaultParent
   • rdnProperties

3. Save changes to wkplc.properties.

4. Choose one of the following tasks to update the entity type:

   To add a new entity type to the existing list

   ./ConfigEngine.sh wp-update-entitytype -DWasPassword=foo

   To delete the old entity types before adding the new RDN attribute as the only entry in the RDN list

   ./ConfigEngine.sh wp-set-entitytype -DWasPassword=foo

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

If you created the clustered environment, including the additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

Update a group member on AIX

After creating the LDAP user registry, you may find that the group member is not correct. We can update the group member in the LDAP user registry configuration.

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

Update the group member in the LDAP user registry

1. List the names and types of configured repositories...
   ./ConfigEngine.sh wp-query-repository

2. Edit wkplc.properties

3. Set the following required parameters under the VMM LDAP group member attribute configuration heading:
   • gm.ldap.id
   • gm.groupMemberName
   • gm.objectClass
   • gm.scope
   • gm.dummyMember

4. Save changes to wkplc.properties.

5. To update the group member information for your LDAP user registry or to create the group member if it does not exist...
   ./ConfigEngine.sh wp-update-ldap-groupmember -DWasPassword=foo

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

If you created the clustered environment, including the additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

Update the stand-alone LDAP user registry on AIX

Changing the LDAP bind password removes any existing attribute mappings. Review all existing attribute mappings before proceeding so we can re-create them after completing this task.

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

If you need to rerun wp-modify-ldap-security to change the LDAP repositories or because the task failed, choose a new name for the realm using the standalone.ldap.realm parameter or set ignoreDuplicateIDs=true in wklpc.properties, before rerunning the task.

Update the stand-alone LDAP user registry

We can use WP_PROFILE/ConfigEngine/config/helpers/wp_security_xxx.properties to ensure correct properties.

1. Edit wkplc.properties

2. Identify the stand-alone LDAP user registry to update:
   standalone.ldap.id

3. Specify values as required for any parameters that begin with standalone.ldap under the Standalone LDAP repository heading in wkplc.properties. The task you run updates all stand-alone LDAP properties.

4. Specify a new realm name in wkplc.properties.

   1. Locate the following parameter under the Standalone LDAP repository heading: standalone.ldap.realm.

   2. Specify a new realm name as the value for the parameter.

      For example, change...

      standalone.ldap.realm=PortalDev

      ...to...

      standalone.ldap.realm=DevPortal

5. Save changes to wkplc.properties.

6. Validate the LDAP server settings...
   ./ConfigEngine.sh validate-standalone-ldap -DWasPassword=foo

   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.

7. Update the stand-alone LDAP user registry
   1. ./stopServer.sh WebSphere_Portal -username wpadmin -password foo
   2. ./ConfigEngine.sh wp-update-standalone-ldap -DWasPassword=foo
8. Stop and restart servers, dmgrs, and node agents.

If you created the clustered environment, including the additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

This task removed any attribute mappings that we added since you enabled the stand-alone LDAP user registry. Therefore, you must re-run the mapping attribute task. The instructions are located in the installing WebSphere Portal section.

Choose the appropriate operating system and then the appropriate deployment option. The mapping topic is then located in the "Configuring WebSphere Portal to use a user registry" topic under Adapting the attribute configuration.

Update the group membership configuration on AIX

When you configure your LDAP user registry, a group membership is automatically created. You may need to adjust the group membership configuration if you notice high loads on the LDAP server and/or long response times on authentication requests.

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

Update the group membership configuration

1. Edit wkplc.properties

2. Update the following required parameters in wkplc.properties under the VMM LDAP group member config heading:
   • gc.ldap.id
   • gc.name
   • gc.updateGroupMembership
   • gc.scope

3. Save changes to wkplc.properties.

4. Update the group membership for the LDAP user registry...
   ./ConfigEngine.sh wp-create-ldap-groupconfig -DWasPassword=foo

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

If you created the clustered environment, including the additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

Update the context pool configuration on AIX

After configuring the LDAP user registry, you may find that you need to adjust the number of context instances concurrently maintained by the content pool in order to increase performance.

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

Update the context pool configuration

1. Edit wkplc.properties

2. Update the following required parameters in wkplc.properties under the VMM LDAP context pool heading:
   • cp.ldap.id
   • cp.maxPoolSize

3. Save changes to wkplc.properties.

4. Update the context pool configuration for the LDAP user registry...
   ./ConfigEngine.sh wp-update-ldap-contextpool -DWasPassword=foo

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

If you created the clustered environment, including the additional nodes, and then completed the steps in this task, run update-jcr-admin on the secondary nodes.

See also

Start and stop servers, dmgrs, and node agents
Enable LDAP security after cluster creation