Best Practices from Oracle Development's A‑Team

OVD 11g LDAP Error 2 : Bad LDAP Filter


Hi everyone, just a quick post on an issue I encountered with OVD 11g ( and how it handles LDAP filtering.

The Issue

For this post let’s use the following DN as our example:

“cn=OVD (11g), dc=us, dc=oracle, dc=com”

This is a perfectly valid DN, however, it has been discovered that DNs with parenthesis have issues within OVD.  Within the logs you may see “Bad LDAP Filter” errors:

! com.octetstring.vde.util.DirectoryException: LDAP Error 2 : Bad LDAP Filter.
at com.octetstring.vde.util.ParseFilter.parse(ParseFilter.java:291)…

The Solution

You may have guessed that the solution is to encode the ‘cn’ attribute.  Here is a description of how to encode as described in RFC 2254.

If a value should contain any of the following characters:

Character ASCII Value
* 0x2a
( 0x28
) 0x29
\ 0x5c
NUL 0x00

the character must be encoded as the backslash '\' character (ASCII 0x5c) followed by the two hexadecimal digits representing the ASCII value of the encoded character. The case of the two hexadecimal digits is not significant.

So using the above example, the ‘cn’ should now be encoded as follows: “cn=OVD \5c2811g\5c29”.  So when creating entries into your LDAP repository, make sure you encode the backslash ‘\’ character and both parenthesis ‘()’ as described above.

I know what you are thinking.What if I already have thousands of users that contain these special characters?  I’m certainly not going to go back and encode the ‘cn’ for each user!  Well, for that there is a patch coming out to address this problem.  As of this writing the solution has been identified and is due out for

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha