Exception: javax.naming.directory.InvalidSearchFilterException. We can't synchronize Active directory.

[Izaskun Nazabal]

Hi,

We can't synchronise one user directory with Active directory. And some new users they can't loggin.

When we try sinchronising, it throws this error:

Test retrieve group : Failed
org.springframework.ldap.InvalidSearchFilterException: invalid attribute description; nested exception is javax.naming.directory.InvalidSearchFilterException: invalid attribute description; remaining name 'ou=UHS_OÑATI,dc=uhs,dc=local'

In the directory settings we put in the "Group Schema settings", in the "Group Object Filter" atribute we try with 2 different options: (objectCategory=Group) , (&(objectClass=group)(cn=*))
But it doesn't work.

We've got another directory in the same server and it works perfectly.

[Izaskun Nazabal · Accepted solution]

Thank you for your help. But at finallly, the problem was a bug of a version.

https://confluence.atlassian.com/display/JIRAKB/InvalidSearchFilterException%3A+Empty+filter+when+Synchronising+LDAP

We create new directory with the same parameters and it works!

Thanks!

[UlmaHandling]

Thank you for your help. But at finallly, the problem was a bug of a version.

https://confluence.atlassian.com/display/JIRAKB/InvalidSearchFilterException%3A+Empty+filter+when+Synchronising+LDAP

We create new directory with the same parameters and it works!

Thanks!

[Izaskun Nazabal]

Hi,

Tiago, but it works before with Ñ.

Andy, what can I do?

Thanks.

[Andy Brook [Plugin People]]

Get an LDAP tool like http://directory.apache.org/studio/and validate your queries outside JIRA against your LDAP server. If you can get that to work, then you have a case for a bug report, if not, its a language/system incompatibility with (most likley) that character being the cause. In which case, a support call with M$, as it is reported that LDAP servers reporting V3 compatibility should trigger the Java VM to convert your query to UTF-8.

If you have developer resources, Id suggest getting the Java source, remote socket debugging JIRA running the filter, to determine exactly 'what' the LDAP filter is being converted to by Java.

The RFC seems to indicate that escaping is possible with \04\02\48\69 format within the filter (unverified) you just need to know what the unicode value is for the character in question, I couldnt paste it into http://unicodelookup.com/(dont know why)

[Tiago Comasseto]

Hi, both your filters seem correct, the only thing that called my attention was the Ñ in your base DN, I've never seem this character in an LDAP configuration, you may want to test it without ou=UHS_OÑATI just to rule out this possible issue from the list.

Cheers

[Andy Brook [Plugin People]]

yep, my bet is that you have an LDAP v2 connection (even if AD seems to support both 2 and 3), which means the underlying (guessing oracle) ldap filter impl converts your multibyte characters to ISO-8859 (latin-1) which could explain what you see. LDAP v3 gets converted to UTF-8.

- http://www.docjar.com/html/api/com/sun/jndi/ldap/Filter.java.html