siliconflow/glauth

siliconflow/glauth

Description: A lightweight LDAP server for development, home use, or CI

Language: Go

License: MIT

Stars: 0

Forks: 0

Open issues: 0

Created: 2026-09-03T09:25:02Z

Pushed: 2026-09-04T03:45:09Z

Default branch: master

Fork: yes

Parent repository: glauth/glauth

Archived: no

README:

GLAuth: LDAP authentication server for developers

Go-lang LDAP Authentication (GLAuth) is a secure, easy-to-use, LDAP server w/ configurable backends.

!Docker pulls

• Centrally manage accounts across your infrastructure
• Centrally manage SSH keys, Linux accounts, and passwords for cloud servers.
• Lightweight alternative to OpenLDAP and Active Directory for development, or a homelab.
• Store your user directory in a file, local or in S3; SQL database; or proxy to existing LDAP servers.
• Two Factor Authentication (transparent to applications)
• Multiple backends can be chained to inject features

Use it to centralize account management across your Linux servers, your OSX machines, and your support applications (Jenkins, Apache/Nginx, Graylog2, and many more!).

Contributing

• Please base all Pull Requests on dev, not master.
• Format your code automatically using gofmt -d ./ before committing

Quickstart

This quickstart is a great way to try out GLAuth in a non-production environment. *Be warned that you should take the extra steps to setup SSL (TLS) for production use!*

1. Download a precompiled binary from the releases page. 2. Download the example config file. 3. Start the GLAuth server, referencing the path to the desired config file with -c.

• ./glauth64 -c sample-simple.cfg

4. Test with traditional LDAP tools

• For example: ldapsearch -LLL -H ldap://localhost:3893 -D cn=serviceuser,ou=svcaccts,dc=glauth,dc=com -w mysecret -x -bdc=glauth,dc=com cn=hackers

Make Commands

Note - makefile uses git data to inject build-time variables. For best results, run in the context of the git repo.

Documentation

:point_right: The latest version of GLauth's documentation is available at https://glauth.github.io/ :point_left:

Quickstart

Get started in three short steps

Usage:

glauth: securely expose your LDAP for external auth

Usage:
glauth [options] -c
glauth -h --help
glauth --version

Options:
-c, --config Config file.
-K AWS Key ID.
-S AWS Secret Key.
-r AWS Region [default: us-east-1].
--ldap Listen address for the LDAP server.
--ldaps Listen address for the LDAPS server.
--ldaps-cert Path to cert file for the LDAPS server.
--ldaps-key Path to key file for the LDAPS server.
-h, --help Show this screen.
--version Show version.

Configuration:

GLAuth can be deployed as a single server using only a local configuration file. This is great for testing, or for production if you use a tool like Puppet/Chef/Ansible:

glauth -c glauth.cfg

Here's a sample config wth hardcoded users and groups:

[backend]
datastore = "config"
baseDN = "dc=glauth,dc=com"
[[users]]
name = "hackers"
uidnumber = 5001
primarygroup = 5501
passsha256 = "6478579e37aff45f013e14eeb30b3cc56c72ccdc310123bcdf53e0333e3f416a" # dogood
sshkeys = [ "ssh-dss AAAAB3..." ]
[[users]]
name = "uberhackers"
uidnumber = 5006
primarygroup = 5501
passbcrypt = "243261243130244B62463462656F7265504F762E794F324957746D656541326B4B46596275674A79336A476845764B616D65446169784E41384F4432" # dogood
[[groups]]
name = "superheros"
gidnumber = 5501

More configuration options are documented here and in this sample file

Keycloak backend

datastore = "keycloak" exposes a Keycloak realm over LDAP (read-only), so that Keycloak can act as an identity provider for services such as vSphere, even without LDAP user federation.

[backend]
datastore = "keycloak"
keycloakhostname = "idp.example.com" # Keycloak server (HTTPS only)
keycloakport = 8443 # HTTPS port (defaults to 8443)
keycloakrealm = "master" # Realm whose users/groups are exposed
keycloakdomain = "example.com" # DNS domain deriving base DNs and objectSids
keycloakclientid = "glauth" # Client for user password binds and their searches
keycloakclientsecret = "..." # Secret of that client

Users and groups of the realm appear under cn=users, and cn=groups,, where ` is dc=example,dc=com for keycloakdomain = "example.com"`.

Two bind forms are supported:

Service accounts (OAuth 2.0 client credentials grant, one grant per connection, token refreshed automatically): the bind DN username is the Keycloak client_id and the bind password is the client client_secret:

ldapsearch ... -D "cn=,cn=bind,dc=example,dc=com" -w "" \
-b "cn=users,dc=example,dc=com" "(objectClass=user)"

Users (OAuth 2.0 resource owner password credentials grant, i.e. Keycloak's *direct access grants*): the bind DN username is the Keycloak username and the bind password is the user's password. The password is validated against the realm's token endpoint using the configured keycloakclientid/keycloakclientsecret; on success the connection's searches run as that client's service account:

ldapsearch ... -D "cn=,cn=users,dc=example,dc=com" -w "" \
-b "cn=users,dc=example,dc=com" "(objectClass=user)"

Searches accept arbitrary LDAP filters and attribute subsets over the users and groups containers. Simple equality filters on sAMAccountName/cn/userPrincipalName/mail/givenName/sn (groups: sAMAccountName/cn) are pushed down to Keycloak REST queries; all other filters are evaluated server-side over the full list. Results are limited to Keycloak's default page size (100 entries) when listing everything.

Service-account clients must be confidential with *Service accounts roles* enabled; give the service account the realm-management roles view-users, query-users and query-groups. The client named by keycloakclientid additionally needs *Direct access grants* enabled to validate user passwords. Add/Modify/Delete are not supported (read-only proxy). A complete example is in sample-keycloak.cfg.

Docker and Kubernetes:

Build an image directly...