lldap: Light LDAP Implementation(github.com)
github.com
lldap: Light LDAP Implementation
https://github.com/lldap/lldap
35 comments
LDAP came from the University of Michigan where it was intended to be a "lightweight" alternate of X.500
https://en.wikipedia.org/wiki/Lightweight_Directory_Access_P...
https://en.wikipedia.org/wiki/Lightweight_Directory_Access_P...
Why do so many seem to think everything should be on top of http? DNS, LDAP, where does it stop?
> Nowadays I'm think we're better served with a SQL queryable RDBMS to store directory-like data
Maybe, but most RDBMS' suck a recursive self-referential queries, which mandatory for making a directory system not suck to use.
> modernising the query language using JSON over a HTTP(S) transport
Eh. Modernizing the query language would be nice, but there's a reason most databases don't make HTTP + JSON the primary method by which you interface. Some LDAP systems get absolutely hammered, you don't want a bunch of unnecessary overhead and connection-building to add to it when you really don't need to. Also expressing queries sanely in JSON would be a pain, you'd either just be wrapping a plaintext query in an object or doing something incredibly misguided with trying to represent the query structure as a bad AST using JSON types.
Maybe, but most RDBMS' suck a recursive self-referential queries, which mandatory for making a directory system not suck to use.
> modernising the query language using JSON over a HTTP(S) transport
Eh. Modernizing the query language would be nice, but there's a reason most databases don't make HTTP + JSON the primary method by which you interface. Some LDAP systems get absolutely hammered, you don't want a bunch of unnecessary overhead and connection-building to add to it when you really don't need to. Also expressing queries sanely in JSON would be a pain, you'd either just be wrapping a plaintext query in an object or doing something incredibly misguided with trying to represent the query structure as a bad AST using JSON types.
> queryable RDBMS to store directory-like data, and modernising the query language using JSON over a HTTP(S) transport.
Isnt this what identity systems like Azure Entra essentially are? I remember that they were always at pains to point out that Azure Active Directory was not Active Directory and didnt do LDAP.
Isnt this what identity systems like Azure Entra essentially are? I remember that they were always at pains to point out that Azure Active Directory was not Active Directory and didnt do LDAP.
I've been using this for the past few years. LLDAP + Authelia + Caddy is a great way to completely avoid writing your own (likely bad) authentication system. Layers are great.
my next task is traefik + authelia + ldap, and I will definitively try this lldap (openldap is really old style... )
I'll do it in Docker Swarm: if anybody have suggestions or want to work on it together pls let me know
I'll do it in Docker Swarm: if anybody have suggestions or want to work on it together pls let me know
I've been wanting to build a stack like this. Mind sharing a few details about how you set it up?
Sure, here ya go: https://github.com/cu/silicon/tree/master/deploy/caddy-authe...
OpenBSD also includes ldapd, a daemon which implements version 3 of the LDAP protocol. It's simpler than OpenLDAP, at least since OpenLDAP started storing its configuration within itself.
I don't think there's a portable version though.
I don't think there's a portable version though.
Ah LLDAP
(Light Lightweight Directory Access Protocol)
hello,
as always ... imho (!)
disclaimer: i'm a big fan of ldap, especially of the FOSS openldap implementation and i'm using it since ... ever ... (~ 25 years)
i think there is one feature which makes openldap stand out and which in my experience is crucial for any non-trivial directory-implementation someone wants to use:
* easy replication-setups with the possibility to create complex (!) topologies.
what i mean with that is maybe best described by the following "anecdote":
once upon a time i had the use-case of the migration of some mid-sized HPC-clusters - distributed memory - from "good old" NIS to LDAP.
ok ... sounds simple: pam-ldap and be done with it!!
sure, but what happens, if the LDAP main server fails!?
no problem, replicate to a second system as a "fail over" eg. HA ...
sure, but what happens if the network between the HPC-cluster and the LDAP server(s) fails!?
just replicate the directory "read only" to the head-nodes ...
sure, but what happens if the network "in cluster" fails!?
just replicate it to each node ...
now draw out the resulting topology ;))
why? because i wanted to keep the cluster(nodes) utilized even if the "worst case" happens.
last but not least: "openldap is a monster" ... sure, but define monster ... in my experience once you "groked" ldap and delved into the somewhat complex setup of openldap it "just works(tm)" ...
but: great project ... :+1: ... and its written in rust ... yawns ... ;)
just my 0.02€
as always ... imho (!)
disclaimer: i'm a big fan of ldap, especially of the FOSS openldap implementation and i'm using it since ... ever ... (~ 25 years)
i think there is one feature which makes openldap stand out and which in my experience is crucial for any non-trivial directory-implementation someone wants to use:
* easy replication-setups with the possibility to create complex (!) topologies.
what i mean with that is maybe best described by the following "anecdote":
once upon a time i had the use-case of the migration of some mid-sized HPC-clusters - distributed memory - from "good old" NIS to LDAP.
ok ... sounds simple: pam-ldap and be done with it!!
sure, but what happens, if the LDAP main server fails!?
no problem, replicate to a second system as a "fail over" eg. HA ...
sure, but what happens if the network between the HPC-cluster and the LDAP server(s) fails!?
just replicate the directory "read only" to the head-nodes ...
sure, but what happens if the network "in cluster" fails!?
just replicate it to each node ...
now draw out the resulting topology ;))
why? because i wanted to keep the cluster(nodes) utilized even if the "worst case" happens.
last but not least: "openldap is a monster" ... sure, but define monster ... in my experience once you "groked" ldap and delved into the somewhat complex setup of openldap it "just works(tm)" ...
but: great project ... :+1: ... and its written in rust ... yawns ... ;)
just my 0.02€
As a relatively young person I think openLDAP is ultimately not that hard to use, it just feels very foreign to the modern user.
And that has mostly to do with a lack of good documentation and syntax/system choices that have been made in times where some best practises might not have existed yet.
I must say googling any LDAP issue sucked majorly. But once you get the basic hang of how to do X it is somewhat consistent.
And that has mostly to do with a lack of good documentation and syntax/system choices that have been made in times where some best practises might not have existed yet.
I must say googling any LDAP issue sucked majorly. But once you get the basic hang of how to do X it is somewhat consistent.
> sure, but what happens if the network between the HPC-cluster and the LDAP server(s) fails!?
Call a network engineer.
For anything else use the multi-master replication, like the one built-in in ADDC.
Call a network engineer.
For anything else use the multi-master replication, like the one built-in in ADDC.
Seconded. Certainly cool to see people working with important protos like LDAP in new ways. For me replication is part of security and resiliency design. Read only replicas act as a buffer that keeps core infrastructure shielded from malicious or poorly configured clients.
Funny that the L in ldap stands for lightweight, and yet clearly there is interest in a lightweight version of what has become a somewhat bloated protocol.
Ironically, there is not much "lightweight" in LDAP
It was simple enough that back in 2002, I could implement a whole client+server LDAP protocol framework from scratch in ~11k lines of Python. That's not horrible.
ASN.1 gets a lot of (imho deserved) crap but it's roughly just a bunch of nested TLV (type, length, value) messages, just smeared with a bunch of legacy and a weird definition language. It's not all that different from e.g. Protocol Buffers. Outside of figuring out what context you're in and thus what message type an integer refers to, there's not much that would be "a hard problem" about it.
ASN.1 gets a lot of (imho deserved) crap but it's roughly just a bunch of nested TLV (type, length, value) messages, just smeared with a bunch of legacy and a weird definition language. It's not all that different from e.g. Protocol Buffers. Outside of figuring out what context you're in and thus what message type an integer refers to, there's not much that would be "a hard problem" about it.
You should have seen X.500.
Did X.500 ever get even close to fully implemented?
Rumour has it that that was logically impossible.
Culturally impossible as well, in the sense thar x.500 expected that every country's national telecom operator would take on the task of handling identity and certs for the population of that country.
That said, the US DoD had a pretty good stab at it, and even today in corners of the defense industrial base you can find companies like Isode that still service that niche. To be fair, x.400 messaging and x.500 directory looked pretty smart back in the day when smtp and passwd were the alternatives. It's just that smtp grew up incredibly fast and quickly outstripped the alternative.
That said, the US DoD had a pretty good stab at it, and even today in corners of the defense industrial base you can find companies like Isode that still service that niche. To be fair, x.400 messaging and x.500 directory looked pretty smart back in the day when smtp and passwd were the alternatives. It's just that smtp grew up incredibly fast and quickly outstripped the alternative.
I got my start in that era and they only looked smart if you didn't look deeply. Too many options, too many areas where they created a problem and then passed it off to someone else to fix.
I'm curious about other's experience with LDAP's supposed succesor: SCIM (http://scim.cloud). based on REST, it does sound simpler to implement & integrate compared to LDAP. but is it actually better compared to LDAP?
SCIM + Oath/SAML is pretty solid (SCIM doesn't handle authentication just provisioning, de-provisioning, and updates).
It flips the script on LDAP as well, instead of the application calling in to the directory, the directory/sync service calls into the application which has some positive security implications.
It flips the script on LDAP as well, instead of the application calling in to the directory, the directory/sync service calls into the application which has some positive security implications.
I've often thought that a large fraction of what LDAP does could be replaced by a /etc/passwd.d/ directory, with individual files for user accounts. Then the accounts could be synced without issue or race conditions. And it'd be much simpler to work with than that bloated protocol.
I've been getting into my homelab with proxmox recently, and that sounds like exactly what I wish I could do. I tried setting up an ldap server but it was way too complicated for my use case.
I use it for my home lab. Highly recommend
Does it do replication?
No but also yes. lldap uses an rdbms as its backing data store so replicate the databases and point lldap at each one.
We had a forest of openldap trees in 2002. Openldap had a replication integrated. Slapd (its more than 20 years ago forgive me if I get things wrong).
You could use a counter or timestamps to resolf conflicts.
How do you solve conflicts?
My bad slapd is the openldap daemon.
Hmm, shouldn’t it be lSLAPD or LDSA? After all, it is an LDAP server, not lighter weight protocol!
I like it very much.
Fullfills all your SOHO SSO needs!
Not to be confused with LDAC, the audio codec (which is what I thought of when I clicked).
Those days I didn't really understand the notion of a tree-like directory. Nowadays I'm think we're better served with a SQL queryable RDBMS to store directory-like data, and modernising the query language using JSON over a HTTP(S) transport.