search

pingidentity / ldapsdk

UnboundID LDAP SDK for Java
Other
338 stars 81 forks source link

How to search entries dn by filter ? Attributes should not be loaded in response #170

Open gredwhite opened 8 hours ago

gredwhite commented 8 hours ago

I need a method which accepts collection of identifiers (dn or objectGuid) and returns back dns.

so I have code like this:

var entries = ldapConnection.search(baseDN, scope, filter).searchEntries

At this case each entry in the list has attributes. By default it is all user attributes. But I don't need them here. Sure I can make a call like

var entries = ldapConnection.search(baseDN, scope, filter,"dn").searchEntries

or even var entries = ldapConnection.search(baseDN, scope, filter,"").searchEntries

But maybe there are special API for such a problem ?

dirmgr commented 4 hours ago

By default, if you don't specify any attributes to return in a search request, the server will return every user (that is, non-operational) attribute in matching entries that the requester has permission to see.

As per RFC 4511 section 4.5.1.8, the correct standard way to request that the server not include any attributes in a search result entry is to have a requested attribute list that contains only the string "1.1". You can use SearchRequest.NO_ATTRIBUTES for this purpose.

"dn" happens to work in most cases, but that's basically because you're requesting an attribute that isn't present in the entry, but that's not actually guaranteed to be the case.

And requesting an empty string is technically illegal because that isn't a valid attribute description, nor is it one of the defined tokens that have special meaning (like the aforementioned "1.1", or "*" to indicate all user attributes, or "+" to indicate all operational attributes, or "@objectClassName" to indicate all attributes associated with the specified object class as per RFC 4529). The LDAP SDK doesn't attempt to perform validation on the requested attribute names because it's possible that servers may support other types of special tokens, and it sounds like Active Directory doesn't care either.

But in this case, I'd recommend going with "1.1". It's possible that the server has an optimization to handle that case more efficiently than just falling back to the default logic and treating "1.1" as an OID for a nonexistent attribute type.