SASL Pass-Through to LDAP: Why Transparent Relaying Breaks and How to Proxy Authentication Properly

Delegating SASL authentication from a mail or XMPP server to your LDAP directory is possible, but not by blindly relaying SASL messages to slapd. Transparent forwarding breaks because several mechanisms depend on facts that only exist at the connection the application server terminates — the TLS session, the client certificate, the service's own Kerberos identity. The design that actually works uses a dedicated, SASL-aware authentication broker, and the most common one in production is Dovecot.

The two standard ways to hook services into LDAP

When you centralize authentication in LDAP, an IMAP, SMTP, or XMPP server has traditionally had two options:

• Service account with hash access. The application authenticates to LDAP with its own account, retrieves users' password hashes (sometimes even plaintext), and verifies SASL mechanisms like SCRAM-SHA-256 or DIGEST-MD5 locally. This supports strong mechanisms, but every service that can read hashes becomes a high-value target.
• Simple bind per user. The application takes the password the user submitted and performs an LDAP bind as that user. No hash exposure, but the application necessarily handles the plaintext password, which forces the PLAIN mechanism on the client side.

PLAIN inside TLS is not catastrophic — the password is protected on the wire — but mechanisms like SCRAM exist precisely to keep plaintext away from both the network and the application process. That tension is what makes the third idea attractive: let the directory run the SASL exchange itself.

The pass-through idea, and where it already works

The concept is sound: the application advertises non-plain mechanisms, then relays the SASL messages between client and directory so plaintext never leaves the client and hashes never leave the server. And it does exist — just not as a transparent proxy to LDAP.

Postfix and Exim can delegate the entire SASL exchange to Dovecot's authentication socket, where Dovecot's SASL server code runs the mechanism and holds the single LDAP service account on behalf of both. Prosody offers the same pattern through mod_auth_dovecot; ejabberd currently has no direct equivalent. IRC networks that use SASL also work this way: each server forwards the exchange to a central services pseudo-server that owns the account database.

The crucial detail is that Dovecot is not a dumb pipe. Its socket protocol carries metadata beyond the raw SASL payloads, and Dovecot understands its role in the exchange. That awareness is exactly what a generic LDAP server cannot provide.

Why a transparent proxy to the LDAP server fails

Channel bindings

Mechanisms such as SCRAM-*-PLUS, GSSAPI, GSS-SPNEGO, and NTLM can tie the SASL handshake to the outer TLS session — for example by embedding the TLS session identifier in the SCRAM messages. If the authentication fails when the two sides report different identifiers, it is by design: it defeats a man-in-the-middle. In a relay setup the client's TLS channel terminates at your application server, while the application server opens a different TLS channel to LDAP. The bindings cannot match, and the directory — correctly — rejects the exchange as an attack. Microsoft's AD LDAP commonly requires channel bindings outright, so this fails hard and early.

The EXTERNAL mechanism

EXTERNAL derives identity from the TLS client certificate of the connection the server terminates. A relay cannot forward the certificate handshake itself, so EXTERNAL cannot survive the second hop. Designs that need this pass an explicit fingerprint — IRC servers, for instance, typically carry a SHA-256 fingerprint in their inter-server messages.

Service identity

Kerberos-based GSSAPI distinguishes services: xmpp/mail.example.com and ldap/mail.example.com are separate principals with separate keys. A client obtains a ticket for the XMPP service; slapd has no key to validate it. DIGEST-MD5 carries similar service-scope information. SCRAM notably does not distinguish services, which is why it is the one mechanism that could theoretically pass through — until a client negotiates the -PLUS variant and channel bindings kill it again.

SASL security layers

Lesser-known but real: GSSAPI, NTLM, and DIGEST-MD5 can negotiate an encryption layer as a side effect of authentication. Those keys are established between the client and whoever terminates SASL — the directory — leaving your application server unable to read or wrap the resulting traffic.

The fix: a SASL-aware authentication broker

Run one component as the authentication authority and let everything else talk to it. Dovecot fills this role well: it holds the LDAP service account, runs the mechanisms, and exposes a simple socket protocol designed for exactly this delegation.

# Dovecot: expose the auth socket to Postfix
service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
}

# Postfix: delegate SASL to Dovecot
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

If your server cannot speak to Dovecot, the fallbacks are Cyrus saslauthd with its LDAP backend (which brokers simple binds, so you are back to PLAIN toward LDAP) or simply accepting a per-user bind over TLS with a minimally privileged bind DN.

Choosing a design deliberately

• If shared passwords are the only goal, a per-user simple bind over TLS is the simplest and safest-to-audit option.
• If you want to concentrate sensitive access, use a broker so exactly one account can touch credentials, and keep its ACL narrow.
• Prefer SCRAM-SHA-256(-PLUS) and GSSAPI; retire DIGEST-MD5 and CRAM-MD5 unless something forces them.
• Match mechanisms to what your directory can actually verify — a mechanism neither end supports will only surface as a confusing negotiation failure.

Frequently Asked Questions

Is PLAIN over TLS actually a problem?

On the wire, no — TLS protects it. The residual risk is at the endpoints: the application process sees the plaintext password, so it can leak through memory dumps, logs, or a compromised service. SCRAM-style mechanisms remove that exposure.

Can ejabberd delegate SASL like Prosody does?

There is no native Dovecot SASL equivalent for ejabberd. The practical options are a per-user LDAP bind or an external authentication script that mediates between ejabberd and your directory.

Why does the LDAP server report an integrity or binding error during relay tests?

That is the channel-binding check working as intended. The client and the directory are on two different TLS sessions with different identifiers, so the server concludes the connection is intercepted and refuses authentication.

Does SCRAM solve pass-through completely?

Only partially. Plain SCRAM carries no service identity, so it is the best candidate for relaying, but many clients negotiate the -PLUS variant with channel bindings, which breaks any second TLS hop. The verifier must also live with whichever server terminates the exchange.

What should the LDAP service account be allowed to do?

As little as possible: ideally nothing beyond reading a narrow password attribute, or nothing at all if you use per-user binds. It should never have write access, and its use should be logged and audited.

Is DIGEST-MD5 a good middle ground?

No. It is deprecated, weakly supported, and still requires the server to access credential material. Prefer SCRAM or GSSAPI, and use a broker if you need to centralize verification.