DXsearch fails with bad search filter error (-7)
Article ID: 15476
Updated On:
Products
Issue/Introduction
You might come across a situation where a specific search fails to execute while all looks to be good. You might also notice the fact that same search on a different attribute in filter value working fine for you.
When you run a search (dxsearch/ldapsearch), you are receiving "bad search filter error (-7)"
e.g.
dxsearch -h {host}:{port} -D "bindDN" -W -b "o=democorp,c=au" "CA_disabled_State=1" dxEntryCount
fails with:
=======
# extended LDIF
#
# LDAPv3
# base <o=democorp.c=au> with scope subtree
# filter: CA_disabled_State=1
# requesting: dxEntryCount
#
dxsearch: ldap_search_ext: Bad search filter (-7)
=======
Environment
Component:
Resolution
The problem is, attribute name (descriptor) mentioned in the filter has an underscore as part of naming convention which is not supported by OpenLDAP standards. You can read more at:
https://ff1959.wordpress.com/2012/03/04/characters-that-are-permitted-in-attribute-names-descriptors/
Further explanation:
The OpenLDAP source which we use for dxsearch is standards compliant and as such enforces the standards with respect to search filters. A request that we hack a 3rd party component like OpenLDAP to follow suite would seem like a slippery slope to nowhere.
Renaming the attribute to include hyphens instead of underscores is not a workaround but rather a way of making the attribute name standards compliant.
To allow future compatibility with LDAP tools that enforce strict compliance, we would recommend renaming the attribute to conform to the LDAP standard.
The inconsistency here is that we have allowed a name with hyphens to be configured in the first place. The reason for this is that we are built on X.500 and the DAP interface didn't care about attribute names, it only used object identifiers. Therefore, DAP applications could assign pretty much any label they wanted to an object identifier. Our support for names with hyphens in the schema are a throwback from these days.
On a temporary basis you can either edit the 'name' of all those your custom attributes replacing 'underscore' with 'hyphens'.
i.e. as for example:
schema set attribute attributeType:4 = {
name = CA-disabled-State
syntax = caseIgnoreString
single-valued
};
OR
You can add 'ldap-names' to the existing definitions, so it can be searchable that way.
i.e. as for example
schema set attribute attributeType:4 = {
name = CA_disabled_State
ldap-names = CA-disabled-State
syntax = caseIgnoreString
single-valued
};
NOTE: In either way, the output (looking through LDAP browser or dxsearch output for entire entry etc.) will show the attribute name with 'hyphne' and not 'underscore' though. That is the trade off.
Feedback
