You can restrict the types of search filters that a given client may be allowed to use to prevent the use of potentially expensive filters, like range or substring searches. You can use the allowed-filter-type property to provide a list of filter types that may be included in the search requests from clients associated with the client connection policy. This setting will only be used if search is included in the set of allowed operation types. This restriction will only be applied to searches with a scope other than baseObject, such as searches with a scope of singleLevel, wholeSubtree, or subordinateSubtree.

The minimum-substring-length property can be used to specify the minimum number of non-wildcard characters in a substring filter. Any attempt to use a substring search with an element containing fewer than this number of bytes will be rejected. For example, the server can be configured to reject filters like "(cn=a*)" and "(cn=ab*)", but to allow "(cn=abcde*)". This property setting will only be used if search is included in the set of allowed operation types and at least one of sub-initial, sub-any, or sub-final is included in the set of allowed filter types.

There are two primary benefits to enforcing a minimum substring length:

  • Allowing very short substrings can require the server to perform more expensive processing. The search requires a lot more server effort to assemble a candidate entry list for short substrings because the server has to examine a lot more index keys.

  • Allowing very short substrings makes it easier for a client to put together a series of requests to retrieve all the data from the server (a process known as "trawling"). If a malicious user wants to obtain all the data from the server, then it is easier to issue 26 requests like "(cn=a*)", "(cn=b*)", "(cn=c*)", ..., "(cn=z*)" than if the user is required to do something like "(cn=aaaaa*)", "(cn=aaaab*)", "(cn=aaaac*)", ..., "(cn=zzzzz*)".