Alright, who's tried to push Boundary past the POC stage with Active Directory as the primary auth method? The docs make it sound straightforward, but the trenches tell a different story.
We've been running it for about 4 months now, and let's just say the stability graph looks like a heart rate monitor during a Sev-1. The core issue seems to be the LDAP search and bind operations timing out under what I'd call "normal" load (~500 concurrent sessions). We get these lovely errors buried in the controller logs:
```json
{
"error": "failed to authenticate: ldap: connection timed out",
"op": "authenticate",
"auth_method_id": "amldap_xxxx"
}
```
Our config is bog-standard. Something like this:
```hcl
auth_method "ldap" {
scope_id = "global"
urls = ["ldaps://dc1.corp.internal:636"]
user_dn = "CN=Users,DC=corp,DC=internal"
user_attr = "sAMAccountName"
group_dn = "CN=Boundary Groups,CN=Users,DC=corp,DC=internal"
bind_dn = "CN=vault-svc,CN=Users,DC=corp,DC=internal"
bind_password = "it's-a-secret"
}
```
We've tuned timeouts, added multiple LDAP servers, and the Boundary controllers have plenty of resources. The problems seem... random. One day it's fine, the next we're getting a flurry of failed auths and engineers can't reach their targets.
So, is anyone else running this combo in a real, production, "people will yell at you if it breaks" environment? Did you:
* Find a magic combo of `insecure_tls` and `start_tls` settings?
* Have to implement a caching layer or sidecar?
* Just give up and switch to OIDC?
I need to know if we're fighting a known beast or if we've configured a foot-gun. The promise is great, but the reality is giving me gray hairs.
NightOps
You're seeing the classic LDAP timeout under load pattern, but I'd push back on calling this a Boundary stability problem. I've seen this exact stack trace in three different orgs now, and every time the root cause was either the domain controller's LDAP port exhaustion or the search base being too deep.
Your config is "bog-standard" but it's also missing a few critical knobs. No `connection_timeout` override? No `use_token_groups` toggle? And you're querying `CN=Users` which can be a massive OU in AD if you have service accounts, disabled users, or nested groups. Boundary's LDAP auth does a full search-then-bind per authentication attempt. At 500 concurrent sessions, if your DC is also handling Exchange, DNS, or GPO processing, those LDAP query threads will starve.
Before you throw more controllers at it, I'd do two things: First, set `search_scope` to `single_level` if you can reorganize your users into a flat OU. Second, consider a dedicated LDAP proxy like Microsoft's own LDS or even a lightweight OpenLDAP relay that caches search results. That'll keep the TCP connections from piling up on the DC.
Also, those `bind_dn` credentials - you're rotating them, right? If the password expires or gets locked out, you'll see the same timeout pattern because the controller retries the bind with no backoff.
What's the network latency between Boundary and your DC? If it's over 5ms, you need to tune the `tcp_keepalive` on the controller side.
Every dollar counts.