skip to content

In a SASL EXTERNAL LDAP Bind, where does the identity come from, and what does an authzId in the request change?

level: seniorimportance: nice to knowfreq 30%

answer

  1. the bind that sends nothing
  2. it borrows from underneath
  3. two identities, not one
  4. proved against requested
  5. dn: or u:, prefix required

basics

~20 s

SASL EXTERNAL carries no secret: it asks the directory to use an identity the layer beneath LDAP already established. An authzId in its credentials asks to act as someone else instead, which the server may refuse.

solid answer

~50 s

`SASL EXTERNAL` is the one bind that presents nothing. Named through `sasl [3]`, it asks the directory to take the client's identity from a layer already established underneath the LDAP session; if no such identity exists there, the server has nothing to use and rejects the Bind. Its credentials value is optional, and when present it holds an **`authzId`** — the identity the client asks to *act as*, which need not be the one it proved. The grammar has two forms: `dnAuthzId`, a Distinguished Name after a `dn:` prefix, and `uAuthzId`, a bare user identifier after `u:`. That splits one bind into two identities — the **authentication identity** the layer below established, and the **authorization identity** the session ends up carrying — and the directory decides by policy whether the first may assume the second.

code

pseudocode · 19 lines
pseudocode
function bind_external(session, requested_authzId)
    proved = session.identity_from_the_layer_below

    if proved is none
        reject the Bind
        session stays anonymous
        return

    if requested_authzId is empty
        authorization_identity = proved
    else
        -- "dn:" <distinguished name>   or   "u:" <userid>
        authorization_identity = parse_authzId(requested_authzId)
        if authorization_identity is malformed
            reject the Bind; session stays anonymous; return
        if not policy_permits(proved, authorization_identity)
            reject the Bind; session stays anonymous; return

    bind session as authorization_identity

go deeper

for a junior

Recall that not every LDAP Bind carries a password, and that SASL EXTERNAL is the one carrying no credential because the identity came from somewhere underneath.

for a middle

Explain the two identities and the authzId forms - dn: with a Distinguished Name, u: with a user identifier - and that supplying one is a request the server may refuse.

for a senior

Show the diagnosis: identical client code failing where no identity exists below the session, and an audit trail that records the assumed identity rather than the proved one.

for a principal

Decide whether act-as is permitted in your estate at all, who may assume whom, and how both identities are recorded so an action can still be attributed to the party that proved itself.

## A bind that presents no credential Every other bind hands the directory something to check: a password in `simple [0]`, or a mechanism's data in `sasl [3]`. **`SASL EXTERNAL` hands over nothing.** It is the client saying: *you already know who I am from the layer underneath this session — use that.* That makes it unusual in three ways worth stating explicitly: - **There is no secret on the wire for this bind**, so there is nothing in the bind itself to intercept or replay. - **It cannot work in isolation.** If the layer beneath the LDAP session established no identity, the mechanism has nothing to refer to and the server rejects the Bind. "It works from my workstation and fails in the shift-planning service" is, nine times out of ten, that: the service reached the directory over a connection that authenticated nobody. - **The directory is not choosing the identity** — it is accepting one decided below. What that lower layer is, and how it establishes an identity, is a separate subject; for the Bind the only question is whether an identity is there. ## Two identities, not one The credentials value of `SASL EXTERNAL` is optional. When it is absent, the client is saying "use whatever the layer below established, unchanged". When it is present, it holds an **`authzId`** — a request to act as a *different* identity. That is the distinction the question is really testing: - the **authentication identity** — who the client actually proved it is; - the **authorization identity** — who the session will be treated as for everything it does afterwards. They are the same by default, and differ whenever an `authzId` is supplied and accepted. The `authzId` grammar has exactly two forms: | form | shape | means | |---|---|---| | `dnAuthzId` | `dn:` followed by a Distinguished Name | act as this directory entry | | `uAuthzId` | `u:` followed by a user identifier | act as this user, the server resolving the name | The prefix is not decoration. A bare Distinguished Name with no `dn:` in front of it is not a well-formed `authzId`, and stripping the prefix because "it is obviously a DN" is a real client bug. ## The server decides, and it may say no Asking is not receiving. A request to assume an authorization identity is a **request**, and the directory's policy decides whether the proved identity is permitted to make it. A shift-planning service that proved one identity at the layer below and asks to act as each press operator in turn is asking for something a directory may perfectly reasonably refuse; if it does, the Bind fails and the session is anonymous, exactly as any other refused Bind leaves it. The practical consequences: 1. **Audit trails follow the authorization identity, not the one that was proved.** If the two differ and only one is recorded, the directory's record of who changed an entry is the assumed identity — and the proved one may be nowhere in it. 2. **A client cannot escalate by asking nicely.** The `authzId` carries no proof of its own; everything rests on the server's policy for the proved identity. 3. **Nothing about the mechanism removes the need for a decision.** `SASL EXTERNAL` with an `authzId` is not "passwordless therefore safe"; it moves the whole question into the directory's policy. ## Where EXTERNAL sits among the named mechanisms It helps to place it against the other mechanisms a `sasl [3]` bind can name: - **`SASL PLAIN`** also carries an `authzId`, but alongside an authentication identity and a password in one credentials value — it still transmits a secret, and it derives nothing from the layer below. - **`SASL ANONYMOUS`** claims no identity at all, and is a named mechanism distinct from the anonymous authentication mechanism of simple bind. - **`SASL EXTERNAL`** is the only one of the three with no credential of its own to send, because the identity already exists somewhere else. A client discovers which of these a directory will actually negotiate by reading `supportedSASLMechanisms` from the root DSE while still anonymous, rather than hard-coding a name and finding out per deployment. ## The short answer to give "`SASL EXTERNAL` takes the authentication identity from the layer already established beneath the session and sends no credential; if there is no such identity, the Bind fails. An `authzId` in its credentials — `dn:` plus a Distinguished Name, or `u:` plus a user identifier — asks to be authorized as somebody else, and whether that is granted is the directory's policy decision, not the client's."

  • What is the difference between a session's authentication identity and its authorization identity?
    The authentication identity is who the client proved it is; the authorization identity is who the session is treated as afterwards. They coincide unless an `authzId` was supplied and accepted. Everything the session then does — and everything the directory records about it — follows the authorization identity, which is why letting the two differ is a policy decision.
  • Why does SASL EXTERNAL fail on one deployment and succeed on another with identical client code?
    Because the mechanism refers to an identity established beneath the LDAP session, and that is a property of how the connection was made rather than of the client's bind logic. Where no identity exists below, there is nothing for the mechanism to use and the Bind is rejected.
  • Does SASL PLAIN solve the same problem as SASL EXTERNAL?
    No. `SASL PLAIN` also carries an `authzId`, so it can express the same act-as request, but it sends an authentication identity and a password in its credentials — a secret on the wire. `SASL EXTERNAL` sends no credential at all, because the identity was established before the bind.

saying these in an interview costs you the question

  • Says SASL EXTERNAL sends a credential of its own
  • Treats the proved identity and the requested authzId as one thing
  • Assumes the lower layer's identity applies without any bind
  • Writes an authzId as a bare DN with no dn: prefix
  • Thinks a server must honour whatever authzId is asked for
  • Calls a passwordless bind safe without naming the policy decision