Why would a service check one attribute value with an LDAP Compare rather than a search?

## What the operation asks A Compare request carries two things: the Distinguished Name of **one** entry, and an assertion of the form *attribute equals value*. It asks the server a single closed question — does this entry hold this value for this attribute? — and the server answers with a `resultCode`. ## The answer is a code, not data - **`compareTrue (6)`** — the entry holds the asserted value. - **`compareFalse (5)`** — it does not. - **`noSuchObject (32)`** — there is no such entry, which is a different fact from a value that did not match. Nothing else comes back. There is no entry, no attribute list, no values. That is the whole point of the operation, and it produces the trap that catches most client code: **`success (0)` is never the answer to a Compare**. A generic result handler that treats any non-zero `resultCode` as a failure will report an error for a comparison that worked perfectly, and — worse — may report the same error for both possible answers. | operation | answer carried in | data returned | |---|---|---| | Compare | the `resultCode` itself, `compareTrue (6)` or `compareFalse (5)` | none | | a search for the same fact | a result entry, or the absence of one | the attributes that were asked for | ## Why it exists when a search would do Three reasons, and they are the reasons an interviewer is listening for. 1. **It cannot be used to enumerate.** The caller must already know both the Distinguished Name and the value; a caller who knows neither learns nothing. A search, by contrast, is a discovery tool — it takes a pattern and hands back whatever matched. 2. **Compare and read are separately controllable.** A directory can permit an application to *compare* an attribute it may not *read*. `userPassword` is the standard case: an application may confirm a value it was given without being able to retrieve what is stored. 3. **It is cheap for one bit.** Checking whether a Distinguished Name appears in a group entry's `member` values is one assertion evaluated inside the server. Doing it with a search means either transferring thousands of values to the client or constructing a filtered query whose result the client then has to interpret. Whether the assertion matches is decided by the attribute's own equality rules rather than by byte comparison in the client, which is another reason the server is the right place for the question. ## What it is emphatically not A Compare against `userPassword` is **not authentication**. It does not set the connection's authentication state — that is the LDAP Bind operation's job and nothing else's — and a `compareTrue (6)` says only that the assertion matched. Where the server holds a derived form of the value rather than what was originally supplied, an assertion carrying the original need not match at all, so a `compareFalse (5)` is not evidence that the value the caller holds is wrong. Building a login on Compare produces a system that is both insecure in its authorization model and unreliable in its verdicts. ## Reading the result correctly The handling a Compare needs is specific rather than generic: - Map `compareTrue (6)` and `compareFalse (5)` to the two answers, not to success and failure. - Keep `noSuchObject (32)` separate: a wrong name is a different bug from a wrong value, and collapsing the two hides typos in Distinguished Names indefinitely. - Treat `insufficientAccessRights (50)` as its own case: the caller may not even ask this question, which is not the same as the answer being no. ## Where it fits in a consolidation Merging address books, Compare is the cheap pre-flight. Before deleting what looks like a duplicate entry, assert that the surviving entry really does carry the value the duplicate was keeping — the phone number, the staff identifier, the membership — and act on `compareTrue (6)`. One bit, one request, no data moved, and no chance of the check itself leaking an attribute the job was never meant to read.