d74308280b
An LDAP client only accepts the result that pairs with the request it
sent, and silently ignores anything else. Unrouted operations were
answered with a generic result, which encodes with the wrong tag, so a
search with an unexpected base DN (for example the empty base that
ldapsearch uses when -b is omitted) left the client waiting forever
instead of reporting an error.
Every failure path now terminates the request with the matching result
type, panics included, so a single wrapper covers all operations rather
than one responder per operation. NetAuth calls carry a 30s deadline
because the gRPC client dials lazily and applies none of its own, and
refused operations and failed authentication are logged, which is what
an operator needs when a client appears to hang.
💘 Generated with Crush
Assisted-by: Crush:qwen38_flash_next_mtp
|
||
|---|---|---|
| .github/workflows | ||
| internal | ||
| scripts | ||
| .gitignore | ||
| .goreleaser.yml | ||
| AGENTS.md | ||
| Dockerfile | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| main.go | ||
| README.md | ||
NetAuth LDAP Server
The NetAuth LDAP server acts as a bridge that allows legacy systems that understand LDAP to gain a read-only view of data in the NetAuth server.
It is recommended to install the NetAuth LDAP server on each host that requires this interface and to bind it to the loopback interface.
The format that the LDAP bridge exposes data in is slightly different
to that which is presented to an actual NetAuth client. The groups
are presented in a flattened format with all expansions processed, and
all groups are precented under a special ou=groups path. Similarly,
entities are presented under a ou=entities path under the base DN.
Speaking of the base DN, NetAuth doesn't have such a concept, so the
LDAP bridge takes this as a seperate configuration item on startup.
The provided format must be a valid domain name that will be split on
.. Prepended to this will be dc=netauth to clearly signify that
the data retrieved is coming from NetAuth.