Mapping attributes between LDAP and WebSPhere Portal

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


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

o Stand alone: ConfigEngine.sh wp-validate-standalone-ldap-attribute-config

o Federated: ConfigEngine.sh wp-validate-federated-ldap-attribute-config



* 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; you must 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.

* Enter a value for one of the following sets of parameters in the wkplc.properties file to correct any issues found in the config trace file:
The following parameters are found under the LDAP attribute configuration heading:

* standalone.ldap.id
* standalone.ldap.attributes.nonSupported
* standalone.ldap.attributes.nonSupported.delete
* standalone.ldap.attributes.mapping.ldapName
* standalone.ldap.attributes.mapping.portalName
* standalone.ldap.attributes.mapping.entityTypes

* 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:

o Standalone :ConfigEngine.sh wp-update-standalone-ldap-attribute-config

o Federated: ConfigEngine.sh wp-update-federated-ldap-attribute-config

Restricting authentication based on group membership when configured for standalone LDAP

Question
How do you configure IBM WebSphere Portal so that only members of a specific group can log in if WebSphere Portal security is configured to use a standalone LDAP?

Answer

The same general steps will be taken for each supported LDAP although the specific userFilter will differ depending on the LDAP brand and/or version.

First, check with your LDAP administrator to confirm that your LDAP implements an attribute whereby group membership is specified within each user record. The IBM® Redbooks® publication, "IBM WebSphere Portal V6 Self Help Guide", lists the default attributes used for memberOfAttributeName support in several supported LDAPs in table 5-15 on page 155.

If your LDAP implements one of these attributes, verify that it can be used to properly identify the subset of users who should be allowed to authenticate to the Portal server. Check the userFilter in the wkplc.properties file: (This assumes the userFilter in wkplc.properties was not edited since originally enabling security. You can likewise refer to the ConfigEngine helper files for your LDAP to help construct your userFilter.)

standalone.ldap.userFilter=(&(cn=%v)(objectclass=inetOrgPerson))

Test the search filter using ldapsearch prior to making any changes to the WebSphere Portal configuration. Your ldapsearch might look something like:

ldapsearch -x -v -D -w -h -p -b (&(objectclass=inetOrgPerson)(groupMembership=))

(This example uses Novell eDirectory's groupMembership attribute.)

If the search succeeds, add the (cn=%v) back to the userFilter, then back up and update wkplc.properties as follows:

standalone.ldap.userFilter=(&(cn=%v)(objectclass=inetOrgPerson)(groupMembership=))

( is a distinguished name and might be something like cn=portalgroup,o=yourOrganization.)

Update the WebSphere Portal and WebSphere Application Server security configurations by running wp-modify-ldap-security as described in the Information Center v6.1:

WebSphere Portal > Installing WebSphere Portal > Setting up WebSphere Portal > Setting up a (standalone/clustered) production server > Configuring WebSphere Portal to use a user registry > Configuring WebSphere Portal to use a user registry on (your OS) > Choosing your user registry model on (your OS) > Configuring a stand-alone LDAP user registry on (your OS)

Users should now be authenticated only if they belong to the group identified by above.

Using ldapsearch to debug LDAP configuration problems

Problem(Abstract)
How to using ldapsearch to debug LDAP configuration problems with IBM® WebSphere® Application Server?



Resolving the problem
There are many things which may prevent your LDAP configuration from working properly.
DN = Distinguished Name
ACL = Access Control List

· DN not in ACL and therefore cannot perform certain ldap queries
· DN was locked out of ldap due to too may failed login attempts
· DN password may have been changed
· LDAP server may not allow anonymous queries
· Default filter defined in Application Server may not fit customers' settings.(i.e. no objectclass=someObjectClass defined)
· Firewall not allowing communication on port
· LDAP set to use nonstandard port of 389
· LDAP administrator ID used for Server ID but the administrator's ID is not defined as a regular user

For these and numerous other possible configuration problems the best way to quickly debug the problem is to do an ldapsearch. Ldapsearch is a utility similar to what Application Server uses to query the ldap server but is used on the command line. This removes Application Server from the picture and allows you to see what is being returned from the query, normally hidden by Application Server.

The idea is use the same configuration settings, on the command line, as you have defined in Application Server’s Administrative console > Security > user Registries > LDAP settings.

Security Server ID Short name of the ID which is queried from LDAP.
Security Server Password ID’s password in LDAP
Directory Type Predefined list of supported LDAP servers. Selecting the proper Directory updates the filters defined under the Advanced properties. These can be changed.
Host Hostname of LDAP server. Can be short name, long name, or IP address.
Port 389 is the default LDAP port
Base Distinguished Name
(BaseDN) Query starting location in your LDAP tree
Bind Distinguished Name
(BindDN) Fully qualified DN which has the authority to “bind” to your LDAP server and preform the requested queries. Some LDAP servers allow for anonymous queries so no bind DN and bind password may be required
Bind Password Bind DN’s password.

LDAP advanced properties User Filter The string used to query the LDAP server.
User ID Map Defines what gets displayed in WebSphere from resulting query.

ldapsearch –h -p -b “” –D -w “”

Note: The “%v” in the gets replaced by the
For example, instead of "(&(cn=%v)(objectclass=ePerson))" use "(&(cn=bob)(objectclass=ePerson))"

Example ldapsearch queries
C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" uid=test
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test

C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" "(&(uid=test)(objectclass=ePerson))"
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test

Ldapsearch queries which would cause an exception for Application Server:

The following would fail in Application Server because the search filter is looking for an objectclass of “XYZ” but there is no “XYZ” objectclass defined LDAP. This results in an empty return string.

C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" "(&(uid=test)(objectclass=XYZ))"

The following search would fail in Application Server because 2 DN’s are returned instead of 1. Application Server will only authenticate using a single DN. If the query was uid=test instead of cn=test, then only one DN would have been returned.

C:\>ldapsearch -h petunia -p 389 -b "o=ibm,c=us" "(&(cn=test)(objectclass=ePerson))"
cn=test,o=ibm,c=us
sn=test
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
uid=test
cn=test

cn=test,ou=Larry's Group,ou=Austin,o=ibm,c=us
sn=User
objectclass=top
objectclass=organizationalPerson
objectclass=ePerson
objectclass=person
objectclass=inetOrgPerson
cn=Test

How to get user ID of logged-in user from LDAP

How do you retrieve the user ID of a logged-in user from the LDAP instead of the user name which may not be unique?

There are two ways to achieve this :
1. Setting the "api.use.dn" parameter in WCMConfigService.properties to True gives you the distinguished name (DN) of the user instead of the display name when calling the getUserName() method.

2. You can dynamically set this by calling

"workspace.useDistinguishedNames(true)" before calling "workspace.getUserProfile()".
Essentially this would be similar to the following:

Workspace workspace = p_contextProcessorParams.getWorkspace();
workspace.useDistinguishedNames(true);
String currentCust = CustContextProcessorUtils.getCustomer(workspace.getUserProfile().getUsername());

Implementing LDAP failover with WebSphere Portal

Problem:
Can WebSphere® Portal support the usage of a network dispatcher to forward LDAP requests to multiple LDAP servers? Can WebSphere Member Manager be leveraged to support LDAP failover?

Answer

Implementing clustered LDAP systems in a WebSphere Portal environment for failover purposes can be achieved using either of the following methods:

1) An environment that implements a network dispatcher and clustered LDAP servers can be successfully integrated into a WebSphere Portal environment. The communication between the dispatcher and the LDAP cluster members should be transparent to the portal server and its LDAP interface, WebSphere Member Manager (WMM). Only the network dispatcher host address would be referenced in the /wmm/wmm.xml:

. . . . .
ldapHost=""
. . . . .
>

Unless you have configured realm support security for WebSphere Portal, such a setup also requires you to disable the "Reuse Connection" feature of WebSphere Application Server (if dispatcher doesn't support session affinity) and set the dispatcher address as the LDAP hostname. These settings can be accessed using the WebSphere Application Server Administration Console via Security->User Registries-->LDAP.

This is the recommended option for setting up WebSphere Portal to take advantage of LDAP failover.

2) If you are not able to implement a network dispatcher, a second option exists which can be implemented in one of two supported environments:

a) WebSphere Portal 5.1/6.0 on WebSphere Application Server 6.0.2 or later (See the link at the end of this document for details on configuring WebSphere Application Server 6.0.2.x for multiple LDAP servers)

b) WebSphere Portal 5.1.x on WebSphere Application Server 5.1.1.x or 6.x versions less than 6.0.2 using WMM realm support security. WebSphere Application Server does not support LDAP failover until version 6.0.2, but WMM realm support results in WMM handling all LDAP connections and the lack of WebSphere Application Server support is not an issue.

The following details regarding WebSphere Member Manager apply to both of the above supported environments in a) and b).

Starting in Member Manager 5.1, Member Manager can utilize the multiple URLs support in the Java 2 SDK, v1.4.1. This means that Member Manager can be configured to connect to multiple LDAP servers in turn until it is able to create a successful connection. This new feature can be implemented in WebSphere Portal 5.1/6.0 by adding a JNDI environment parameter to the /wmm/wmm.xml:

java.naming.provider.url=" "

Note that there is a space between each URL and more than two URLs can be defined.

When implementing this feature, Support strongly recommends installing the latest Member Manager Cumulative fix (see links under Related information) and then using the following additional parameter to set a limit on the amount of time (in milliseconds) WMM will wait for an established connection before moving onto the next LDAP in the list:

connectTimeOut=""

If the above parameter is not set, then the default behavior is to wait until the connection is established or the underlying network times out. This default behavior can lead to performance issues in WebSphere Portal.

For example:

...
adminId="cn=root"
adminPassword="xxxxxx"
ldapHost=""
ldapPort=""
connectTimeOut="500"
java.naming.provider.url="ldap://:389 ldap://:389"
...
>

The above example assumes that you have two LDAP servers, a primary and a backup. The backup and primary servers are synchronized to have identical content (including your adminID and adminPassword). You want WMM to use the backup server if the primary server is unavailable.

If you are using an SSL connection for LDAP, this parameter can look like the following:

java.naming.provider.url="ldap://:636 ldap://:636"

Note that once you set this parameter, the parameters ldapHost and ldapPort are overwritten by the LDAP addresses and ports specified in this parameter.

If the primary server goes down, and WMM then reverts to the backup server, WMM will continue to use the backup server until the backup server becomes unavailable.