Repository files navigation

LDAP made easy.

• About
• Installation
• Usage
  • Recommended architecture
• Client configuration
  • Known compatible services
  • General configuration guide
  • Incompatible services
• Frequently Asked Questions
• Contributions

This project is a lightweight authentication server that provides anopinionated, simplified LDAP interface for authentication. It integrates withmany backends, from KeyCloak to Authelia to Nextcloud andmore!

It comes with a frontend that makes user management easy, and allows users toedit their own details or reset their password by email.

The goal isnot to provide a full LDAP server; if you're interested in that,check out OpenLDAP. This server is a user management system that is:

• simple to setup (no messing around withslapd),
• simple to manage (friendly web UI),
• low resources,
• opinionated with basic defaults so you don't have to understand thesubtleties of LDAP.

It mostly targets self-hosting servers, with open-source components likeNextcloud, Airsonic and so on that only support LDAP as a source of externalauthentication.

For more features (OAuth/OpenID support, reverse proxy, ...) you can installother components (KeyCloak, Authelia, ...) using this server as the source oftruth for users, via LDAP.

By default, the data is stored in SQLite, but you can swap the backend withMySQL/MariaDB or PostgreSQL.

It's possible to install lldap from OCI images (docker/podman), fromKubernetes, or froma regular distribution package manager (Archlinux, Debian, CentOS, Fedora, OpenSuse, Ubuntu, FreeBSD).

Buildingfrom source andcross-compiling to a different hardware architecture is also supported.

The simplest way to use LLDAP is through the web front-end. There you cancreate users, set passwords, add them to groups and so on. Users can alsoconnect to the web UI and change their information, or request a password resetlink (if you configured the SMTP client).

You can create and manage custom attributes through the Web UI, or through thecommunity-contributed CLI frontend (Zepmann/lldap-cli). This is necessaryfor some service integrations.

Thebootstrap.sh script can enforce a list ofusers/groups/attributes from a given file, reflecting it on the server.

To manage the user, group and membership lifecycle in an infrastructure-as-codescenario you can use the unofficialLLDAP terraform provider in the terraform registry.

LLDAP is also very scriptable, through its GraphQL API. See theScripting docs for more info.

If you are using containers, a sample architecture could look like this:

• A reverse proxy (e.g. nginx or Traefik)
• An authentication service (e.g. Authelia, Authentik or KeyCloak) connected toLLDAP to provide authentication for non-authenticated services, or to provideSSO with compatible ones.
• The LLDAP service, with the web port exposed to Traefik.
  • The LDAP port doesn't need to be exposed, since only the other containerswill access it.
  • You can also set up LDAPS if you want to expose the LDAP port to theinternet (not recommended) or for an extra layer of security in theinter-container communication (though it's very much optional).
  • The default LLDAP container starts up as root to fix up some files'permissions before downgrading the privilege to the given user. However,you can (should?) use the*-rootless version of the images to be able tostart directly as that user, once you got the permissions right. Just don'tforget to change from theUID/GID env vars to theuid docker-composefield.
• Any other service that needs to connect to LLDAP for authentication (e.g.NextCloud) can be added to a shared network with LLDAP. The finestgranularity is a network for each pair of LLDAP-service, but there are oftencoarser granularities that make sense (e.g. a network for the *arr stack andLLDAP).

Most services that can use LDAP as an authentication provider should work outof the box. For new services, it's possible that they require a bit of tweakingon LLDAP's side to make things work. In that case, just create an issue withthe relevant details (logs of the service, LLDAP logs withverbose=true inthe config).

Some specific clients have been tested to work and come with sampleconfiguration files, or guides. See theexample_configsfolder for example configs for integration with specific services.

Integration with Linux accounts is possible, through PAM and nslcd. SeePAMconfiguration guide. Integration with Windows (e.g. Samba) is WIP.

To configure the services that will talk to LLDAP, here are the values:

• The LDAP user DN is from the configuration. By default,cn=admin,ou=people,dc=example,dc=com.
• The LDAP password is from the configuration (same as to log in to the webUI).
• The users are all located inou=people, + the base DN, so by default userbob is atcn=bob,ou=people,dc=example,dc=com.
• Similarly, the groups are located inou=groups, so the groupfamilywill be atcn=family,ou=groups,dc=example,dc=com.

Testing group membership throughmemberOf is supported, so you can have afilter like:(memberOf=cn=admins,ou=groups,dc=example,dc=com).

The administrator group for LLDAP islldap_admin: anyone in this group hasadmin rights in the Web UI. Most LDAP integrations should instead use a user inthelldap_strict_readonly orlldap_password_manager group, to avoid granting fulladministration access to many services. To prevent privilege escalation users in thelldap_password_manager group are not allowed to change passwords of admins in thelldap_admin group.

Though we try to be maximally compatible, not every feature is supported; LLDAPis not a fully-featured LDAP server, intentionally so.

LDAP browsing tools are generally not supported, though they could be. If youneed to use one but it behaves weirdly, please file a bug.

Some services use features that are not implemented, or require specificattributes. You can try to create those attributes (see custom attributes intheUsage section).

Finally, some services require password hashes so they can validate themselvesthe user's password without contacting LLDAP. This is not and will not besupported, it's incompatible with our password hashing scheme (a zero-knowledgeproof). Furthermore, it's generally not recommended in terms of security, sinceit duplicates the places from which a password hash could leak.

In that category, the most prominent is Synology. It is, to date, the onlyservice that seems definitely incompatible with LLDAP.

• I can't login
• Discord Integration
• Migrating from SQLite
• How does lldap comparewith OpenLDAP?With FreeIPA?With Kanidm?
• Does lldap support vhosts?
• Does lldap provide commercial support contracts?
• Can I make a donation to fund development?
• Is lldap sustainable? Can we depend on it for our infrastructure?

Contributions are welcome! Just fork and open a PR. Or just file a bug.

We don't have a code of conduct, just be respectful and remember that it's justnormal people doing this for free on their free time.

Make sure that you runcargo fmt from the root before creating the PR. And ifyou change the GraphQL interface, you'll need to regenerate the schema byrunning./export_schema.sh.

Join ourDiscord server if you have anyquestions!