IBM Support

Cannot search users in multiple user directories in my LDAP server configuration

Preventive Service Planning


Abstract

This technote explains how to search users in multiple user directories in my LDAP server configuration in IBM Rational Team Concert.

Content

The solution can be addressed with the use of an LDAP attribute and the configuration and the LDAP search criteria definition within the application server's configuration.
This example will use the LDAP attribute "o"; it is possible that this attribute has been already implemented on your production LDAP server . Speak to your LDAP administrator and ask whether this attribute can be used, or if another attribute can serve the purpose. If another attribute is required, replace the "o" in this document with the attribute value identified as a replacement.

NOTES:

  • This requires a excellent understanding of the LDAP servers and their interfaces. It is important that you discuss this with your LDAP Administrator and have them implement this solution and test it in a staging area beforehand, once you and your LDAP Administrator agree that this tech note should be implemented. If there are any problems with the LDAP implementation, please review the LDAP server documentation and work with your support organization.

  • Your solution does not require the Attribute setup if you are only trying to search multiple LDAP user branches and seeing all users in the IBM Rational Team Concert (RTC) administration tool is not a concern.


Add LDAP attribute to user definition:

The following section shows the original definition of a user call RTCA_1 and the command to add the new attribute definition. The example assumes that the right objectClass</code>] definition has been applied to the user's definition. In this context, objectClass inetOrgPerson contains the attribute definition "o" which has been added to the user's definition.

Original User Definition:

dn: uid=RTCA_1,ou=Users,dc=example,dc=com
objectClass: uidObject
objectClass: extensibleObject
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
cn: RTCA one
sn: one
uid: RTCA_1
givenname: RTCA1
mail: RTCA1@example.com
member: cn=JazzAdmins,ou=Groups,dc=example,dc=com
ou: Users
userpassword:: UnBtZGV2MTlh

Execute LDIF Command against LDAP server:

<Example: LDIF File Add_o_RTC.ldif>

dn: uid=RTCA_1,ou=users,dc=example,dc=com
changetype: modify
add: o
o: RTC

<Example/>

At this point the Attribute "o" with value "RTC" has been added to the LDAP directory service for user RTCA_1. It is important to realize that all users that will log on to RTC will require the new attribute -- the example below speaks of only one user in the LDAP server.

New User Definition (see entry o: RTC):

dn: uid=RTCA_1,ou=Users,dc=example,dc=com
objectClass: uidObject
objectClass: extensibleObject
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: top
cn: RTCA one
sn: one
uid: RTCA_1
givenname: RTCA1
mail: RTCA1@example.com
member: cn=JazzAdmins,ou=Groups,dc=example,dc=com
o: RTC
ou: Users
userpassword:: UnBtZGV2MTlh

Modify search filter criteria for the application server:

Tomcat Application server (embedded with RTC):

See reference: http://jazz.net/library/techtip/92
In the techtip, search for the "LDAP Realm parameters" section and look for the "userSearch" property.

Current properties configuration:

The following configuration will search all user definitions in the LDAP tree starting from the entry point defined in the userBase="ou=Users,dc=example,dc=com" property. This will bypass all user definitions in the "ou=Admins,dc=example,dc=com" entry point, and fail to allow all administrators to be authenticated against RTC -- this is probably not what you want, and can be solved as described below.

<LDAP Realm Properties from file server.xml>

<Realm className="org.apache.catalina.realm.JNDIRealm"
debug="99" connectionURL="ldap://MY_LDAP_SERVER:389"
connectionName="uid=ADMIN,ou=Users,dc=example,dc=com"
connectionPassword="Pa55w0rd"
userSearch="(uid={0})"
userBase="ou=Users,dc=example,dc=com"
userSubtree="true"
roleBase="ou=Groups,dc=example,dc=com"
roleSubtree="false"
roleSearch="(uniquemember={0})"
roleName="cn" />

<LDAP Realm Properties/>

First Solution:

Move the userBase one level up the LDAP tree. This means that the new value for the userBase will be userBase="dc=example,dc=com". This situation will allow administrators to authenticate against RTC, but it will also allow the RTC administrators to start assigning users that are defined in all elements defined under this userBase. But it still does not answer the concern that the security policies do not allow this situation. If you do not have such a concern, then the solution stops here, and it is not required to add the new LDAP attribute.

<LDAP Realm Properties from file server.xml>

<Realm className="org.apache.catalina.realm.JNDIRealm"
debug="99" connectionURL="ldap://MY_LDAP_SERVER:389"
connectionName="uid=ADMIN,ou=Users,dc=example,dc=com"
connectionPassword="Pa55w0rd"
userSearch="(uid={0})"
userBase="dc=example,dc=com"
userSubtree="true"
roleBase="ou=Groups,dc=example,dc=com"
roleSubtree="false"
roleSearch="(uniquemember={0})"
roleName="cn" />

<LDAP Realm Properties/>


Final solution :

Using the "o" attribute in the LDAP server, userSearch can filter the query of the LDAP server to search only the users that have the "o" attribute with values equal to "RTC". The new value for the userSearch would be defined as the following:
userSearch="(&amp;(o=RTC)(uid={0}))"
Why "&amp;"? The reason is that the server.xml file uses the "&" for other purposes and the default format for LDAP filter criteria does not work: Example userSearch="(&(o=RTC)(uid={0}))" where the "&" defines an "AND" condition. The value "&amp;" is a substitute for the "&".

WARNING
Reading the documentation for the JDNIRealm it does mentions that only the "|", OR condition, is supported at some places. It is possible that there may be side affect in using the "&", AND condition, that have not been clearly understood.

<LDAP Realm Properties from file server.xml>

<Realm className="org.apache.catalina.realm.JNDIRealm"
debug="99" connectionURL="ldap://MY_LDAP_SERVER:389"
connectionName="uid=ADMIN,ou=Users,dc=example,dc=com"
connectionPassword="Pa55w0rd"
userSearch="(&amp;(o=RTC)(uid={0}))"
userBase="dc=example,dc=com"
userSubtree="true"
roleBase="ou=Groups,dc=example,dc=com"
roleSubtree="false"
roleSearch="(uniquemember={0})"
roleName="cn" />

<LDAP Realm Properties/>

NOTE:
This filtering criteria definition method is also good for the groups configuration, the attribute "o" can be added to the groups definition to allow this filter to search for groups in different LDAP directories. Apply logic to the property roleSearch. This as long as the entry point is higher then the directory that are being searched by the roleBase property.

It must be noted that the userPattern property can also be used to filter in specific user directories in the LDAP server for example:

    userPattern="(uid={0},ou=Users,dc=example,dc=com)(uid={0},ou=Users2,dc=example,dc=com)" to replace the userSearch, and userBase with this Property.

WebSphere Application server:

See reference: http://jazz.net/library/techtip/96
Section: WAS set up step #6
In Figure see Field: "User Filter"

Current setting for LDAP Field in WebSphere:

LDAP Server setting and search entry point as you can see in figure below that the Base Distinguished name (DN) is set to "dc=example,dc-com". The reason why this is configured in this manner is that if we pointed the entry to the users DN "ou=Users,dc=example,dc=com" The group configuration will not function since the DN for the groups is "ou=groups,dc=example,dc=com" which is not nested in the User's DN. It is at the same level as the User's DN.




The method to make a distinction from the User's and the Groups DN is in this next image. The filter criteria is defined in this section. The "User Filter" field defines what list of users you want to expose from LDAP. This user filter field support any LDAP filter criteria your LDAP server supports. In this example the filter uses the objectClass definition to identify users in combination with the user's uid: (&(uid=%v)(objectclass=inetOrgPerson)) , The "&" defines and AND condition, hence the filter will look for object with the uid and the objectClass inetOrgPerson defined in the LDAP server.





Final Solution:

In this next image, is the final solution, The following User Filter (&(uid=%v)(&(objectclass=inetOrgPerson)(o=RTC))) Will Search for users with the required uid, but it will include the criteria for objectClass "inetOrgPerson" and the "o" objectClass that are equal to "RTC".


NOTE:
This filtering criteria definition method is also good for the groups configuration, the attribute "o" can be added to the groups definition to allow this filter to search for groups in different LDAP directories. Apply logic to the filed "Group Filters"

Reference:
  1. Class org.apache.catalina.realm.JNDIRealm information:
    https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/realm/JNDIRealm.html
  2. Installing Rational Team Concert 2.0 with WebSphere Application Server 6.1.0.25 / 7.0.0.7:
    http://jazz.net/library/techtip/321
  3. Configuring WAS with LDAP realm:
    http://jazz.net/library/techtip/96
  4. User Management in Tomcat:
    http://jazz.net/library/techtip/92


Leverage the Jazz Community
Jazz and Rational Team Concert have an active community that can provide you with additional resources. Browse and contribute to the User forums, contribute to the Team Blog and review the Team wiki.
Refer to technote 1319600 for details and links.

Related information

Class org.apache.catalina.realm.JNDIRealm information
Installing Rational Team Concert 2.0 with WAS
Configuring WAS with LDAP realm
User Management in Tomcat

Document information

More support for: Rational Team Concert
Team Server

Software version: 2.0, 2.0.0.1, 2.0.0.2, 3.0, 3.0.1, 3.0.1.1, 3.0.1.2, 3.0.1.3, 3.0.1.4, 3.0.1.5, 3.0.1.6, 4.0, 4.0.0.1, 4.0.0.2, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5, 4.0.6, 4.0.7, 5.0, 5.0.1, 5.0.2, 6.0, 6.0.1, 6.0.2

Operating system(s): AIX, Linux, Solaris, Windows

Reference #: 1447324

Modified date: 18 April 2017


Translate this page: