
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
| Short | Meaning | Think of it as |
|---|---|---|
| dc | Domain Component | Your domain, split into pieces |
| ou | Organizational Unit | A folder |
| uid | User ID | A username |
| cn | Common Name | A group name |
| dn | Distinguished Name | The 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=peopleunder the root - Groups live in
ou=groupsunder 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