+

Search Tips   |   Advanced Search


Mapping attributes on Windows in a clustered environment

After installing the LDAP user registry querying the defined attributes, you can map the attributes so they match the configured LDAP servers.

Perform the following steps to map attributes between WebSphere Portal and your LDAP server; if you have multiple LDAP servers, perform these steps for each LDAP server:

  1. Edit

      profile_root/ConfigEngine/properties/wkplc.properties

    .

  2. Enter a value for one of the following sets of parameters in wkplc.properties to identify your LDAP server:

    Make sure you use the same values used to configure your LDAP server.

    Option Description
    Standalone The following parameters are found under the LDAP attribute configuration heading:

    Federated The following parameters are found under the VMM Federated repository properties heading:

  3. Run one of the following tasks to check that all defined attributes are available in the configured LDAP user registry:

    Option Description
    Standalone ConfigEngine.bat wp-validate-standalone-ldap-attribute-config -DWasPassword=password task, from the profile_root/ConfigEngine directory
    Federated ConfigEngine.bat wp-validate-federated-ldap-attribute-config -DWasPassword=password task, from the profile_root/ConfigEngine directory

  4. Open the config trace file to 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 all attributes that are 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 that you plan to use to the attributes that exist in the LDAP; also 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 all attributes that are defined as "MUST" in the LDAP server but not as required in WebSphere Portal.

    You should flag these attributes as required within WebSphere Portal; see the step below about flagging an attribute as either unsupported or required.

    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

      profile_root/ConfigEngine/properties/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:

    Option Description
    Standalone The following parameters are found under the LDAP attribute configuration heading:

    For example, the following values will flag certificate and members as unsupported attributes and will 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 The following parameters are found under the VMM Federated repository properties heading:

    For example, the following values will flag certificate and members as unsupported attributes and will 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. Run one of the following tasks to update the LDAP user registry configuration with the list of unsupported attributes and the proper mapping between WebSphere Portal and the LDAP user registry:

    Option Description
    Standalone ConfigEngine.bat wp-update-standalone-ldap-attribute-config -DWasPassword=password task, from the profile_root/ConfigEngine directory
    Federated ConfigEngine.bat wp-update-federated-ldap-attribute-config -DWasPassword=password task, from the profile_root/ConfigEngine directory

  9. Propagate the security changes:

    Option Description
    Standalone

    1. cd profile_root/bin
      stopServer.bat server1 -username admin_userid -password admin_password

    2. cd profile_root/bin
      stopServer.bat WebSphere_Portal -username admin_userid -password admin_password

    3. cd profile_root/bin
      startServer.bat server1

    4. cd profile_root/bin
      startServer.bat WebSphere_Portal

    Cluster

    1. cd dmgr_profile/bin
      stopManager.bat-username admin_userid -password admin_password

    2. cd profile_root/bin
      stopNode.bat-username admin_userid -password admin_password

    3. cd profile_root/bin
      stopServer.bat WebSphere_Portal -username admin_userid -password admin_password

    4. cd dmgr_profile/bin
      startManager.bat

    5. cd profile_root/bin
      startNode.bat

    6. cd profile_root/bin
      startServer.bat WebSphere_Portal

  10. Optional: Perform the following steps to flag an attribute as either unsupported or required for the entire WebSphere Portal environment instead of just for the specified LDAP:

    1. Enter a value for the following parameters in wkplc.properties:

    2. Save changes to wkplc.properties.

    3. Run...

        ConfigEngine.bat wp-update-attribute-config -DWasPassword=password task, from the profile_root/ConfigEngine directory.

      • Cycle all necessary servers to propagate changes.

If you performed these steps after creating the clustered environment, run enable-jcr-security on the secondary node.


Parent topic:

Adapting the attribute configuration


Previous topic:

Add attributes on Windows in a clustered environment


Next topic:

Remove attributes


Related tasks


Enable LDAP security after cluster creation