A lightweight LDAP server
Clone or download
benyanke Pulling in latest changes and fixes for 1.1.1 (#56)
* Adding a few test dockerfiles

* Continued work on docker builds

* Basic example of docker build and run works - see build.sh for now

* Continuing to work on docker build

* Removing testing from build script, since it belongs later in process

* Implementing dumb init

* Docker build fully switched to alpine

* Setting up alpine build

* Cleaning up dockerfile

* Cleaning up repo in prep for merge

* Updating permissions for clean merge

* Removing old ansible cruft, as per #12

* Removing binaries (since we now build)

* Updating sample config to use new fields now available

* Testing travis

* another travis test

* Still working on travis builds

* Fix missing amazon packages

* Merge in Travis config feature branch (#26)

* Adding version string

* Fixing and cleaning up docker build

* Adding image hashing and verification to 'make all'

* Testing build

* Running gofmt to fix build

* Testing switching travis to make

* Testing build again

* Merging in Fixes from travis-build feature branch (#33)

This includes an integration test which runs glauth and compares ldapsearch snapshot output stored in the repo compared to the snapshot output of the glauth.

Additionally, removing old versions of go, and adding windows and linuxar builds (but not tests) to the makefile, and consequently, the travis build.

While the mac, linux-arm, and windows binaries are not able to be run in travis, they are able to be at least compiled.

* Remove needless comment from integration test

* Adding 'is-process-running' check before integration tests run, to clearly note if the program crashes on run

* Switching from 1 sec to 2 sec timeout for integration test

* Adding back config file to fix build. Previous commit intended to see if build failed (and it did)

* Add support for including groups in groups (#23)

* Add support for including groups in groups
* Pulling in Makefile structure to allow easier testing and builds

* Forgot to remove spare test

* Add Version Info at Buildtime  (#39)

Adds the build info to the binary at buildtime via buildtime variables. This is shown by `./glauth --version`.

Example output for a non-release:
```
GLauth
Non-release build from branch feature/buildversion

Build time: 20180531_181011Z
Commit: 07ba631
```

And example of a built release:
```
GLauth v2.3.4

Build time: 20180601_041330Z
Commit: 931d666

```

* Fixing Broken Docker Build (#41)

Forgot to include go-bindata run in Dockerfile.

* Removing leftover TODO from merge

* Testing releases

* Testing releases

* Testing releases

* Adjusting logging

* Add new group tests to integration tests

* add cleanup to test process

* Add documentation about otherGroups, which was a previously undocumented field.

* Auto fetching bindata during build so it's not needed to be done manually

* Syntax fix

* starting framework for unit tests

* Merging in ongoing progress from Feature/travis build (#44)

Fixes a few minor issues:

#42 - now uses the makefile in the docker build, which means version info is correctly embedded at runtime - also now outputs version data at the top of the log when the container starts

Fixing a simple issue found by go vet. Need to do more work on fixing issues found in go vet.

* Forgot to run 'go fmt'

* Adding codecov for go now that a single test is written

* Testing not quite ready yet, removing from build

* Add Support For 2 Factor Authentication

Merging in feature from @ryskov (PR #24) adding 2FA support during LDAP binds. This is accomplished by concatenating the code to the end of the password. 

Also added integration tests for the TOTP method to run in CI. Could not, however, add automated tests for the yubikey, due the physical nature.

* Expose LDAPS ports in Docker container (#49)

Currently, the LDAPS ports are not exposed in the docker container.

* Adding better logging to docker start script

* Add more logging info to docker startup script

* Fix Arm32 Build (#52)

As discussed in issue #51, Arm32 builds were using 368 (intel/amd) arch accidentally, generating linux 32 bit binaries instead of arm 32 bit binaries. This commit fixes this in the Makefile, which will fix both the local builds, as well as the travis CI and release builds.

fixes #52

* Update docker hub image badge to a working one

previous one simply returned 0.

* Removing 3893 - fixes #50

* Fixing readme MD formatting

* Adding travis_retry to fix against intermittent network outages

* Add TLS options for running both with TLS and without on the same time (#27)

* Add TLS options for running both with TLS and without on the same time.

This commit expands on the settings available for using TLS. It puts TLS settings under the [frontend.tls] section and adds a new setting to [frontend] called TLSExclusive (bool).
TLSExclusive specifies whether or not to only run TLS when it is enabled, and is 'true' by default. Setting it to 'false' and having TLS enabled, causes the server to start both a LDAP and LDAPS server,
and therefore requires to seperate 'listen' options (to run on different ports) - the Frontend.Listen and the Frontend.TLS.Listen. If TLSExclusive is set to 'true' and no Frontend.TLS.Listen is specified, it will use the Frontend.Listen.

* Adding PR template and improving integration test tooling

* Updating formatting

* Add get dependencies step to makefile setup

* Add go 1.11

* Add App Password Support (#60)

App passwords can now be used to allow easier OTP use alongside applications which need to bind with a static password. Use the key `passappsha256` and specify an array of password hashes. See the readme and sample configuration file for more information.

Fixes #54

* Adding NCoC as official project code of conduct

We happily accept contributions based on the merit of the contributions.

* Properly handling paramaters in logs - fixes #64

* Adding ldapsearch for healthchecks
Latest commit 28802ff Dec 25, 2018

README.md

GLAuth: LDAP authentication server for developers

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

Travis Build - Master Last Commit

DockerHub Image Size

Maintainability Test Coverage

Donate via Paypal

  • 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 local file, S3 or proxy to existing LDAP servers.

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 PRs on dev, not master.

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.
    • sudo ./glauth64 -c sample-simple.cfg
  4. Test with traditional LDAP tools
    • For example: ldapsearch -LLL -H ldap://localhost:389 -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.

make all - run build binaries for platforms

make fast - run build for only linux 64 bit

make run - wrapper for the 'go run' command, setting up the needed tooling

make test - run the integration test on linux64 binary

Usage:

glauth: securely expose your LDAP for external auth

Usage:
  glauth [options] -c <file|s3url>
  glauth -h --help
  glauth --version

Options:
  -c, --config <file>       Config file.
  -K <aws_key_id>           AWS Key ID.
  -S <aws_secret_key>       AWS Secret Key.
  -r <aws_region>           AWS Region [default: us-east-1].
  -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"
  unixid = 5001
  primarygroup = 5501
  passsha256 = "6478579e37aff45f013e14eeb30b3cc56c72ccdc310123bcdf53e0333e3f416a"   # dogood
  sshkeys = [ "ssh-dss AAAAB3..." ]
[[groups]]
  name = "superheros"
  unixid = 5501

To create the password SHA hash, use this command: echo -n "mysecret" | openssl dgst -sha256 Instead of a local configuration file, GLAuth can fetch its configuration from S3. This is an easy way to ensure redundant GLAuth servers are always in-sync.

glauth -c s3://bucketname/glauth.cfg

In order to use S3, you must set your AWS credentials. Either:

  1. set the -K and -S command-line flags OR
  2. set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.

More configuration options are documented here: https://github.com/glauth/glauth/blob/master/sample-simple.cfg

Required Fields

  • Name
    • The user's username
  • ou
    • ID of the user's primary group
  • uidnumber
    • The user's unix user id
  • sshPublicKey
    • Specify an array of public keys

Optional Fields

  • otherGroups
    • Array of IDs of groups the user is a member of.
    • Example: [5501, 5002]
    • default = blank
  • givenname
    • First name
    • Example: John
    • default = blank
  • sn
    • Last name
    • Example: Doe
    • default = blank
  • disabled
    • Specify if account is active.
    • Set to 'true' (without quotes) to make the LDAP entry add 'AccountStatus = inactive'
    • default = false (active)
  • mail
  • loginshell
    • Specify a different login shell for the user
    • Example: /bin/sh, or /sbin/nologin
    • default = /bin/bash
  • homedirectory
    • Specify an overridden home directory for the user
    • Example: /home/itadmin
    • default = /home/[username]
  • otpsecret
    • Specify OTP secret used to validate OTP passcode
    • Example: 3hnvnk4ycv44glzigd6s25j4dougs3rk
    • default = blank
  • passappsha256
    • Specify an array of app passwords which can also succesfully bind - these bypass the OTP check. Hash the same way as password.
    • Example: ["c32255dbf6fd6b64883ec8801f793bccfa2a860f2b1ae1315cd95cdac1338efa","4939efa7c87095dacb5e7e8b8cfb3a660fa1f5edcc9108f6d7ec20ea4d6b3a88"]
    • default = blank
  • yubikey
    • Specify Yubikey ID for maching Yubikey OTP against the user
    • Example: cccjgjgkhcbb
    • default = blank

OpenSSH keys:

GLAuth can store a user's SSH authorized keys. Add one or more keys per user as shown above, then setup the goklp helper: https://github.com/appliedtrust/goklp

Two Factor Authentication

GLAuth can be configured to accept OTP tokens as appended to a users password. Support is added for both TOTP tokens (often known by it's most prominent implementation, "Google Authenticator") and Yubikey OTP tokens.

When using 2FA, append the 2FA code to the end of the password when authenticating. For example, if your password is "monkey" and your otp is "123456", enter "monkey123456" as your password.

TOTP Configuration

To enable TOTP authentication on a user, you can use a tool like this to generate a QR code (pick 'Timeout' and optionally let it generate a random secret for you), which can be scanned and used with the Google Authenticator app. To enable TOTP authentication, configure the otpsecret for the user with the TOTP secret.

App Passwords

Additionally, you can specify an array of password hashes using the passappsha256 for app passwords. These are not OTP validated, and are hashed in the same way as a password. This allows you to generate a long random string to be used in software which requires the ability to authenticate.

However, app passwords can be used without OTP as well.

Yubikey Configuration

For Yubikey OTP token authentication, first configure your Yubikey. After this, make sure to request a Client ID and Secret key pair.

Now configure the the yubikeyclientid and yubikeysecret fields in the general section in the configuration file.

To enable Yubikey OTP authentication for a user, you must specify their Yubikey ID on the users yubikey field. The Yubikey ID is the first 12 characters of the Yubikey OTP, as explained in the below chart.

Yubikey OTP

When a user has been configured with either one of the OTP options, the OTP authentication is required for the user. If both are configured, either one will work.

Backends:

For advanced users, GLAuth supports pluggable backends. Currently, it can use a local file, S3 or an existing LDAP infrastructure. In the future, we hope to have backends that support Mongo, SQL, and other datastores.

[backend]
  datastore = "ldap"
  servers = [ "ldaps://server1:636", "ldaps://server2:636" ]

Production:

Any of the architectures above will work for production. Just remember:

  • Always use legit SSL certs for production!

Other Architectures

A small note about other architectures: while I expect the code is, for the most part, system-independent, there is not a good (and free) CI system which can be easily used to continuously test releases on ARM, BSD, Linux-32bit, and Windows. As such, all of the non-linux-64bit packages are provided as is. The extent of testing on these packages consists solely of cross-compiling for these architectures from a linux 64 bit system.

We will accept PRs which fix bugs on these platforms, but be aware these binaries will not be tested regularly, and instead are provided for the convenience of those who feel comfortable with this.

Building:

You'll need go-bindata to build GLAuth. Then use the Makefile.

go get github.com/jteeuwen/go-bindata/...
make all

Stargazers over time

Stargazers over time

Support

Support the ongoing development of GLAuth!

Paypal

Donate via Paypal

Bitcoin Address

39z2Zkoc24LsuiqCQNFe7QrX4da3mzbGjK