Although both the substring and present grammar productions can produce the 'attr=*' construct, this construct is reserved solely to denote a presence filter, not a substring filter with empty components.

ldap

The backslash escaping mechanism was chosen because it eliminates filter-parsing ambiguities and allows any LDAP filter to be represented as a NUL-terminated string. Other non-printing characters may also be escaped using the same mechanism.

ldap

The filter format uses prefix notation (operator before operands, e.g., '(&(a=1)(b=2))') rather than infix, which is consistent with LDAP's ASN.1 structure and simplifies unambiguous recursive parsing.

ldap

The IESG warns that until mandatory authentication mechanisms are standardized, clients and servers implementing LDAP update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.

ldap, security

This document replaces RFC 1960, extending the string LDAP filter definition to include support for LDAPv3 extended match filters and to cover the full range of possible LDAP search filters.

ldap

Characters *, (, ), \, and NUL (ASCII 0x2a, 0x28, 0x29, 0x5c, 0x00) MUST be encoded as a backslash '\' followed by the two hexadecimal digits representing the character's ASCII value when they appear in a filter value.

ldap

The case of the two hexadecimal digits used in the escape sequence is not significant, meaning both '\2a' and '\2A' are valid representations of the '*' character.

ldap

LDAPString is defined as an OCTET STRING limited to the UTF-8 encoding of the ISO 10646 character set. AttributeDescription, MatchingRuleID, and similar string types are all LDAPString instances.

ldap

MatchingRuleAssertion includes optional matchingRule [1] MatchingRuleID, optional type [2] AttributeDescription, required matchValue [3] AssertionValue, and dnAttributes [4] BOOLEAN DEFAULT FALSE. This supports extensible matching against named matching rules.

ldap

SubstringFilter is a SEQUENCE with an AttributeDescription type and a SEQUENCE OF CHOICE containing initial [0], any [1], and final [2] LDAPString components. This structure allows prefix, infix, and suffix substring matching.

ldap

The extensible match ':dn' notation indicates that the attributes of an entry's distinguished name should be considered part of the entry when evaluating the match, as illustrated by '(sn:dn:2.4.6.8.10:=Barney Rubble)'.

ldap

The LDAP search Filter is defined as an ASN.1 CHOICE encompassing ten filter types: and, or, not, equalityMatch, substrings, greaterOrEqual, lessOrEqual, present, approxMatch, and extensibleMatch. This covers the full range of LDAPv3 search filter semantics.

ldap

When no attr is specified in an extensible filter (e.g., '(:dn:2.4.6.8.10:=Dino)'), the filter applies to any attribute supporting the given matching rule, including those in DN components if ':dn' is present.

ldap

While the string representation itself has no known security implications, LDAP search filters are interpreted by servers to select entries from which data is retrieved. LDAP servers should take care to protect the data they maintain from unauthorized access.

ldap, security

Extensible match filters are encoded as 'attr [":dn"] [":" matchingrule] ":=" value' or '[":dn"] ":" matchingrule ":=" value'. The ':dn' flag causes DN attributes to be considered when evaluating the match.

ldap

Simple filter items take the form 'attr filtertype value' where filtertype is '=' (equal), '~=' (approx), '>=' (greater), or '<=' (less). Presence filters use 'attr=*' and substring filters use 'attr=[initial]*[any]*[final]'.

ldap

The string representation uses prefix parenthesized notation defined by an ABNF grammar. A filter is '(' filtercomp ')' where filtercomp is one of: '&' filterlist (AND), '|' filterlist (OR), '!' filter (NOT), or an item (simple, present, substring, extensible).

ldap