lldap: Light LDAP Implementation

by thunderbong • 2 years ago

136 35 2 years ago

will0• 2 years ago

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.

ivanjermakov• 2 years ago

Ironically, there is not much "lightweight" in LDAP

anyfoo• 2 years ago

You should have seen X.500.

yencabulator• 2 years ago

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.

Attummm• 2 years ago

Ah LLDAP (Light Lightweight Directory Access Protocol)

danielfrg• 2 years ago

I use it for my home lab. Highly recommend

NewJazz2• 2 years ago

Does it do replication?

Spivak• 2 years ago

No but also yes. lldap uses an rdbms as its backing data store so replicate the databases and point lldap at each one.

PeterWhittaker• 2 years ago

Hmm, shouldn’t it be lSLAPD or LDSA? After all, it is an LDAP server, not lighter weight protocol!

tetrisgm• 2 years ago

Not to be confused with LDAC, the audio codec (which is what I thought of when I clicked).

bityard2• 2 years ago

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.

infogulch• 2 years ago

I've been wanting to build a stack like this. Mind sharing a few details about how you set it up?

bityard2• 2 years ago

Sure, here ya go: https://github.com/cu/silicon/tree/master/deploy/caddy-authe...

oriettaxx• 2 years ago

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

SoftTalker• 2 years ago

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.

commandersaki• 2 years ago

In my teens I was obsessed with LDAP and shared authentication across a fleet of Linux machines, it sounded pretty cool. In reality I never actually had to administer or setup LDAP. It was popularised by Microsoft with advent of Active Directory in the 00s (I believe AD came out with Windows 2000 Server).

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.

kjellsbells2• 2 years ago

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.

newman314• 2 years ago

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...

packetlost• 2 years ago

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.

1over137• 2 years ago

Why do so many seem to think everything should be on top of http? DNS, LDAP, where does it stop?

ksk23• 2 years ago

I like it very much. Fullfills all your SOHO SSO needs!

generalizations• 2 years ago

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.

daelon• 2 years ago

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.

t312227• 2 years ago

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€

NewJazz2• 2 years ago

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.

atoav• 2 years ago

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.

justsomehnguy• 2 years ago

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.

azophy_2• 2 years ago

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?

patmorgan23• 2 years ago

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.

lldap: Light LDAP Implementation

Related Stories