In LDAP, what does the Bind operation do to a session, and what state is that session in before one?
answer
- a state change, not a login call
- what the session is before you ask
- anonymous until proven otherwise
- version, name, AuthenticationChoice
- what a failure leaves behind
basics
~20 sThe LDAP Bind operation sets the authentication state of an LDAP session. Before any Bind, and after any Bind that fails, the session is anonymous: it can already send searches, but every request is evaluated as an unauthenticated caller.
solid answer
~50 sAn LDAP session is usable the moment the transport is up: the client may send a `SearchRequest` straight away, and the directory answers as far as an unauthenticated caller is permitted. The session is in an **anonymous** authorization state, and the LDAP Bind operation is the one operation whose job is to change that. A `BindRequest` carries exactly three things — `version` (3 for LDAPv3), `name` (the bind DN of a directory entry, zero length for anonymous), and an `AuthenticationChoice` that is either `simple [0]`, an octet string password, or `sasl [3]`, a `SaslCredentials` naming a mechanism. Only a `success (0)` response moves the session to that identity. Receipt of a `BindRequest` discards whatever identity the session already held, so a Bind that fails does not leave you where you were — it leaves you anonymous.
code
asn1 · 14 linesBindRequest ::= [APPLICATION 0] SEQUENCE {
version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }
AuthenticationChoice ::= CHOICE {
simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials,
... }
SaslCredentials ::= SEQUENCE {
mechanism LDAPString,
credentials OCTET STRING OPTIONAL }go deeper
Recall the shape: an LDAP session starts anonymous, and the Bind operation is what gives it an identity. Name the three fields of a BindRequest - version, the bind DN, and the choice between a password and a SASL mechanism.
Explain the ordering: the server resets the session to anonymous on receiving a BindRequest and only promotes it on success (0). Be able to say why UnbindRequest is not the inverse of Bind.
Show that you have debugged the consequence - a pooled connection silently left anonymous by a failed re-bind, producing missing search results rather than an error anywhere in the application.
Frame the trade-off in binding identity to a connection at all: state that cannot be shared or migrated, a pool whose entries each carry an authorization state, and what that costs against a credential presented per request.
## What a Bind actually is The LDAP Bind operation is not "opening" something that was closed. An LDAP session — a client's connection to a directory server and the stream of `LDAPMessage` envelopes over it, each tagged with a `messageID` — exists and is usable the instant the transport is established. A client can send a `SearchRequest` before it has bound anything, and it will get a real answer: whatever a caller with no proven identity is allowed to see. What the session lacks is an identity. It is in an **anonymous authorization state**, and Bind is the operation that changes that state. RFC 4511 defines `BindRequest` as carrying three fields and nothing else: - **`version`** — the protocol version the client is speaking, `3` for LDAPv3. A server publishes what it accepts in `supportedLDAPVersion`. - **`name`** — the **bind DN**: the Distinguished Name of the directory entry the client claims to be, in the RFC 4514 string form. Zero length means the client is claiming nothing. - **`authentication`** — an `AuthenticationChoice`, which is `simple [0]`, an octet string holding a password, or `sasl [3]`, a `SaslCredentials` value naming a mechanism and carrying that mechanism's data. There is no session identifier for the client to store and no credential it keeps presenting on later requests. **The authentication state lives on the connection**, and it dies with the connection. ## The state machine, and the trap inside it The rule that catches people is the ordering: the server resets the session to anonymous when it *receives* a `BindRequest`, and only moves it to the new identity if the Bind succeeds. | event | resulting state of the session | |---|---| | transport established, no Bind sent yet | anonymous | | `BindRequest` received, still being processed | anonymous | | Bind answered `success (0)` | the identity that bound | | Bind answered any other result code | anonymous | | `UnbindRequest` sent | the session terminates; there is no response | Read the fourth row twice. **A re-bind that fails is a downgrade, not a no-op.** A shift-planning service that holds a long-lived pooled connection bound as a read-only directory entry, and then re-binds that same connection as a different identity, has an anonymous connection in its pool the moment that second Bind is refused. Nothing errors afterwards — the next borrower's search simply returns fewer entries, or none, and the service reports "the operator does not exist" for someone who plainly does. Diagnosing that means knowing this row of the table. `UnbindRequest` is also not the opposite of Bind, despite its name. It takes no response and ends the session outright. To drop an identity and keep the connection, a client binds again — an anonymous Bind, with a zero-length `name` and a zero-length `simple [0]` value, is the idiom. ## A successful Bind proves credentials, not permission A `success (0)` means the directory accepted what was presented. It does **not** mean the bound identity can read the tree, or any part of it. What the bound identity may then see is decided entry by entry and attribute by attribute when each later request is processed, by the directory's own access policy. A candidate who answers "then I can read everything under the naming context" has confused authentication with what the directory will show them. Two further limits are worth stating plainly: 1. A simple bind on an unprotected connection sends the password in the clear, because `simple [0]` is an octet string on the wire with nothing over it. 2. Binding says nothing about the *server's* identity. Only a mechanism that authenticates in both directions does that, and a plain password bind is not one. ## "Bind" is an overloaded word — say which one Three different things are called binding around directories, and an interview answer should distinguish them without being asked: - the **LDAP Bind operation** described here, which sets a session's authentication state; - a socket **bound** to a listening port, which is the transport and has nothing to do with identity; - a directory client library's `bind`/`rebind` call that **creates or replaces an entry** in a naming service — the same four letters, an entirely different act. Saying "the LDAP Bind operation" or "the bind DN" costs two words and removes the ambiguity completely.
- How does a client drop an LDAP session's authenticated identity without closing the connection?By sending another `BindRequest`. Receipt of one resets the session to anonymous before the new credentials are even evaluated, so an anonymous Bind — zero-length `name`, zero-length `simple [0]` value — discards the old identity. `UnbindRequest` will not do it: it carries no response and terminates the session entirely.
- How does a client learn which SASL mechanisms a directory will accept, before it has bound?From the `supportedSASLMechanisms` attribute of the root DSE, which a client can read while still anonymous. It lists the mechanism names the server is willing to negotiate, so a client can pick one rather than guessing and collecting an `authMethodNotSupported (7)` for each attempt.
- Does a successful LDAP Bind mean the bound identity can read the directory?No. `success (0)` says the credentials were accepted, nothing more. What that identity may read is decided when each later request is processed, per entry and per attribute, by the directory's access policy — which is why a bind that works and a search that returns nothing are perfectly consistent.
A workshop's notice board is readable by anyone who walks in, and signing the shift register is a separate act that changes which cupboards the foreman will open for you. Scratching your name out again leaves you a stranger, not your earlier self.
saying these in an interview costs you the question
- Says an LDAP session can send nothing at all until it binds
- Treats a failed Bind as leaving the previous identity intact
- Confuses the LDAP Bind operation with a library call that creates an entry
- Thinks a successful Bind means the caller may read the whole tree
- Calls UnbindRequest the way to drop credentials and keep the session