GLAuth

Centralized authentication, honestly reviewed. No marketing fluff, just what you get when you self-host it.

TL;DR

• What it is: A lightweight, MIT-licensed LDAP authentication server written in Go — a practical alternative to OpenLDAP and Active Directory for developers, homelabs, and small teams [1].
• Who it’s for: Sysadmins, homelab operators, and small engineering teams who want centralized login across Linux servers and internal tools without standing up a full Active Directory or OpenLDAP instance [1].
• Cost savings: Active Directory requires a Windows Server license (starting around $500–$1,200/server) plus ongoing CALs. OpenLDAP is free but notoriously painful to configure. GLAuth runs as a single binary or Docker container on a $5/mo VPS — zero license cost [1].
• Key strength: Single binary, file-based config, starts in minutes. No database required for small deployments — user accounts live in a TOML file [1].
• Key weakness: This is not a product for non-technical founders. LDAP is a protocol with 1980s DNA, and GLAuth doesn’t hide that. If you don’t already know what a DN, base DN, or ldapsearch flag is, this tool will not teach you [1].

---

What is GLAuth

GLAuth (Go-lang LDAP Authentication) is an LDAP server you can run as a single binary. The pitch in the README is blunt: “A secure, easy-to-use, LDAP server w/ configurable backends” [1]. It’s positioned as a lightweight alternative to OpenLDAP and Active Directory for development environments, homelabs, or CI pipelines [1].

What does that mean in practice? You set up GLAuth once on a server, define your users and groups in a config file, and then every service that supports LDAP authentication — Jenkins, Nginx, Graylog2, Apache, dozens of others — can authenticate against it. One user database, one password to manage across your whole infrastructure [1].

The project has 2,807 GitHub stars and 240 forks, with 14 releases and the latest (v2.4.0) shipped April 28, 2025 [1]. It’s been around long enough to be stable, and the release cadence suggests active maintenance without being a runaway growth story. This is a niche infrastructure tool, and the star count reflects that — it’s not trying to be n8n.

GLAuth is written entirely in Go (85.8% of the codebase), which gives it the single-binary distribution model and low resource footprint that Go is known for [1]. No JVM, no Python runtime, no node_modules directory to babysit.

---

Why People Choose It

Independent reviews weren’t available for this article — the tool is niche enough that mainstream tech publications haven’t covered it. The case for GLAuth, therefore, comes from the README, the documentation site, and the straightforward math of the alternatives [1][2].

The comparison that matters most is GLAuth versus OpenLDAP. OpenLDAP is the dominant open-source LDAP server and the standard answer for centralized authentication on Linux. It’s also notorious for configuration that requires significant expertise — schema files, ACLs written in a domain-specific language, slapd.conf that looks like it was designed to be hostile to newcomers. GLAuth replaces all of that with a TOML config file where you add users by typing their name, UID number, and a password hash [1]. That’s the core value proposition.

The comparison that matters second is GLAuth versus running no centralized auth at all — which is what most homelab operators and small teams actually do. Individual SSH keys scattered across servers, separate login credentials per service, no single place to disable an account when someone leaves. GLAuth fixes that problem with minimum installation surface area [1].

For CI and development environments specifically, GLAuth exists to solve a real pain: integration tests that need an LDAP endpoint. Spinning up an actual OpenLDAP instance for testing is overkill. A single GLAuth binary pointed at a config file gives you a real LDAP server in under 60 seconds [1].

---

Features

Based on the README and documentation [1][2]:

Core authentication:

• Standard LDAP protocol on port 3893 (configurable) [1]
• LDAPS (TLS) support with cert and key file configuration [1]
• Passwords stored as SHA256 or bcrypt hashes — no plaintext [1]
• SSH public key storage per user, queryable via LDAP — useful for automating SSH key distribution across servers [1]
• Group membership management [1]

Two-factor authentication:

• 2FA support that is described as “transparent to applications” — the TOTP token is appended to the password at login time, so applications don’t need to be modified to support it [1]

Backend storage options:

• File backend: Users and groups defined in a TOML config file. Can be a local file or a file on S3, which enables config distribution without a shared filesystem [1]
• SQL database backend: Via optional plugin — connects to a SQL datastore for user directory [1]
• LDAP proxy backend: Forwards queries to an existing LDAP server. Useful for adding GLAuth features (2FA, SSH keys) in front of an existing Active Directory or LDAP instance [1]
• PAM backend: Via optional plugin [1]

Infrastructure management:

• Centralized SSH key management across cloud servers [1]
• Linux account provisioning (UID numbers, primary groups) [1]
• Works as a drop-in auth backend for Jenkins, Apache, Nginx, Graylog2 [1]

Operational features:

• Docker support (Docker Hub image available) [1]
• Single binary with a -c flag pointing to the config — no installer, no service registration required [1]
• AWS SDK integration for S3-hosted configs (with --aws-key-id, --aws-secret-key, --aws-region flags) [1]
• Multiple backends can be chained — meaning you can compose behaviors (e.g., inject 2FA in front of an existing LDAP proxy) [1]

What’s notably absent: a web UI, a REST API, any GUI for managing users. Everything is config file manipulation. This is a deliberate architecture choice — it keeps the footprint small and the behavior auditable — but it means every user add/modify/delete is a text file edit and a process restart.

---

Pricing: SaaS vs Self-Hosted Math

GLAuth itself is MIT-licensed and free [1]. The cost conversation is about what you’re replacing.

Alternatives and their costs:

Active Directory:

• Requires Windows Server. Licensing starts around $500–$1,200 for the server OS, plus Client Access Licenses (CALs) at roughly $35–$50 per user for Standard edition.
• Azure Active Directory (now Entra ID) starts free for basic SSO but the P1 tier (needed for conditional access, self-service password reset) runs $6/user/month — $720/year for a 10-person team.

JumpCloud:

• The closest modern SaaS equivalent to what GLAuth does. Free for up to 10 users. After that, $11/user/month for the Platform tier — $1,320/year for 10 users.

Okta:

• Workforce Identity starts at $2/user/month for basic SSO, scaling rapidly to $8–$15/user/month once you add MFA and provisioning.

GLAuth self-hosted:

• Software: $0 (MIT) [1]
• VPS to run it: $5–10/month on Hetzner or DigitalOcean
• Your time to configure it initially: 1–4 hours depending on LDAP familiarity
• Total annual cost for any team size: ~$60–$120/year

For a 10-person engineering team currently paying JumpCloud $1,320/year, self-hosted GLAuth is a legitimate $1,200/year saving — assuming someone on the team is comfortable configuring LDAP. Data on pricing is not available for all tiers from public sources; verify current pricing with each vendor.

---

Deployment Reality Check

The README quickstart is honest about one thing: “Be warned that you should take the extra steps to setup SSL (TLS) for production use!” [1] This is the first warning in the setup guide, and it’s appropriate.

What you need:

• A Linux server (or Mac — GLAuth is a single binary)
• The precompiled binary from the GitHub releases page [1]
• A TOML config file (a sample is in the repository) [1]
• A domain and TLS certificate if running in production (Let’s Encrypt + Caddy works)
• Basic familiarity with what LDAP is and how to test it with ldapsearch

The config model: Users and groups are defined in TOML:

[backend]
  datastore = "config"
  baseDN = "dc=glauth,dc=com"

[[users]]
  name = "alice"
  uidnumber = 5001
  primarygroup = 5501
  passsha256 = "..."
  sshkeys = [ "ssh-ed25519 AAAA..." ]

Adding a user = adding a [[users]] block and restarting GLAuth. There’s no API call, no web form. For a homelab with 5–10 users, this is fine. For a 50-person team with monthly onboarding/offboarding, this workflow will irritate your ops team.

Docker path: GLAuth has a Docker image available [1]. A Docker Compose stack with GLAuth is straightforward — no database required for the file backend, so it’s essentially a single container with a mounted config file.

What can go sideways:

• LDAP debugging is painful. If a service can’t bind, the error messages from both sides (GLAuth and the client) are often cryptic. Budget time for ldapsearch debugging when connecting new services.
• No hot reload — config changes require a process restart. In Docker this is a container restart, which means a brief auth outage for anything actively querying it.
• The SQL and PAM backends are optional plugins, which means separate compilation or finding pre-built plugin binaries. The documentation site covers this [2], but it adds setup friction beyond the file backend case.
• No built-in high availability. If your GLAuth instance goes down, LDAP auth fails for everything pointing at it. The LDAP proxy backend can partially address this by chaining to a secondary server, but GLAuth itself has no native clustering [1].
• Production deployments need TLS. The quickstart skips this for simplicity, but running LDAP in cleartext means passwords transit the network unencrypted [1].

Realistic time estimate: 30–60 minutes from binary download to a working LDAP server with test users, for someone who has used LDAP before. Half a day to a full day for someone learning LDAP concepts simultaneously. For a non-technical user with no LDAP background, this tool is not the right starting point.

---

Pros and Cons

Pros

• Single binary, minimal footprint. No database required for basic deployments. Download, point at a config, run. Compare this to OpenLDAP’s installation, schema loading, and slapd.conf ceremony [1].
• MIT license. No commercial restrictions, no “Fair-code” ambiguity, no vendor relationship required [1].
• S3-backed config. Storing the config in S3 enables synchronized config across multiple instances without a shared filesystem — a genuinely useful feature for distributed homelabs [1].
• SSH key management built in. Centralizing SSH keys via LDAP is not a feature most identity tools include. GLAuth makes it a first-class attribute [1].
• Transparent 2FA. TOTP without requiring application changes is legitimately clever engineering — the app doesn’t know 2FA is happening [1].
• Chained backends. Composing behaviors (adding 2FA in front of an existing LDAP proxy, for example) is architecturally clean [1].
• Active maintenance. v2.4.0 shipped April 2025, 14 total releases, 333 commits — this is not abandoned software [1].

Cons

• No web UI. Every user management operation is a text file edit. Acceptable for a homelab, annoying at scale.
• No hot reload. Config changes require a process restart and a brief auth outage.
• No native HA. Single point of failure without additional infrastructure around it.
• LDAP is LDAP. The protocol itself is arcane, the debugging tools are command-line only, and the error messages are historically unhelpful. GLAuth makes LDAP easier, not easy.
• Plugin friction. SQL and PAM backends require plugin binaries, adding setup complexity beyond the basic file backend case [1].
• Small community. 2,807 stars and 240 forks is not a large community. Stack Overflow coverage is sparse. When you hit an unusual problem, you may be reading GitHub issues rather than finding a clean answer elsewhere [1].
• No REST API or web management. Programmatic user management means scripting config file manipulation and restarting the service — there’s no management API to call [1].

---

Who Should Use This / Who Shouldn’t

Use GLAuth if:

• You’re a homelab operator running 3–20 users who want one place to manage SSH keys and service logins across a handful of Linux machines.
• You’re building a CI/CD pipeline that needs a real LDAP endpoint for integration testing — GLAuth is the fastest path to that [1].
• You have an existing LDAP/AD infrastructure and want to add 2FA without touching the core directory — use GLAuth as a proxy layer [1].
• You’re a developer who needs a local LDAP server to develop against and doesn’t want to run a full OpenLDAP stack.
• You or someone on your team is comfortable with LDAP concepts and TOML config files.

Skip it (look at JumpCloud or Authentik) if:

• You need a web UI for user management that a non-technical person can operate.
• You need SCIM provisioning, self-service password reset, or SSO flows (SAML, OIDC) — GLAuth doesn’t provide these.
• You have more than 20–30 users and regular onboarding/offboarding — the config-file workflow won’t scale gracefully.
• Your team has no LDAP experience and you need this to “just work” without a learning curve.

Skip it (stay on Active Directory or Entra ID) if:

• You’re on Windows-first infrastructure where AD integration is already built into every system.
• Your compliance framework requires an enterprise identity provider with audit logs, certifications, and vendor support.

Skip it (look at Kanidm or FreeIPA) if:

• You want a modern open-source identity server with a web UI, OIDC support, and a REST API for a small-to-medium team.
• You need something more fully featured than GLAuth but less expensive than JumpCloud.

---

Alternatives Worth Considering

• OpenLDAP — the standard open-source LDAP server. More features, more configuration surface, dramatically harder to set up correctly. GLAuth exists specifically because OpenLDAP configuration is painful.
• Kanidm — a newer, Rust-based identity server that supports LDAP, RADIUS, and OIDC with a web UI. More opinionated, more modern, more full-featured. Worth evaluating if you need beyond what GLAuth provides.
• FreeIPA — full identity management suite from Red Hat. Combines LDAP, Kerberos, DNS, and a web UI. Significantly heavier than GLAuth; intended for organizations with a real sysadmin.
• Authentik — self-hosted SSO/IdP platform with LDAP, SAML, OIDC, and a web UI. If you need more than just LDAP, Authentik covers the broader identity problem.
• JumpCloud — the SaaS option that replaces what GLAuth does, plus MDM, RADIUS, and a full admin console. Free for ≤10 users; $11/user/month after.
• Lldap — another lightweight LDAP server alternative, written in Rust, with a simple web UI for user management. Directly comparable to GLAuth; younger project.

For a homelab operator who just wants to centralize logins: the realistic shortlist is GLAuth vs lldap. GLAuth if you want the most minimal footprint and are comfortable editing config files. lldap if you want a web UI for user management.

---

Bottom Line

GLAuth is a well-executed solution to a specific problem: running a real LDAP server with minimum setup ceremony and zero license cost. It’s not trying to be Okta, JumpCloud, or even FreeIPA. It’s trying to be the tool you stand up in 45 minutes when you need centralized SSH key management across five Linux servers and don’t want to deal with OpenLDAP’s configuration model. For that use case, it succeeds cleanly. The MIT license, single-binary distribution, S3-backed config, and transparent 2FA are genuinely useful features that reflect careful design decisions.

The honest caveat: if you’re a non-technical founder reading this, GLAuth is probably not your tool. LDAP is infrastructure plumbing — not the kind of thing you set up over a coffee. If you need centralized identity for a small team and want something you can actually operate without a sysadmin, look at Authentik or JumpCloud’s free tier first. But if you have someone technical on your team who’s spent time with Linux servers and needs a no-cost, no-friction LDAP server, GLAuth is the answer.

---

Sources

1. GitHub — glauth/glauth: A lightweight LDAP server for development, home use, or CI (Repository README, 2,807 stars, MIT license, v2.4.0 released Apr 28, 2025). https://github.com/glauth/glauth
2. GLAuth Official Documentation. https://glauth.github.io/

Note: Third-party independent reviews of GLAuth were not available for this article. The tool occupies a niche infrastructure space with limited mainstream coverage. All claims above are sourced from the primary repository and documentation. Readers should weigh this accordingly and consult the GitHub issues and Gitter/Matrix community for real-world deployment experiences before making production decisions.