LDAP Channel

Point your existing LDAP apps at Scribe. They’ll keep working — same protocol, same tools, same queries — but now they’re reading from PostgreSQL instead of hitting your directory server directly.

Configure one or more listeners:

channels.ldap {
  listen = [
    { port = 10389 }                        # Plain LDAP
    { port = 10636, ssl {                    # LDAPS
      ca = "certs/ca.pem"
      cert = "certs/server.pem"
      key = "certs/server-key.pem"
    }}
  ]
}

Test with any LDAP client:

ldapsearch -H ldap://localhost:10389 -x -D "u:alice" -W \
  -b "ou=users,dc=example,dc=com" "(cn=john*)" cn mail

For all listener settings (host binding, client certificates, socket options, connection limits), see Configuration Reference.

Scribe authenticates LDAP bind requests locally using the unified auth infrastructure. Several bind DN formats are supported:

# Bind with bearer token
ldapsearch -H ldap://localhost:10389 -x \
  -D "bearer:eyJhbGciOiJSUzI1NiJ9..." -w "ignored" \
  -b "ou=users,dc=example,dc=com" "(cn=*)"

# Bind with username
ldapsearch -H ldap://localhost:10389 -x \
  -D "u:alice" -W \
  -b "ou=users,dc=example,dc=com" "(cn=*)"

Authentication methods are tried in order (e.g., bearer, then ropc, then ldap). Both channels.ldap.auth and channels.identity-hub.auth inherit from global auth {} and can override enabled, methods, and rules per channel. See Authentication for method configuration.

The LDAP channel supports Proxy Authorization V2 (RFC 4370) for delegation — a service account binds, then acts on behalf of a user:

ldapsearch -H ldap://localhost:10389 -x \
  -D "cn=service,dc=example,dc=com" -W \
  -e "authzid=dn:uid=alice,ou=users,dc=example,dc=com" \
  -b "ou=users,dc=example,dc=com" "(cn=*)"

ProxyAuth accepts the same formats as bind: bearer:<token>, dn:<dn>, u:<username>, or plain values. DN and username formats (including plain values) require auth.ldap configuration so Scribe can verify DNs and resolve usernames; without it, ProxyAuth with those formats returns AUTHORIZATION_DENIED. Use bearer:<token> when LDAP auth is not configured. Bearer tokens with a dn claim are subject to auth.ldap.base scope validation — the DN must be a strict descendant of the base.

1. Bind establishes the service identity (who’s calling)
2. ProxyAuth establishes the subject identity (on whose behalf)
3. The backend receives operations with a ProxyAuth control containing the resolved effective DN

All authentication happens locally within Scribe. The upstream LDAP server only sees the resolved DN.

Standard LDAP search with filters, scopes, and attribute selection:

# Subtree search with filter and specific attributes
ldapsearch -H ldap://localhost:10389 -x -D "..." -W \
  -b "ou=users,dc=example,dc=com" \
  -s sub "(|(cn=john*)(mail=*@example.com))" cn mail uid

Use Simple Paged Results for large result sets:

ldapsearch -H ldap://localhost:10389 -x -D "..." -W \
  -b "ou=users,dc=example,dc=com" \
  -E pr=100/noprompt "(objectClass=inetOrgPerson)"

VLV (Virtual List View) is also supported.

Server-Side Sorting works on indexed attributes:

ldapsearch -H ldap://localhost:10389 -x -D "..." -W \
  -b "ou=users,dc=example,dc=com" \
  -E sss=-sn "(objectClass=inetOrgPerson)"

Access rules are evaluated for all operation types. The exact checks differ:

Search has the strictest gating: when channels.ldap.auth.enabled is true, unauthenticated Search requests are rejected before access rules are evaluated. Non-Search operations (add, modify, etc.) rely solely on access rules. Extended operations: StartTLS is always forwarded to the backend (RFC 4513 requires pre-bind transport negotiation); other extended operations are subject to access rules and ProxyAuth validation.

Bind failure delay: failed bind attempts use auth.failure-delay (default 2s) before responding, mitigating brute-force attacks. Does not apply when auth is delegated to the backend.

Some requests can’t be answered from the local cache — schema queries, unsupported filters, directory browser operations. When that happens, Scribe forwards the request to the upstream LDAP server.

Set channels.ldap.prevent-delegation = true to fail these requests instead of forwarding them. See Configuration Reference for delegation reasons and telemetry.

See Signals for metrics, Logging and Traces for trace debugging, Error Handling for the complete ResultCode mapping.