Question

I have written a program that reads a webservice, retrieving user data, and then is supposed to push that data to ActiveDirectory, thus updating the user's title, address, phone numbers, etc.

The problem is that when I perform the search using the Unboundid Connection class the requested attributes are not returned. Below is the search code:

SearchResult result = connection.search( properties.getProperty("ldap.search.baseDN"), 
                        SearchScope.SUB, "(cn=" + userId + ")", 
                        "personalTitle", "department", "company", "manager", "telephoneNumber", 
                        "streetAddress", "I", "st", "postalCode", "c", "pager", "mobile", 
                        "fax", "cn");

The above code locates the desired user and the cn attribute is returned as expected, but the other attributes all fail to return. If I connect to AD using JXplorer using the same connection credentials, I'm able to see all the desired attributes exist, but are simply not being returned.

enter image description here

I have tried substituting SearchRequest.ALL_OPERATIONAL_ATTRIBUTES, SearchRequest.ALL_USER_ATTRIBUTES and SearchRequest.REQUEST_ATTRS_DEFAULT rather than listing the fields explicitly, but with no success.

I have also looked at the 'Schema' object returned from 'connection.getSchema()' and can see that personalTitle should exist:

connection.getSchema().getAttributeType("personalTitle")

The above code returns:

1.2.840.113556.1.2.615 NAME 'personalTitle' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE

So maybe this is a user permission issue? Has anyone experienced this and know how to resolve it?

Thanks, Mike

Was it helpful?

Solution

LDAP search result entries only include attributes that actually have values, so the behavior you are seeing from the UnboundID LDAP SDK is appropriate and correct. Even if you explicitly request a particular attribute, that attribute will only be included in the entry if it has one or more values.

I think that you're confused by JXplorer because it's reading the schema to determine what attributes could possibly be included in the entry based on its object classes and is showing them to you so that you can set values for those attributes in the editor. But that doesn't mean that the entry returned by the server actually includes any information about those attributes.

To verify this, you can use the ldap-debugger tool provided with the LDAP SDK to see the actual LDAP communication that occurs. Just run a command like:

 tools/ldap-debugger --hostname {directory-server-address} \
      --port {directory-server-port} --listenPort {listen-port}

This will create a very simple LDAP proxy server that decodes all requests and responses that pass through it. To use it, simply point JXplorer at the specified listen-port. You will see that when JXplorer retrieves the entry, the entry returned by the server will only contain attributes that actually have values.

If you want to figure out what all the possible attributes are that you can include in a given entry, then use the LDAPConnection.getSchema method to retrieve the server schema, then Schema.getObjectClass for each of the object classes in the target entry, and finally use the ObjectClassDefinition.getRequiredAttributes and ObjectClassDefinition.getOptionalAttributes methods to see what attribute types must and may be used in entries with that object class.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top