Hi everyone, just a quick post on an issue I encountered with OVD 11g (11.1.1.2) and how it handles LDAP filtering.
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)…
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 11.1.1.4.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.