Weird AD layout leading to a possible feature request?

Hi there.

Today I deployed a wildfire server into a small company. They run Exchange as well, backed by an ActiveDirectory, so I tried to bind WF against it as well.

It worked surprisingly well, but I had one minor issue: The layout the company used was something like this:

ou=employees;dc=example;dc=com

…ou=stuff

…u=someUser

…ou=Whatever

…u=someFunctionalUserForMailingListsOrStuff

…u=someEmployee

…u=anotherEmployee

If the graph above looks odd: I agree… Anyway, I tried to include only the real users (those directly below the employees ou) and failed, due to the hardcoded recursive search in the ldap code (In the Manager class there, iirc).

Is this usecase too far-fetched for an option here? I currently think about recompiling WF with this sinle/easy change for me, but if there’'s any interest in an option for this I could offer to create something like ldap.searchscope with base, one etc. as possible options.

Opinions?

I agree. It would be a good option to have and the implementation is simple. +1 for this request.

If anyone wants to add this feature, the search scope is set around line 479 of LdapManager.java.

Since there’'s really only two useful scopes (SUBTREE and ONELEVEL), I would recommend a simple boolean option such as:

[/code]

Glad that you agree. I already found the line and changed it for my deployment. If some more express their interest in this I could remove the hack and make it configurable.

I’'m interested in a onelevel ldap search. Could this be implemented in a future version?

Hey guys,

This was a 15 minute new feature so I went ahead and added it. Here’'s the new entry in the LDAP documentation:

ldap.subTreeSearch – the value “true” if the entire sub-tree under the base DN should

be included when executing searches (recursive search). If the value “false” is set, only

the first level under the base DN will be searched. The default value is “true”, which is

the better option for the majority of directory layouts. Only set the value to “false” if

necessary.

The issue was filed as JM-719 and will be Wildfire 3.0 (due out soon!).

Regards,

Matt