GLAuth: an LDAP server you configure with a TOML file

The problem GLAuth targets: a directory that starts in one command

Standing up OpenLDAP or Active Directory for a test suite or a three-machine homelab means schema files, an admin password bootstrap, and a service that outlives the thing you were testing. GLAuth takes the opposite position. The README describes it as a lightweight alternative to OpenLDAP and Active Directory for development or a homelab, and the quickstart is four steps: download a precompiled binary from the releases page, download the example config, start the server with ./glauth64 -c sample-simple.cfg, and query it with a normal LDAP client. There is no slapd.conf, no olcDatabase block, no directory initialisation step. The audience is developers who need their application's LDAP code path exercised, and homelab operators who want one place to hold Linux accounts, SSH keys and passwords for a handful of servers. The README also lists Jenkins, Apache/Nginx and Graylog2 as applications people point at it. That is a bind-and-search workload, not a directory management workload, and the project is shaped accordingly.

Backends are the architecture: config, S3, upstream LDAP, SQL

The [backend] section is where GLAuth stops being a toy. The datastore key selects the source of truth. With datastore = "config" the user directory lives in the same TOML file as the server settings, and the README's sample shows [[users]] and [[groups]] blocks with name, uidnumber, primarygroup, gidnumber, passsha256 or passbcrypt, and an sshkeys array. With datastore = "ldap" GLAuth stops being a store and becomes a proxy: the sample sets servers = [ "ldaps://server1:636", "ldaps://server2:636" ] and forwards to an existing directory. The README states that a local file can also live in S3, that SQL databases and PAM are reachable through optional plugins, and that multiple backends can be chained to inject features. That last point is the interesting design decision. Chaining lets you keep an authoritative upstream and add local entries on top, which is how you would give a CI job a service account without writing to the production directory. The cost is that the resolution order and conflict behaviour between chained backends is the kind of thing you need to read the full documentation for, because the README does not spell it out. Two factor authentication is described as transparent to applications, meaning the second factor is handled inside GLAuth rather than by the client, which is a different integration model from an LDAP server that simply returns a bind success or failure.

Running it: the flags and config keys that matter

The usage block in the README is short enough to quote in full. The binary takes -c or --config with a file or an s3url, and there are three AWS flags: -K for the key id, -S for the secret key, -r for the region, which defaults to us-east-1. Listener addresses are overridden with --ldap <address> and --ldaps <address>, and TLS material is supplied with --ldaps-cert <cert-file> and --ldaps-key <key-file>. The plain invocation is glauth -c glauth.cfg. The quickstart warns in italics that you should take the extra steps to set up SSL (TLS) for production use, which is a fair reading of the defaults: the sample query targets ldap://localhost:3893, an unencrypted listener, and the sample passwords are SHA-256 or bcrypt hashes pasted into a file. A minimal config needs [backend] with datastore and baseDN, then one or more [[users]] and [[groups]]. The baseDN in the sample is dc=glauth,dc=com, and the bind DN in the ldapsearch example is cn=serviceuser,ou=svcaccts,dc=glauth,dc=com, so the DN layout is derived from the config rather than configured per entry. The makefile, per the README, uses git data to inject build-time variables, so building from a source tarball rather than a clone will not produce the same version string.

Where GLAuth is the wrong tool

The README markets GLAuth for development, home use and CI, and that framing is honest about the ceiling. Nothing in the supplied material describes replication, multi-master or failover between GLAuth instances, so a single process is a single point of failure for anything that depends on it. There is no mention of an administrative protocol for creating users or changing passwords at runtime, which means the config datastore is effectively read-only in operation: an account change is a file edit and a restart, or a change in whatever upstream the backend points at. The datastore = "config" mode also puts password hashes in a plaintext TOML file, and the README's own quickstart tells you to add TLS yourself, so the default posture is a development posture. Schema extensibility is another boundary. The sample covers users, groups, uidnumber, gidnumber, primarygroup and sshkeys, which is enough for POSIX identity and SSH public key lookup, but the material says nothing about custom object classes, ACLs or per-attribute access control. If your application reads directory attributes outside that set, or if you need to delegate password resets to end users, GLAuth will not carry that load. It is an authentication endpoint, not a directory service with an administrative surface.

How it differs from OpenLDAP and from a test double

The obvious comparison is OpenLDAP, and the difference is not performance, it is the unit of configuration. OpenLDAP's cn=config backend stores its own configuration inside the directory it serves, which makes replication and online reconfiguration possible and makes the first hour of setup painful. GLAuth keeps configuration in a TOML file passed with -c, optionally fetched from S3, which makes the whole server reproducible from a single artifact and trivial to reset. The trade is that anything requiring online state, such as adding a user without touching a file, falls outside the model. A second comparison is to a stub LDAP library embedded in the test process. Those avoid a network listener entirely and are faster to start, but they only satisfy the client library that knows about them. GLAuth speaks the wire protocol on port 3893, so the same instance can be queried by ldapsearch, by a Jenkins plugin, or by an SSH client doing public key lookup, which is the point of running a server rather than a mock. If your only consumer is one application's test suite, a mock is less machinery. If several consumers need the same accounts, GLAuth is the smaller commitment.

Maintenance, releases and what the MIT licence means here

GLAuth ships tagged releases, with v2.5.2 in July 2026 following v2.5.1 a week earlier and v2.5.0 in April 2026, and the repository is not archived. The README asks contributors to base pull requests on the dev branch rather than master and to run gofmt -d ./ before committing, which tells you master is the release branch and dev is where changes land. For an operator, the upgrade path is to replace the binary and restart with the same config file, since the config is external to the process. That is cheap, but it also means there is no migration step to run and no schema version to reconcile, so a config key that changes meaning between releases will surface as a startup failure or a silently different bind result rather than as an upgrade error. The MIT licence is permissive and places no conditions on how you deploy or redistribute the binary. It says nothing about the data you put in the config file, and it does not change the fact that the quickstart's default listener is unencrypted. If you enable TLS with --ldaps-cert and --ldaps-key, the certificate lifecycle is yours to manage; GLAuth does not obtain or renew certificates for you.

What to check before you commit to it

Start with the client, not the server. Run the quickstart exactly as written, then point your actual consumer at ldap://localhost:3893 and see whether it binds and searches successfully. The README's test command uses a service account under ou=svcaccts, so check whether your consumer expects to bind as a user entry or as a dedicated account, and whether it needs a DN shape that the baseDN plus entry name scheme can produce. Second, decide the backend before you populate anything. If you already run a directory, datastore = "ldap" with the servers list is the lower-risk choice because GLAuth holds no state. If you do not, the config datastore is fine but you should move it to S3 or a plugin-backed store before more than one person depends on it, since a local file is a local file. Third, confirm the two factor behaviour if you intend to use it, because the README describes it as transparent to applications and that is a claim about where the second factor is enforced, not a configuration recipe. The material supplied here does not include the full documentation site, so the file format reference and the plugin list are the next things to read.

Editorial conclusion

Adopt GLAuth if you need a bind-capable LDAP endpoint for a test suite, a homelab or a small set of Linux and macOS clients, and you are willing to run it from a config file or a chained backend. Do not adopt it as the directory of record for an organisation with delegated administration, replication or schema requirements, because the README and the usage output describe none of those. Verify first that your client only needs simple bind and search: start it with ./glauth64 -c sample-simple.cfg and run the ldapsearch example from the README against port 3893 before you commit to a backend design.

Official sources

1. glauth/glauth on GitHub
2. Issues
3. License: MIT
4. README
5. Releases