In our company we have a hella corporate directory that provides company wide access to all kinds of great information as well as group memberships and corporate password system. The implementation is exposed via a few helpful representations but from the perspective of Team Concert we really only care about LDAP.
A challenge that I face over and over is having to import batches of users from the directory, due to the volume of the information and the complexity importing “Joe Smith” unavoidably comes up. Now we have some help here in that some attributes are guaranteed to be unique, but for the sake of better search capability a user may have 5 or 6 different cn attributes. The limited views from the RTC search tool become very apparent with than a basic find user queries that only search common names.
Here is a quick example of the amount of variability of just a single user, in this case me.
sgw@geb:~$ ldapsearch -x -h bluepages.ibm.com -b ou=bluepages,o=ibm.com 'cn=S*Wilbur' cn mail preferredIdentity # extended LDIF # # LDAPv3 # base &lt;ou=bluepages,o=ibm.com&gt; with scope subtree # filter: cn=S*Wilbur # requesting: cn mail preferredIdentity # # XXXXXX897, us, bluepages, ibm.com dn: uid=XXXXXX897,c=us,ou=bluepages,o=ibm.com mail: XXXXXXX@us.ibm.com preferredIdentity: XXXXXX@us.ibm.com cn: Sean G. Wilbur cn: Shawn G. Wilbur cn: Shaun G. Wilbur cn: Sean Wilbur cn: Shawn Wilbur cn: Shaun Wilbur # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 sgw@geb:~$
One way that I have found to deal with this is to update the two find user ldap query attributes to include an or option for one or more of the unique attributes. Notice that these are not fuzzy searches in my case, as it made these queries slow down dramatically and for my purposes I only want the one result that it matches.
com.ibm.team.repository.ldap.findUsersByNameQuery=(|(cn\=?1*)(uid\=?1)(mail\=?1) com.ibm.team.repository.ldap.findUsersByAnyNameQuery=(| (cn\=* ?1*) (cn\=*_?1*)(uid\=?1)(mail\=?1))
Hope this helps!