Do special characters in LDAP Search escaped by \XX have to be sent in binary form in the wire format?

Is there any RFC that requires the binary encoding on the wire of the \XX escaped values of a search query?

The string syntax for filters is defined in RFC 4515 as you've already found.

1. Section 3 says that specific characters within values – including a literal backslash – are represented in the resulting filter string by a \ followed by two hexadecimal digits.

   In other words, there is no possible input in the value which can result in the output of a standalone \ in the filter string – an \ is only ever allowed in combination with two hexadecimal digits, as part of an \xx hex escape.

   So it follows that when the parser sees a \ in the filter string, it cannot possibly be a standalone character representing itself, but must have been generated as part of a \xx hex escape, therefore the parser must un-escape it (or reject the filter as invalid if the next two characters aren't hex digits).

2. Section 4 of the same RFC has multiple examples specifically of the escaping mechanism, where it explicitly says that the example filter (bin=\00\00\00\04) is "a filter searching for the four-octet value 00 00 00 04 (hex)".

I am trying to send LDAP Search queries from PL/SQL (OracleDB using DBMSLDAP.searchs) towards Active Directory for the field objectGUID. Because that is a binary field, and I need to query non-ASCII values in the query.

Active Directory has a special match rule for objectGUID and objectSid which allows the binary value of GUIDs and SIDs to be matched by its standard string representation. That is, you can use an ASCII filter like:

• (objectGUID=1adfc252-0a4e-4644-8c1f-f35d1f21b68d)
  

• (objectSid=S-1-5-21-1713655460-2052781465-2559043297-4689)
  

{...} curly braces around the GUID value are optional.

Note that the string representation of GUIDs is not exactly a direct transformation of each byte to hex digits (it is for "UUIDs" but not for "GUIDs") – you need to swap the byte order of several fields. The above example corresponds to an entry with objectGUID:: UsLfGk4KREaMH/NdHyG2jQ==.

(The relevant RFC just points to The Old New Thing for the "specification"; I'd suggest testing your code against Python's uuid.UUID(bytes_le=b'...').)

As a more non-standard extension, Active Directory allows directly accessing objects by their GUID or SID, by specifying it in place of a DN using syntax:

• ldapsearch -b '' -s base
  

• ldapsearch -b '' -s base
  

This goes best with scope base which is the standard way to "read" an object by its exact DN. As with regular searches, this can still be combined with a filter like (objectClass=computer) if you want to implement type-checking that way.

The same pseudo-DN syntax also extends to Modify and Delete operations (where it can be used to ensure that updates will still get applied even if the entry gets externally renamed in-between the Search and the Modify).