Problems to Translate from JNDI to UnboundID LDAP SDK

[Sebastian B.]

Hi i have a problem, i try to translate my searchResult code from my old JNDI to UnboundID:

Her my code:

JNDI:
DirContext dctx = new InitialDirContext(env);
String[] attrIDs = {"cn","mail"};

SearchControls ctls = new SearchControls();
ctls.setReturningAttributes(attrIDs);
ctls.setSearchScope(SearchControls.SUBTREE_SCOPE);

NamingEnumeration results = dctx.search("ou=ou1,ou=ou2,o=organisation,c=de", "(&(objectclass=person)(uid=testuser))", ctls);

while (results.hasMore ()) {
SearchResult result = (SearchResult) results.next ();
Attributes attrs = result.getAttributes ();
System.out.println(attrs.get("cn")+" "+attrs.get("mail"));

UNboundID:
SearchResult searchResult;

if (connection.isConnected()) {
searchResult = connection.search("ou=ou1,ou=ou2,o=organisation,c=de", SearchScope.SUB, "(&(objectclass=person)(uid=testuser))");

System.out.println(searchResult.getEntryCount() + " entries returned.");
return searchResult.getSearchEntries();

with the UboundID code i get this error:
Exception in thread "main" LDAPSearchException(resultCode=32 (no such object), numEntries=0, numReferences=0, errorMessage='[DSA]:No such object:ou=ou1,ou=ou2,o=organisation,c=de')

I hope everybody have an idea where i make the mistake.

[Neil Wilson]

The search request that you are sending isn't exactly equivalent, since the JNDI example requests that only the cn and mail attributes be returned, but the example with the UnboundID LDAP SDK doesn't request any specific attributes and therefore should cause the server to return all user attributes that the client has permission to retrieve. But it's very unlikely that this is responsible for the different behaviors that you're seeing.

Assuming that difference isn't responsible for the behavior, I have no idea why a JNDI client would cause a different result to be returned than the UnboundID LDAP SDK. The response that the server returns indicates that the entry "ou=ou1,ou=ou2,o=organisation,c=de" doesn't actually exist in the directory. I would first recommend that you check to verify that the entry does actually exist and hasn't been removed or that you aren't accidentally using the wrong DN.

If you're sure that the entry exists and that you're using the right DN, then I can only think of two possibilities:

• JNDI is actually getting the same response, but hides this "no such object" result and just returns an empty NamingEnumeration instead of throwing an exception. In this case, the UnboundID LDAP SDK is behaving as designed, and this is a case where the two APIs simply behave differently (and if this is the case, then I would definitely say that the UnboundID LDAP SDK is more correct, because hiding the exception makes it impossible to distinguish between different reasons for not getting any responses like the search simply not matching any entries, or the client not having permission to see any of the matching entries).
• There is some subtle difference in the requests that are getting sent, and that difference causes the server to produce a different response. You should be able to check this by looking at the low-level communication between the client and server. The ldap-debugger tool provided with the UnboundID LDAP SDK can help you determine whether this is the case. It can act as a simple LDAP proxy server and decode all communication that passes through it. You can point your JNDI and UnboundID LDAP SDK clients at this proxy and have the proxy pass the requests on to the directory server. If there is a difference in the requests that are being sent, you should be able to see it.

Neil