ldap

go-ldap/ldap is the de facto standard LDAP v3 client library for Go, implementing the wire protocol described in RFC 4511 directly on top of ASN.1 BER encoding rather than wrapping a native LDAP SDK. It gives Go programs a typed, idiomatic API for the full set of directory operations: binding (simple, unauthenticated, SASL, GSSAPI, and NTLM), searching with optional paging or async streaming, adding, modifying, deleting, and renaming entries, password modification, and vendor extended operations.

Beyond the base protocol, the library covers the practical concerns of running LDAP against real directory servers: TLS and STARTTLS connection setup with custom dialers, distinguished-name parsing per RFC 4514, server-side sort and content-synchronization controls, and a Kerberos/GSSAPI bind path for integrating with Active Directory environments. Its API surface is defined as a Client interface, making it straightforward to mock in tests that exercise LDAP-backed authentication code without a live directory server.

It is widely used as the LDAP layer inside identity and access-management tooling, self-hosted SSO gateways, and infrastructure that needs to authenticate against corporate directory services such as OpenLDAP or Active Directory.

What You Get

• A Client interface covering Bind, Search, Add, Del, Modify, ModifyDN, Compare, and Extended operations against any RFC 4511-compliant directory server
• Multiple bind mechanisms out of the box: simple bind, unauthenticated bind, SASL/external bind, GSSAPI (Kerberos), and NTLM
• Connection setup over plain TCP, implicit TLS, or STARTTLS, including support for a custom net.Dialer
• Search variants for one-shot results, server-side paged search, and asynchronous streaming search via channels
• RFC 4514-compliant distinguished name parsing and construction through the dn.go module
• Server-side sort control, content synchronization (RFC 4533), and DirSync support for directory replication and change tracking
• A dedicated password-modify extended operation (RFC 3062) and WhoAmI request (RFC 4532) implementation

Common Use Cases

• Authenticating application users against a corporate Active Directory or OpenLDAP server as part of an SSO or single-sign-on gateway
• Building internal admin tooling that reads or writes directory entries — provisioning accounts, updating group membership, rotating passwords
• Synchronizing user and group data from an LDAP directory into an application database using paged or content-sync search
• Implementing custom identity-provider adapters where an existing IAM product needs an LDAP backend written in Go
• Writing infrastructure health checks or CLI utilities that query directory servers for diagnostics

Under The Hood

Architecture The library is organized around a single Conn struct in conn.go that owns the TCP/TLS socket and a background message-processing loop; each LDAP operation (bind.go, search.go, add.go, modify.go, del.go, extended.go) builds an ASN.1 BER packet via the go-asn1-ber dependency, hands it to the connection’s message dispatcher, and waits on a per-request channel for the correlated response. The public surface is defined as a Client interface in client.go, decoupling callers from the concrete Conn implementation and making LDAP-backed code straightforward to mock in tests. Request/response types live in dedicated files per operation (request.go, response.go), and DN parsing is isolated in dn.go — a design that mirrors the RFC’s own operation boundaries rather than imposing an ad hoc abstraction, so a change to how one operation is framed does not ripple into unrelated files.

Tech Stack Written in Go targeting a recent toolchain, with go-asn1-ber/asn1-ber handling BER encoding/decoding of the LDAP wire format, and optional integrations pulled in via go-ntlmssp (NTLM), sspi (Windows SSPI), and gokrb5 (Kerberos/GSSAPI) for the non-simple bind mechanisms. golang.org/x/crypto and the standard library’s crypto/tls cover TLS/STARTTLS. There is no HTTP framework or database layer involved — the module’s only real external dependency surface is protocol- and auth-mechanism-specific.

Code Quality The module ships an extensive test suite (roughly a hundred test functions across _test.go files covering bind, search, filter parsing, DN parsing, and control encoding) using testify for assertions, alongside examples_test.go files that double as runnable documentation. CI runs golangci-lint against the v3 module directory on every pull request, and a Makefile wires up gofmt, go vet, and integration tests against a local directory server via Docker/Podman. Error handling is centralized through a typed Error type in error.go that carries the numeric LDAP result code, rather than opaque string errors, which lets callers branch on protocol-level failure reasons.

What Makes It Unique Rather than wrapping a native LDAP client via cgo, the library re-implements the BER encoding and full RFC 4511 operation set natively in Go, which is what makes it viable in cross-compiled, statically linked binaries with no system LDAP dependency. Its bind path is unusually complete for a community library — simple, SASL, GSSAPI, and NTLM are all first-class — which is why it has become the standard choice for Go services that need to authenticate against Active Directory specifically, not just generic OpenLDAP.