\n The LDAP compare operation may be used to determine whether a given entry has a specified attribute value. Each compare operation consists of one request message and one response message.\n<\/p>\n
\n Technically, you can accomplish this with a search (using a base DN of the target entry DN, a scope of baseObject, and an equality filter with the target attribute type and assertion value; if the server returns a search result entry, the entry has the specified value), but the compare operation does this more efficiently because the compare operation can do this without the need for the extra search result entry message.\n<\/p>\n
\n Honestly, the compare operation isn\u2019t used all that often in most deployments. Nevertheless, it is a core LDAPv3 operation type, so it is described here for completeness.\n<\/p>\n
<\/a><\/p>\n \n RFC 4511<\/a> section 4.10 defines the compare request protocol operation as follows:\n<\/p>\n \n And its dependencies, described elsewhere in RFC 4511<\/a>, are:\n<\/p>\n \n That is to say that the compare request protocol operation is a sequence with a BER type of 0x6E<\/tt> (application class, constructed, tag number fourteen) and the following two elements:\n<\/p>\n \n For example, let\u2019s say that you want to determine whether the entry uid=jdoe,ou=People,dc=example,dc=com<\/tt> has an employeeType<\/tt> attribute with a value of salaried<\/tt>. If the compare request has message ID two and no request controls, it would be encoded as follows:\n<\/p>\n <\/a><\/p>\n \n The compare response protocol operation is also defined in RFC 4511<\/a> section 4.10. That definition is:\n<\/p>\n \n We\u2019ve already covered the LDAPResult<\/tt> element in an earlier section<\/a>, so there\u2019s no need to go into a lot of detail about it again here. But there is one unusual thing about the compare response: it won\u2019t ever include a result code of success<\/tt> (0). Some of the result codes that may be used for the compare operation are:\n<\/p>\n \n There may, of course, be other result codes for other error conditions (e.g., if the requester doesn\u2019t have permission to make the comparison, if the server is too busy, if the server encounters a referral while locating the target entry, if an internal server error occurs, etc.), but the above result codes are the most directly applicable.\n<\/p>\n \n If the server returns a compare response with a result code of compareTrue<\/tt>, then that would be encoded as:\n<\/p>\nThe Compare Request<\/h3>\n
CompareRequest ::= [APPLICATION 14] SEQUENCE {\n entry LDAPDN,\n ava AttributeValueAssertion }<\/pre>\nLDAPDN ::= LDAPString -- Constrained to <distinguishedName>\n -- [RFC4514]\n\nAttributeValueAssertion ::= SEQUENCE {\n attributeDesc AttributeDescription,\n assertionValue AssertionValue }\n\nLDAPString ::= OCTET STRING -- UTF-8 encoded,\n -- [ISO10646] characters\n\nAttributeDescription ::= LDAPString\n -- Constrained to <attributedescription>\n -- [RFC4512]\n\nAttributeValue ::= OCTET STRING<\/pre>\n\n
\n
30 45 -- Begin the LDAPMessage sequence\n 02 01 02 -- The message ID (integer value 2)\n 6e 40 -- Begin the compare request protocol op\n 04 24 75 69 64 3d 6a 64 6f 65 -- The target entry DN (octet string\n 2c 6f 75 3d 50 65 6f 70 -- \"uid=jdoe,ou=People,dc=example,dc=com\")\n 6c 65 2c 64 63 3d 65 78\n 61 6d 70 6c 65 2c 64 63\n 3d 63 6f 6d\n 30 18 -- Begin the attribute value assertion sequence\n 04 0c 65 6d 70 6c 6f 79 65 65 -- The attribute description (octet string\n 54 79 70 65 -- \"employeeType\")\n 04 08 73 61 6c 61 72 69 65 64 -- The assertion value (octet string \"salaried\")<\/pre>\n
The Compare Response<\/h3>\n
CompareResponse ::= [APPLICATION 15] LDAPResult<\/pre>\n
\n
30 0c -- Begin the LDAPMessage sequence\n 02 01 02 -- The message ID (integer value 2)\n 6f 07 -- Begin the compare response protocol op\n 0a 01 06 -- compareTrue result code (enumerated value 6)\n 04 00 -- No matched DN (0-byte octet string)\n 04 00 -- No diagnostic message (0-byte octet string)<\/pre>\n<\/p>\n