powered by Jive Software

LDAP and alias entries

I’'m having the following problem with LDAP authentication:

2006.01.06 12:13:30 Connect Socket[addr=/10.2.43.219,port=1094,localport=5222]

2006.01.06 12:13:31 Trying to find a user’'s DN based on their username. cn: cgep

hart, Base DN: o=mc…

2006.01.06 12:13:31 Creating a DirContext in LdapManager.getContext()…

2006.01.06 12:13:31 Created hashtable with context values, attempting to create

context…

2006.01.06 12:13:31 … context created successfully, returning.

2006.01.06 12:13:31 Starting LDAP search…

2006.01.06 12:13:31 … search finished

2006.01.06 12:13:31 Search for userDN based on username ‘‘cgephart’’ found multipl

e responses, throwing exception.

2006.01.06 12:13:31 Exception thrown when searching for userDN based on username

‘‘cgephart’’

org.jivesoftware.messenger.user.UserNotFoundException: LDAP username lookup for

cgephart matched multiple entries.

Presumably it’'s matching “multiple entries” because there is an alias entry in LDAP pointing to his account entry. So the search returns two results, one for the alias entry and one for the account entry.

Changing the filter has not helped. It appears Java is doing an LDAP query with the “dereference aliases” option set to “always”, so the filter is applied to the alias object after it’'s been dereferenced to the account object. Packet sniffing has shown the LDAP server responding with two copies of the same LDAP entry.

The Java “dereference aliases” behavior is described here:

http://java.sun.com/products/jndi/tutorial/ldap/misc/aliases.html

I have tried to add the following to my /opt/jive_messenger/bin/messenger.vmoptions file:

-Djava.naming.ldap.derefAliases=never

but it doesn’'t seem to make a difference.

Any other ideas?

Ok, I’'ve come up with my own solution. Unfortunately, it involved a patch. Thank you Jive Software for making this project open source! It allows users with special needs to come up with their own solutions.

Here is my solution:

  1. First, I upgraded to Wildfire 2.4.

  2. Then I downloaded the source and made a change to src/java/org/jivesoftware/wildfire/ldap/LdapManager.java

— LdapManager.java.original 2006-01-12 08:28:08.315128500 -0500

+++ LdapManager.java 2006-01-12 08:35:38.046167700 -0500

@@ -264,6 +264,15 @@ public class LdapManager {

env.put(Context.REFERRAL, “follow”);

}

  •    // if the system specifies a value for derefAliases, copy it
    
  •    // into the environment we''ve created
    
  •    final String DEREF_ALIASES = "java.naming.ldap.derefAliases";
    
  •    String derefAliasesSetting = System.getProperty(DEREF_ALIASES);
    
  •    if (derefAliasesSetting != null) {
    
  •        Log.debug(DEREF_ALIASES + "=" + derefAliasesSetting);
    
  •        env.put(DEREF_ALIASES, derefAliasesSetting);
    
  •    }
    

if (debug) {

Log.debug(“Created hashtable with context values, attempting to create context…”);

}

  1. Then I rebuilt the wildfire.jar file and copied it to the proper location.

  2. This patch by itself doesn’'t change any behavior, it only allows the derefAliases property to be changed, so create /opt/wildfire/bin/wildfire.vmoptions with the following content:

-Djava.naming.ldap.derefAliases=never

  1. Restart the Wildfire server

Hi,

I followed your instructions, but the problem persists…