Show HN: Lldap, a Simplified LDAP Server (github.com)
Hi everyone! For the past year I've been working on a simple LDAP server for user management, targeted at self-hosted servers.
The idea is that OpenLDAP is a pain to install, configure and manage, and on top of that you need a frontend if you want a web UI.
LDAP instead provides a minimalistic LDAP server that supports the subset of LDAP needed for user management and authentication, with almost no configuration required, and a nice UI/API in front of it.
We just released version 0.4 (and 0.3 actually) and it should now be stable enough to use it yourself!
We've had some people using it for tests as well.
114 comments
[ 3.0 ms ] story [ 173 ms ] threadI wonder how terrible DAP may be if LDAP is "lightweight".
X.500 (and X.400) got a lot of pushback in the IETF crowd because of the use of ASN.1, while all IETF protocols of the era were still plaintext. It's been enormously clear from then till now that binary protocols are superior in terms of network efficiency, and everyone has tools like wireshark / etherpeek / whatever rendering the human readability of packets a moot point.
It's the same with OpenSSH, Apache httpd and and many more tools. Take OpenSSH as an example: it can do a lot of little-known things (SSH certificate authority, SOCKS proxy, port-forward, signing stuff and verifying signatures and so much more)... Yet like 99% of the people will just do "ssh somehost" and be done with that.
By comparison for one of my first emails I got a reply within 5 minutes from France. I'm in Australia.
I don't think the criticism against regular slapd being hard to configure is fair. It mostly runs out of the box. The tricky bit is LDAP itself, choosing a schema, and that query language which combines extremely long identifiers with line noise looking syntax.
While I agree about the query language, the only custom bits above required 2-3 ready baked queries we had to figure out once. If you need complex queries, I absolutely wouldn't use LDAP, but for that use that was not a consideration.
I feel like I need a PhD to configure openldap, while this was as out of the box as it gets.
Kudos to the devs!
By the way if anybody is interested, authentik comes with an embedded ldap server implementation. It's not perfect but it satisfies the same need. Authorization & authentication.
Authentik looks good though, it's in my queue of things to try.
But I found Authelia reasonably simple to use too.
It just doesn't make sense and I feel you pain.
One great resource I've found about LDAP (in general) is https://www.zytrax.com/books/ldap/ ("Ldap for rocket scientists"). I remeber spending a couple of week(end)s going through that, and things started to make sense.
However, again, there's no real reason for all this to be so complicated...
And postgres configuration is stored in Postgres, so "you need to know about postgres in order to start learning about postgres"...
this is a time-honored database tradition, relational metadata is often itself very relational data and you can often get a huge amount of code reuse by utilizing the same handling mechanisms for the data as the metadata.
[1] http://ldapjs.org/
"Currently only SQLite is supported (see launchbadge/sqlx#1225 for what blocks us from supporting more SQL backends)."
although presumably it would be better to query the graphql API.
However, mapping the tables/field names is not planned. I think it's a can of worms that I don't want to open: How do you populate the fields you don't know about but are mandatory when creating a new user/group?
You could go the way of setting up a middleman service that listens to the binary queries to (e.g.) postgres and "tranlates" them by substituting the field names, but that seems complicated.
So perhaps if it can read from a view with a schema defined by you, that would work? And perhaps for inserting/updating user/groups, you could require the database have a specific stored procedure present?
Initially I was thinking about allowing templated queries, where the administrator can specify the field names. For inserts, the database will just have to provide sensible defaults or let the insert go through a stored procedure that provides such. But doing everything using views & stored procedures might be simpler?
A read-only view would be possible, the schema is quite simple. If you want, you could create an issue for that! Keep in mind that the DB schema is more of an implementation detail than a public API, so I'm not going to consider an (automatically-migrated) schema change as a breaking change.
[1] https://lists.openldap.org/hyperkitty/list/openldap-technica...
Once upon a time Netscape/Mozilla browser shipped with LDAP module callable from javascript. There really wasn't any need to build a separate LDAP frontend. Nowadays Mozilla/Firefox has stripped out pretty much everything that made Netscape useful. So it goes.
People talking about OpenLDAP complexity - that's mostly BS. Complexity of the config is driven by complexity of the demands placed on the installation. If all you want is to store passwords for a handful of users, the config can be done in 10 lines of text.
re: storing config in an LDAP database - no you don't need to know OpenLDAP to be able to manage it. You need to know LDAP - and you need to know that anyway to use it, and your knowledge of LDAP is transferable to any LDAP-based system, not just OpenLDAP. But yes, you have to know the basics of LDAP. That's an unavoidable requirement of working with any LDAP software.
It's a bit daft to write your own LDAP server implementation if your complaint is that there's no modern GUI UI. LDAP is a standard protocol - if you want a shiny new UI, write the shiny new UI. And when you're done you can use it with any LDAP server in existence, assuming you did your job right and followed standards.
Meanwhile, the actual OpenLDAP software has been tuned and battle-tested, it is by far the world's most efficient and most reliable data store.
Eventually, what drove me to create this is that it's targeted at small self-hosted servers that just need <20 users and _don't want to learn LDAP_. People who either don't have the background necessary to learn LDAP or don't have the time to dig into it. That's why an important part of the repository is the list of example configs for many services that provide good defaults for easily setting up the connection with LLDAP. The server admins don't actually need to know LDAP to use LLDAP.
An additional benefit is that the resulting image is small and the software is fast, because it does way less than OpenLDAP. And the API/SQL DB makes it more easy to integrate with scripts or applications that manipulate users directly.
Since you built on top of SQLite, then you're already at least an order of magnitude slower. You could speed it up a bit by using SQLightning, which replaces SQLite's Btree engine with OpenLDAP's.
https://github.com/LMDB/sqlightning
But yes, it's obvious your aim is to provide bare minimum LDAP functionality for people who were only taught SQL and have no desire to learn LDAP. A bit of a loss, because the workloads LDAP is used for most often are things RDBMSs suck at.
I'm what format is data stored? How resilient is the stored data against corruption?
I'm planning on supporting alternate DBs as well.
I don't love this state of affairs as I'd rather just use my password manager for everything (and it's particularly bad when you have a mix of on-prem stuff that does AD and then other cloud stuff that doesn't), but I suppose it probably works well for shops that use exclusively cloud services.
That’s fine when you’re a sole developer or a small team but the moment your organisation grows you need SSO.
> and it's particularly bad when you have a mix of on-prem stuff that does AD and then other cloud stuff that doesn't),
Most cloud services do support AD (eg via SAML) but hide that option behind an enterprise subscription.
And since you have to have AD/Azure AD for Windows logins if you want single-password (not necessarily SSO) your source of truth is now an LDAP server.
Currently I'm trying to learn to be more productive with LDIF honestly is much simpler than I thought. It's a great way to do bulk changes and handy in scripts, but it's not a sensible way to do everyday interactions. Right now there aren't many good tools, Apache Directory Studio is rather nice, but feels old fashion and not the kind of tool you'd want people to interact with on a daily basis... Unless they understand a bit about how LDAP works.
It really nice to see a new LDAP project, especially one that more focus on making the protocol more accessible.
For those who need something simple there's also the OpenBSD LDAP daemon, which also works pretty well.
I've played with OpenLDAP and 389ds.
OpenLDAP is dumb in the sense that its own configuration is stored in OpenLDAP itself, so you need to know openldap to start learning openldap. And its community is quite toxic (i've seen people in their irc channel mocking users asking questions and giving out replies like "it's not in the official docs but it's in the codebase, you should have read the source code").
389ds... is barely documented. The official documentation often points to the proprietary counterpart from RedHat, but it's not clear what the open version corresponds to which proprietary version.
This is really a niche that could use some disrupting imho...
FYI, RHDS 12.0 is based on 389-ds 2.0.14 [0]
RHDS 11.5 is based on 389-ds 1.4.3.28 [1]
RHDS 11.4 is based on 389-ds 1.4.3.27 [2] (the release notes can be consulted for 11.3 and earlier too).
RHDS 10.x is based on 389-ds 1.3.x [3]
And yes I agree it's far too difficult to find this stuff out!
[0] https://access.redhat.com/documentation/en-us/red_hat_direct...
[1] https://access.redhat.com/documentation/en-us/red_hat_direct...
[2] https://access.redhat.com/documentation/en-us/red_hat_direct...
[3] https://directory.fedoraproject.org/docs/389ds/FAQ/roadmap.h...
The web UI uses the OPAQUE protocol to log in/store passwords, so your password is never sent to the server (it instead stores just enough information for you to provide a cryptographic zero-knowledge proof that you have the correct password). It's a bit undermined by the fact that LDAP binds use plaintext passwords, but I thought it would be cool to implement :)
* https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque
I’ll have to have a look at OPAQUE, which according to Wikipedia is a newer alternative to SRP.
Edit: Just noticed that there are quite a few more systems using these types of algorithms, including Apple HomeKit.
The only features I need in LDAP
* One-way (master->RO) Replication
* Standards compliance for queries/binds
* Easy authentication for setup/administration
* Add additional schemas (For instance, the SSH Key schema)
OpenLDAP definitely makes all the above quite difficult, but it's doable.
One esoteric feature we use of OpenLDAP is SASL delegation. This allows us to defer some users to Active Directory. Nice party trick.
SASL is a no-go, I don't plan on supporting it, it looks awfully complex.
In this space there's also Univention (based on OpenLDAP+Samba), which bootstraps the whole configuration from e.g. domain setup to joins to other server instances. Manageable through a web interface as well. UCS aims to be compatible with Active Directory™ - so it still comes with all the legacy complexity of OpenLDAP and more.
If compatibility with external integrations or preexisting AD domains is a must-have, it's an alternative.
PS: I'm glad we no longer need to state in the title of a Show HN post "written in rust".
I think it's great, and as far as I understand, it blocks companies from offering it in a way that doesn't bring anything of value to the community.
I say "fraught" because it imposes conditions on running this on the network. Perhaps fraught is too editorial. Regardless - in some environments, that "stickiness" of the GPL is a non-starter. One may say that "weeding out" those envs is part of the point. In my opinion though, for things like libraries or "lower level" software there seems to be a school of thought where "getting it out there" is more important than "saving it" from modifications.
I tend to think of GPL[2/3] as for end-user applications, like openoffice or ardour[0] (paging 'PaulDavisThe1st) and libraries and network services as mit/bsd/isc/lgpl so they can interact with Other Software without forcing anything on that Other Software.
I hesitated even posting my original comment, but don't mind getting a potentially new read on others devs point of view on this area.
Briefly, on "block[ing] companies ... that [don't] bring anything of value...", you also block orgs that would bring value, but might not want to be legislated to publish everything.
[0] https://ardour.org/