The VPN Certificate Does Not Protect the LDAP Leg

A VPN login that checks credentials against a directory involves two separate network connections. The user's connection to the gateway is protected by the VPN's own certificate and protocol configuration. The gateway's connection to the directory is a different session with its own TLS settings, its own trust store and its own failure modes. Nothing about the first guarantees anything about the second.

That asymmetry is the mechanism behind a login that looks encrypted and still sends a bind password in the clear.

Two Connections, Two Trust Decisions

The outer session is what the user sees: a certificate bound to the VPN hostname, validated by the client, carrying the authentication exchange. The inner session belongs to the directory client inside the gateway, which opens its own connection and either negotiates TLS or does not. Each side validates the peer it talks to, using material from a different configuration file. A misconfigured inner leg stays invisible from the user's side, because the outer leg works exactly as intended.

That is why the failure is silent rather than loud. A gateway that never checks the directory's certificate still authenticates users correctly; it simply authenticates them over a channel it did not verify.

StartTLS and LDAPS, Chosen Deliberately

StartTLS opens as plain LDAP and upgrades in place, conventionally on port 389. LDAPS starts TLS with the connection, conventionally on 636. Both are legitimate and the adapter has to match what the directory offers. Requiring StartTLS is different from trying it and continuing when the upgrade fails, and that difference is exactly where a bind password can escape. Configure the strict mode, and do not allow an unprotected fallback for a password bind.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

The -ZZ flag is the whole point: the query fails rather than silently proceeding without the upgrade. Names and accounts in that line are examples. The OpenLDAP TLS documentation covers the trust settings behind it.

Which Trust Store Does the LDAP Client Read?

The OpenLDAP client library reads its own trust configuration, whether from the system file or from a plugin-specific setting. The VPN's CA directive applies to VPN peers and is not evidence that the LDAP library reads the same file. Use the directory hostname the certificate actually covers, plus the issuing chain the library trusts. On Active Directory, deploy a directory-service certificate with the right server-authentication usage rather than reasoning from a display name.

Every failover destination has to satisfy the same identity policy. An environment where the primary is validated and the secondary is not is worse than one with no failover, because the weaker path is discovered only during an outage.

The Bind Account Stays a Separate Problem

Protecting the transport does not reduce what the bind account may do. Directory search scope, group authorization and the privileges of the service account are separate decisions, and a broad bind account remains broad after TLS is enabled. Use the narrowest service account and search base the integration needs, and record the endpoint, TLS mode, trust owner and renewal process with the VPN configuration.

When a certificate mismatch appears, deploy the correct certificate or chain. Disabling verification converts a visible mismatch into an invisible one and leaves the second trust relationship untested.

Two connections, two owners, two renewal dates. Keeping them separate in the documentation is what keeps the login honest.