skip to content

Why does an LDAP client issue the StartTLS extended operation before the LDAP Bind operation rather than after?

level: middleimportance: must knowfreq 44%

answer

  1. state lives on the connection
  2. a layer change costs the identity
  3. the password already left the building
  4. upgrade, then authenticate
  5. reset happens on removal too

basics

~20 s

Installing a TLS layer resets the LDAP connection's authentication state to anonymous, so a bind performed first is thrown away — and its password has already crossed the network in the clear. StartTLS first, then bind.

solid answer

~40 s

The LDAP Bind operation sets the authentication state of one connection, and that state does not survive a change of protection layer: RFC 4513 has the connection return to the anonymous authentication state whenever a TLS layer is installed — or removed. So binding first and upgrading afterwards costs twice. The identity established by that `BindRequest` is discarded and the client has to bind again, and the password it sent under the name/password authentication mechanism of simple bind travelled unprotected, so it must be treated as exposed. The order is therefore connect, send the StartTLS `ExtendedRequest`, check for `success (0)`, install the layer, and only then send the `BindRequest`. Ordering here is a consequence of the protocol, not a stylistic preference.

code

pseudocode · 13 lines
pseudocode
open connection to the directory server

send ExtendedRequest with requestName = "1.3.6.1.4.1.1466.20037"
wait for ExtendedResponse
if resultCode is not success (0) then
    close the connection          -- do not bind in the clear
install the TLS layer

-- authentication state is now anonymous, whatever it was before

send BindRequest with simple [0] carrying the bind DN and password
if resultCode is success (0) then
    send SearchRequest

go deeper

for a junior

Remember the order and the reason in one line: upgrade the connection first, authenticate second, because the upgrade wipes whatever identity the connection had and the password would otherwise travel unprotected.

for a middle

Explain that the LDAP Bind operation sets connection state rather than issuing a credential, and that installing or removing a protection layer returns that state to anonymous — then walk the five-step order.

for a senior

Bring the failure mode: a bound-then-upgraded client that silently becomes anonymous and reports phantom permission errors, and a client policy that forbids binding after a refused upgrade.

for a principal

The design point is that authentication state is bound to a transient connection. Say what that implies for pooling, for re-use after a layer is torn down, and for how a fleet proves it never binds unprotected.

## What an LDAP Bind operation actually sets The LDAP Bind operation does not mint a credential the client re-presents on every request. It sets the **authentication state of one connection**. A `BindRequest` carries an `AuthenticationChoice` that is either `simple [0]` — a bind DN with a password, or with an empty password, or empty on both counts — or `sasl [3]`, naming a mechanism and carrying `SaslCredentials`. Once it succeeds, every later `SearchRequest`, `ModifyRequest` or `CompareRequest` on that connection is evaluated as that identity. Nothing in a later message names the identity again; the connection *is* the identity. That is exactly why the protection layer and the ordering interact. ## Installing the TLS layer resets that state When a TLS layer is installed on an LDAP connection, the connection's authentication and authorization state is discarded and it reverts to the anonymous authentication state. The rule is symmetric: **removing** the layer resets it too. Three consequences fall out: - A bind performed before the upgrade is simply gone. The client is anonymous again and must bind a second time. - The password it sent in that first bind crossed an unprotected connection. Re-binding inside TLS does not un-send it; that credential has to be treated as exposed. - A client that assumes its identity survived will start issuing searches as an anonymous caller and see either fewer entries than it expects or a flat refusal — a failure that looks like an access-control problem and is not one. ## The order that follows 1. Open the connection. 2. Optionally read `supportedExtension` on the `root DSE`. 3. Send the StartTLS `ExtendedRequest`, with no other operations outstanding, and wait for the `ExtendedResponse`. 4. On `success (0)`, install the layer. On anything else, decide deliberately — do not bind on the unprotected connection out of momentum. 5. Send the `BindRequest`. Now the credential is inside the layer and the state it sets is the state the connection keeps. A client does not send StartTLS on a connection that already carries a TLS layer; the server refuses rather than renegotiating. | | before the upgrade | after the upgrade | |---|---|---| | Authentication state | whatever a Bind set | anonymous, unconditionally | | Traffic | in the clear | protected by the TLS layer | | A password sent here | exposed, permanently | protected | ## The other route to protection, and how the two stack TLS is not the only way an LDAP connection gains integrity and confidentiality. A SASL mechanism negotiated through `sasl [3]` can install a **`security layer`** of its own, and for a client that cannot do TLS this is a genuine alternative rather than a curiosity. The two are independent mechanisms, and when both are present on one connection the SASL security layer is installed **on top of** the TLS layer. Neither negotiation is an input to the other; each protects the traffic passing through it. The ordering point survives that too. A SASL security layer comes into effect as part of the LDAP Bind operation that negotiated it, so it protects what follows the bind — whereas TLS installed by StartTLS protects the bind itself. If the credential you care about is the one in the `BindRequest`, only the layer that was already in place when that message was sent has protected it. ## Where this shows up in production The classic failure is a client that binds, upgrades 'for safety', and then reports intermittent permission errors that nobody can reproduce from a directory client. The second classic is a client configured to attempt the upgrade and continue on failure: every time the server declines StartTLS — during maintenance, after a certificate problem, against the wrong host — the password goes out in the clear and nothing in the client's log says so, because from its point of view the bind succeeded. A third, quieter one is a connection pool that opens a connection, upgrades, binds, and later re-uses it after something has torn the layer down. The connection is anonymous again; the pool believes it is bound. The protocol rule is the same in all three cases: the authentication state belongs to the connection, and the layer change resets it.

  • A client binds, then upgrades with StartTLS, then runs a search and gets fewer entries than expected. What happened?
    Installing the layer returned the connection to the anonymous authentication state, so the search ran as an anonymous caller and saw only what anonymous callers may read. It looks like an access-control regression; it is an ordering bug. The fix is to bind after the upgrade, not to widen anybody's access.
  • When both a TLS layer and a SASL security layer protect one LDAP connection, which sits above which?
    The SASL security layer is installed on top of the TLS layer, and the two operate independently — neither one's negotiation feeds the other. A client may therefore have integrity and confidentiality from either, or from both at once, and the layers are not substitutes in terms of which message each one managed to protect.
  • Does the reset apply when the TLS layer is removed rather than installed?
    Yes — that is the symmetric half of the same rule, and it is the one people forget. A connection whose layer has been torn down is anonymous again even though it was bound a moment earlier, which is how a re-used pooled connection ends up performing work as nobody in particular.

Upgrading after you have bound is like being walked back to the lobby and readmitted through a private corridor: the corridor is yours alone from now on, but the visitor badge you were issued earlier no longer counts and you sign in again.

saying these in an interview costs you the question

  • Says the bound identity survives the upgrade because it is tied to the connection.
  • Calls the ordering a performance preference rather than a protocol consequence.
  • Thinks re-binding inside TLS undoes the exposure of the earlier password.
  • Believes only installing the layer resets the state, never removing it.
  • Puts the SASL security layer underneath TLS instead of on top of it.