Thumbnail image

LDAP Basics: What You Need to Know

The problem

You’re running several self-hosted services — Nextcloud, Gitea, Grafana, maybe more. Each one has its own list of users and passwords. New person joins? You create five accounts. Someone leaves? You hope you remember to delete them everywhere.

LDAP is a directory that holds all your users and groups in one place. Services ask it “does this person exist?” and “are they allowed in?” instead of keeping their own user lists.

lldap is a lightweight LDAP server designed exactly for this. No enterprise complexity — just users, groups, and a clean web UI.


The naming system

LDAP names look strange at first, but there’s a simple pattern behind them.

Your domain becomes the root

Take your domain name, split it at the dots, and prefix each part with dc=:

example.com      →  dc=example,dc=com
home.lab         →  dc=home,dc=lab
yak.consulting   →  dc=yak,dc=consulting

This is called the Base DN — the root of your directory tree.

Everything is a path

Every entry in LDAP has a full address called a Distinguished Name (DN). It reads from the most specific item on the left to the broadest on the right:

uid=slav, ou=people, dc=yak, dc=consulting
│         │          └── the domain
│         └── inside the "people" folder
└── the user called "slav"

It’s like a file path written backwards: instead of /yak.consulting/people/slav, you get uid=slav,ou=people,dc=yak,dc=consulting.

The common abbreviations

ShortMeaningThink of it as
dcDomain ComponentYour domain, split into pieces
ouOrganizational UnitA folder
uidUser IDA username
cnCommon NameA group name
dnDistinguished NameThe full path to anything

The tree

A typical lldap directory looks like this:

dc=yak,dc=consulting           ← root
├── ou=people                   ← all users go here
│   ├── uid=slav
│   └── uid=anna
└── ou=groups                   ← all groups go here
    ├── cn=nextcloud_users
    └── cn=gitea_users

lldap creates this structure automatically. You just set the Base DN and start adding users and groups through the web interface.


Groups control access

This is the key concept. You don’t give a user direct access to a service — you put them in a group, and the service checks group membership.

Want someone to access Nextcloud? Add them to nextcloud_users. Want to revoke access? Remove them from the group. Want to onboard someone to everything? Add them to all the relevant groups in one place.


How services connect

When you hook up a service to lldap, it needs a few things:

  • Where is LDAP? — the server address and port
  • What’s the root? — your Base DN
  • How do I log in to search? — a service account (called the Bind DN) that can look up users
  • How do I find users? — a search filter like “find a user matching this username”
  • Who’s allowed in? — a group filter like “only let in members of this group”

The service never sees passwords. It just asks lldap to verify them.


The mental model

If this is all you take away, you’re in good shape:

  • Base DN = your domain, LDAP-style → the root of the tree
  • Users live in ou=people under the root
  • Groups live in ou=groups under the root
  • Every entry has a full path (DN) built from its position in the tree
  • Access is controlled by which groups a user belongs to
  • Services connect to LDAP with a read-only account and check users against groups