+

Search Tips   |   Advanced Search

Mapping attributes on Linux in a clustered environment


After configuring the LDAP user registry and querying the defined attributes, map attributes between portal and the LDAP server; for multiple LDAP servers, complete these steps for each LDAP server:

  1. Edit wkplc.properties

  2. Identify the LDAP server:

    Repository Parameters
    Standalone

    Federated

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

    Repository Task
    Standalone cd WP_PROFILE/ConfigEngine
    ./ConfigEngine.sh wp-validate-standalone-ldap-attribute-config -DWasPassword=foo
    Federated cd WP_PROFILE/ConfigEngine
    ./ConfigEngine.sh wp-validate-federated-ldap-attribute-config -DWasPassword=foo

  4. Edit...

      WP_PROFILE/ConfigEngine/log/ConfigTrace.log

    ......and review the following output for the PersonAccount and Group entity type:

      The following attributes are defined in WebSphere Portal but not in the LDAP server

      This list contains attributes defined in WebSphere Portal but not available in the LDAP. Flag attributes that you do not plan to use in WebSphere Portal as unsupported. Map the attributes to use to the attributes that exist in the LDAP; map the uid, cn, firstName, sn, preferredLanguage, and ibm-primaryEmail attributes if they are contained in the list.

      The following attributes are flagged as required in the LDAP server but not in WebSphere Portal

      This list contains attributes defined as "MUST" in the LDAP server but not as required in WebSphere Portal. You should flag these attributes as required within WebSphere Portal;

      The following attributes have a different type in WebSphere Portal and in the LDAP server

      This list contains all attributes that WebSphere Portal might ignore because the data type within WebSphere Portal and within the LDAP server do not match.

  5. Edit wkplc.properties

  6. Enter a value for one of the following sets of parameters in wkplc.properties to correct any issues found in the config trace file:

    Repository Parameters
    Standalone

    For example, the following values flag certificate and members as unsupported attributes and map ibm-primaryEmail to mail and ibm-jobTitle to title for both the PersonAccount and Group entityTypes:

    standalone.ldap.attributes.nonSupported=certificate, members standalone.ldap.attributes.nonSupported.delete=
    
    standalone.ldap.attributes.mapping.ldapName=mail, title standalone.ldap.attributes.mapping.portalName=ibm-primaryEmail, ibm-jobTitle
    standalone.ldap.attributes.mapping.entityTypes=PersonAccount, Group 
    Federated

    For example, the following values flag certificate and members as unsupported attributes and map ibm-primaryEmail to mail and ibm-jobTitle to title for both the PersonAccount and Group entityTypes:

    federated.ldap.attributes.nonSupported=certificate, members federated.ldap.attributes.nonSupported.delete=
    
    federated.ldap.attributes.mapping.ldapName=mail, title federated.ldap.attributes.mapping.portalName=ibm-primaryEmail, ibm-jobTitle
    federated.ldap.attributes.mapping.entityTypes=PersonAccount, Group 

  7. Save changes to wkplc.properties.

  8. Update the LDAP user registry configuration with the list of unsupported attributes and the proper mapping between WebSphere Portal and the LDAP user registry:

    Repository Task
    Standalone cd WP_PROFILE/ConfigEngine
    ./ConfigEngine.sh wp-update-standalone-ldap-attribute-config -DWasPassword=foo
    Federated cd WP_PROFILE/ConfigEngine
    ./ConfigEngine.sh wp-update-federated-ldap-attribute-config -DWasPassword=foo

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

  10. Optional: Flag an attribute as either unsupported or required for the entire WebSphere Portal environment instead of just for the specified LDAP:

    1. Set parameters in wkplc.properties:

    2. Save changes to wkplc.properties.

    3. cd WP_PROFILE/ConfigEngine
      ./ConfigEngine.sh wp-update-attribute-config -DWasPassword=foo

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

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: Linux cluster: Adapt the attribute configuration
Previous: Add attributes on Linux in a clustered environment
Next: Linux cluster: Remove attributes
Related:
Start and stop servers, dmgrs, and node agents
Enable LDAP security after cluster creation