Show HN: Lldap, a Simplified LDAP Server | Hacker News Reader

Show HN: Lldap, a Simplified LDAP Server

github.com

229 pointsnitnelave111 comments

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.

Open articleView on HN

LDAP really needs more love. Almost everything can be integrated with LDAP in some form, yet managing the server and configuration is always a bit tricky.

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.

Isn't integrating everything with LDAP how we got log4j though

No. We got that because someone thought it was smart to allow a low level library haul off and make network connections behind the caller's back, then someone else thought it was smart to execute code fetched from random network hosts.

I have the same experience! On the integration side of things, ldap is often easy to configure. Most software just works, when you know your parameters. The server side, however is a whole different story. It feels like most enterprisey implementations are ancient, even though they have active development going on.

Something cool that I didn't highlight since it's not the main point:

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 :)

Yeah the plaintext password thing sucks but you can mitigate that with LDAPS so it talks over a secure socket. The other choice you have is to use Kerberos to do the authentication. Also, thanks for the tip about OPAQUE. Going to go check it out.

An updated draft was just released last week:

* https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque

I’ve used SRP on a few projects, including for a large bank for the log in from their counter system. Once you get the algorithm sorted out it’s quite simple and it feels a whole lot better than some of the password storage systems I have seen (and still do see) implemented.

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.

You could use an LDAP SASL Bind instead, using any of a variety of strong authentication mechanisms then without plaintext passwords.

Another project with similar goals, glauth: https://github.com/glauth/glauth. it's written in Go and has a declarative config--you can define users and groups in yaml. Makes it really easy to do HA and manage your LDAP estate using Ansible.

I was looking for an LDAP server and this looks promising. Thanks for sharing!

It's trivial to reload openldap data from ldif, so you can already manage LDAP via Ansible easily enough.

As a low write, high read database that use case makes sense. Everything can stay in git. LDIF is not a nice format to operate for humans, but it's not much worse than json.

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.

Yeah, we never operated directly on the LDIF anyway. We had an ansible config that created, so we added a new server and it'd go in LDAP, and LDAP would feed the internal DNS and our (pre-Kubernetes) orchestration system.

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.

This sounds like a wonderful system. It's sad that Kubernetes is to tech like Facebook was to web forums. It killed all crafted and tailored systems in favor of a big bowl of badly written integration spaghetti. (And I'm allowed to say that because I do such things for money.)

I've used glauth, and it's great. Would love a comparison between them since glauth seems to be the main "competitor" to lldap.

I like the irony. LLDAP: lightweight lightweight directory access protocol

I wonder how terrible DAP may be if LDAP is "lightweight".

"X.500 is too complex to support on desktops and over the Internet, so LDAP was created to provide this service 'for the rest of us'" - https://en.wikipedia.org/wiki/X.500 (aka. DAP)

The idea was mostly that X.500 was too complex because it also dealt with user authentication and updating the directory data. During the initial development the ability to update dircetory data was then added back and then LDAPv3 allowed for non-password authentication using mechanism that is at least twice as complex as what was in original X.500.

Not exactly. X.500, like all the ISO networking standards had two significant problems : 1. It was defined to operate over transport layers that nobody used. 2. Its standards documents had to be purchased from the ITU, so approximately nobody had access to them and approximately nobody could participate in discussions. LDAP provided a vehicle to tunnel X.500 into the IETF standards process, and onto TCP/IP networks. In the process various things were simplified, but the raisons d'être were those two things.

1) was rectified pretty easily, there were X.500 implementations on top of TCP/IP. 2) was definitely annoying. They seem to have loosened restrictions on access to the specs these days.

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.

I understand the case for the irony, but it's one of those situation where a tecnology can do say 1000 different things but 99% of the people only need like 5-10 of them.

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.

One “lightweight” applies to the protocol, the other to the server software. Arguably it should be named L(LDAP)S. :)

  > size slapd
     text    data     bss     dec     hex filename
  2787425   78888  570048 3436361  346f49 slapd



      PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                          
     2826 hyc       20   0 8442040   1.8g 222972 S  17.5   3.1 744:17.91 gnome-shell                                      
  1122733 hyc       20   0 5834092   2.1g 211008 S  12.3   3.5   1184:04 seamonkey                                        
     2603 hyc       20   0 3072140  32480  24128 S  11.6   0.1   2597:09 pulseaudio                                       
  1124256 hyc       20   0 3026040 391680 107860 S   9.6   0.6 638:12.95 Isolated Web Co                                  
  1123672 hyc       20   0   13.2g 697540 318016 S   9.3   1.1 611:31.12 firefox

Still pretty lightweight, seems to me. As for pain to manage, that hasn't really been true since the introduction of LMDB in 2011. BerkeleyDB was a pain to manage, before that, but nowadays It Just Runs.

I remember a story of a X400/X500 based email system taking two hours to deliver mail within a single machine -- around 1990 or perhaps a little earlier.

By comparison for one of my first emails I got a reply within 5 minutes from France. I'm in Australia.

I have been using lldap for a while (paired with Authelia), and it is a real godsend.

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!

I am pretty sure openldap is easier to configure than Authelia.

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.

I configured Authelia in about 5 minutes, using glauth for LDAP.

Authentik looks good though, it's in my queue of things to try.

I don't use everything authentik supports but it's really good software and has a very responsive developer. Its feature list is already very impressive. When I looked at the comparison table on their website (later verified them myself) I was surprised at the things the more popular alternatives do not support.

Well the comparison here is between openldap and lldap. I would use either as a backend for Authelia.

But I found Authelia reasonably simple to use too.

I have a PhD and can't configure openldap

As I complained in another comment... OpenLDAP configuration is stored in OpenLDAP itself, so you need to know about OpenLDAP in order to start learning about OpenLDAP.

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

> OpenLDAP configuration is stored in OpenLDAP itself, so you need to know about OpenLDAP in order to start learning about OpenLDAP.

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.

I tried several times to use LDAP, only to fail each time. Except for 1 user. Then I had to figure out how to stop using LDAP and put his stuff in the regular authentication system.

FWIW, I have another entry in the same genre: https://github.com/majewsky/portunus - Seems like there really is a lot of pain with LDAP to go around.

Note that Portunus still uses OpenLDAP, it's just "OpenLDAP server is completely managed by Portunus". lldap doesn't use OpenLDAP at all.

Correct. I was going to implement LDAP myself, like lldap does, but after realizing that the "L" in LDAP is a lie, I went with a battle-tested implementation instead.

Seems smart. All too often one wants to start out simple, but later realizes there's this little feature that's missing. This seems to provide perfect backwards compatibility.

This is very interesting. I have build a lot of services that authenticate against LDAP or request user attributes (99% domain controllers in Microsoft land) and I believe this can be a very solid basis for user management for anything outside that plantation. Will certainly keep an eye on this.

Any thought about supporting SQL databases for the user backend with configurable queries? Would be awesome to be able to take an existing SQL database of users and use that to serve LDAP authentication queries.

This would be really cool! At my last job I implemented this for a simple use-case (allowing PfSense captive portal logins with credentials from a different system). It wasn't too hard thanks to ldapjs[1], but it still felt a bit hacky. Having a well-tested implementation with a couple of options could replace a lot of these special-case implementations.

[1] http://ldapjs.org/

According to the docs, it uses sqlite as the backend:

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

Right, I want to hook this up to my existing postgres/mysql database with existing schema.

We're going to add support for more DBs (e.g. Postgres and MySql) in the next release, I did a lot of work on the underlying libraries to make that possible.

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.

First of all, read only functionality would be good enough for me. Especially if it can read from a database view which could be backed by my other tables. I often deal with user databases managed by custom software which we also want to let be consumed by something that speaks ldap, and it would be great not having to synchronize stuff, instead having a single source of truth.

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?

I'm not a DB expert so I don't know much about stored procedures. Given that I'm trying to stay compatible with all of sqlite/mysql/postgresql, it might be difficult to rely on stored procedures horizontally.

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.

OpenLDAP back-sql allows you to map anything you can query with ODBC to ldap

The problem is that back-sql is unmaintained (e.g., see [1]) and only security bugs are addressed.

[1] https://lists.openldap.org/hyperkitty/list/openldap-technica...

How does it compare to 389 Directory Server? I've been using that with SSSD for user management and authentication in a small LAN with about twenty machines for about ten years. It is rock solid, but every few years when I do an major OS upgrade I have to get deep into the weeds and it always takes me a few days to become familiar with all the backend stuff again. I'm not using Kerberos or single sign on or anything fancy.

389 is afaik full-featured enterprise LDAP server, so I guess the main difference is complexity. One thing to note is that there is also FreeIPA companion project for 389, which a bundles in kerberos, sssd etc that are needed for full auth set-up

What do all of the people who want to work with *nix in their infrastructure, but also want to utilize AD and LDAP use?

OpenLDAP? FreeIPA? 389 Server? ApacheDS? The project in this post? Or something else?

I mean, is it even viable to use something like that for most general purpose use cases, as opposed to caving in and going with something running on MS software/cloud platforms?

Which is the easiest to get started with and administer? Personally, I've used OpenLDAP in containers for a bit and overall the experience was pretty good. That said, I'm yet to see something as nice as Keycloak for managing a directory service (just something that you can setup in 15 minutes, that has a nice web UI and that has a wide variety of functionality).

I've used FreeIPA with great success in the past. It really took care of the client onboarding and replication and hid all the ugly complexity behind it. UI was also pretty dang good.

If you want to utilize AD you don't have an alternative to run Samba, IIRC it's the only AD alternative that actually supports Windows clients.

For anything else, OpenLDAP in Docker.

> For anything else, OpenLDAP in Docker.

What about managing this instance and its configuration, as by default OpenLDAP doesn't really come with an easy to use set of tools/UI?

Would you use something like Apache Directory Studio (https://directory.apache.org/studio/) or CLI utilities?

It feels to me that OpenLDAP is probably more proven than lldap, but lldap seems to have a nice interface to use, much like Keycloak and some other turn-key solutions out there do (just a nice example to use from a slightly different domain).

Any form of LDAP management that is not Microsoft is an utter pain, and even Microsoft's is. It seems like the entire space has been stuck somewhere in the late 90s - horrible, outdated UIs and a bunch of dead projects that either don't run at all or are a walking bunch of security issues.

Personally, I use Apache Directory Studio because it's the least painful.

> IIRC it's the only AD alternative that actually supports Windows clients.

We only have 3 Windows clients amongst about 100 Linux VM's so we actually went the reverse path, OpenLDAP for Linux clients/servers and using pGina on the Windows boxes to connect it to OpenLDAP. Works pretty smoothly.

I had looked at FreeIPA, but support for non-Redhat systems seemed poor.

Samba is the way to go for AD on Linux, in my opinion. You'll likely want to run Samba (smbd and winbind) on the Linux clients as well.

AFAIK (from messing with getting Linux to authenticate against a university AD system a few years ago) the best-supported way of replicating AD in Linux is FreeIPA on RHEL, since everybody less corporate is probably going to use a less corporate protocol

But Windows Server is IMO Microsoft's killer product. It's very good at what it does, although using it with Linux clients you'll be missing out on large parts of its functionality like GPOs, WSUS, etc

> work with nix in their infrastructure, but also want to utilize AD and LDAP

If you have AD, just tell the nix machines to use it for user authentication? You don't need another server

> What do all of the people who want to work with *nix in their infrastructure, but also want to utilize AD and LDAP use?

FreeIPA. A trust between the FreeIPA domain and AD means that AD users can log into Unix systems, it's great.

This looks really cool and should help me out when integration testing things are require an LDAP connection. For example setting up the Jenkins ldap connector in an automated test.

PS: I'm glad we no longer need to state in the title of a Show HN post "written in rust".

I just went through the pain of setting up FreeIPA and I wish I saw this first. It's not that FreeIPA was difficult to setup it's that it's immensely complex with lots of parts and little documentation. Ultimately, all I really wanted was the LDAP part for a basic directory service and authentication. Definitely going to be taking a closer look at this, thank you for sharing!

Interesting. Maybe we will use this as a lightweight mock of our ldap server for integratie tests. Or glauth mentioned by candiddevmike.

Nice!!!! Definitely giving this a whirl!

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.

Glad you like it :) It seems LLDAP is a bit more lightweight than you expect, though: - You could easily implement one-way replication on top, it's just an SQlite database, you can easily copy it around (or rather use the built-in `.backup`). - I'm not sure what you mean by standards compliance, but I've tried to stick to the RFCs for the small subset of LDAP that is implemented. - The setup and admin is one of the strong points of LLDAP, it's very simple :) - Additional schemas are currently not supported. We have some plans, but they're kinda longterm and definitely not any time soon. It also will probably be loosely-typed, essentially just allowing you to store arbitrary key-value pairs.

SASL is a no-go, I don't plan on supporting it, it looks awfully complex.

Agree about SASL. We could actually live without SASL, and I wouldn't recommend attempting to implement it. We use it because it's there, it's supported, and we've figured out the reproducible steps to set it up. It's not pretty and I can't believe it actually works. The codebase for it must be intense.

I just don't understand why LDAP software has to generally be so unnecessarily complicated. I'm not talking about the protocol or the domain knowledge, i'm talking about implementations.

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

I agree OpenLDAP is not for the casual users. However, storing config in the LDAP itself is a strength; almost everything can be reconfigured at the run time, using the standard LDAP tool.

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

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

I did this for a project at my old company. We were using ApacheDS as a LDAP server, but we were doing a lot of updating to the datastore, and DS kept having issues with corruption.

But our use case was really limited, so I wrote a server process that talked LDAP, but it was essentially hard coded to support the 4 or 5 queries that we actually did. Then it was backed by our core Postgres backend.

The ASN parser was the trick of it to be sure. For whatever reason, I had a lingering bug in it that I could never track down. Some kind of heisenbug that I was never able to duplicate, and even spamming the logs with tons of debug info, I could never get a handle on it. It wasn't fatal, but it was annoying. Been so long, I don't recall the details.

ASN is tricky, but it's not that hard.

But, in the end, it worked for our use case.

Does anyone know of any nice CLI/TUI ldap browsing tools?

ldapsearch is horrible to use for browsing. Apache Directory Studio is a giant Java application with an overcomplex UI, and falls over as soon as you want to use Kerberos (at least, if you want to re-use the TGT that the user got when they logged in, instead of providing their credentials directly to Apache DS so that it can get its own TGT via JGSS or whatever).

I know of shelldap, which is OK. But what I'd really like is a sort of Finder like UI where the path of entries is represented by columns, and the attributes of the currently selected entry are displayed in the final column, or the pane below.

I'm glad to see that. Dbs like opebldap are way too complicated for simple tasks like having multiple users for NAS' and tools in a small group. It reminds me of send mail with the hours of config.

This seems to be just want I was looking for. Right now I use keycloak but I'd like to have user data separate.

I'm what format is data stored? How resilient is the stored data against corruption?

The data is stored in an sqlite database, it's very easy to backup/copy.

I'm planning on supporting alternate DBs as well.

Great work~

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.

Samba uses a home-grown LDAP server, rather than OpenLDAP.

That's correct. UCS makes use of both.

Looks like the frontend is Rust via webassembly. Is that right? I haven't seen that before. What other intermediate packages are used?

I'm not sure what you mean by intermediate packages, but roughly the main dependencies are: - Backend: sea-query to build the SQL queries, Sqlx to run them, actix for the http frontend, ldap3_proto to handle LDAP protocol, juniper for GraphQL - Frontend: built on top of the Yew framework. It needs updating but the new update is a very breaking change, so it's a major refactoring.

Yew framework answers my question. Thanks!

Or setup Samba and get LDAP for free and can be managed with Active Directory Users and Computers (ADUC)

Can this be used for automatic tests or there are some other tools that people use for that use case?

We develop apps that have LDAP/AD auth. integration and I always wanted to have that feature tested locally, without relying on corporate network and full blown LDAP/AD server.

I use Samba to setup an LDAP database that mostly reflects how the Active Directory schema looks like https://github.com/jborean93/PSOpenAD/blob/main/tools/setup-.... It's not perfect but a lot easier than trying to setup an actual Windows domain in a CI environment.

This is fantastic. LDAP servers have always been atrocious.

Can anyone suggest an open source self-hosted IdP for use with SAML and/or OAuth? Specifically not looking for a cloud-hosted one, and ideally not something horrifyingly complicated like Shibboleth.

> Can anyone suggest an open source self-hosted IdP for use with SAML and/or OAuth?

Have you tried KeyCloak?

You might want to give ZITADEL a spin https://github.com/zitadel/zitadel SAML2.0 is on a PR right now, but ready to be merged very soon. Would be glad to get your feedback. (discl. I work for ZITADEL)

I’ll watch with interest, and am heartened with the responses I see. One thing I wish is that the license were also more “lightweight”. GPL3 for a piece of backend network infra seems a bit fraught. This is usually the domain of ISC, MIT, or BSD.

Samba is GPLv3. OpenLDAP has its own license but has some GPL-like clauses regarding code redistribution. I can’t recall what NIS is licensed under but it was written by Sun and then licensed to other vendors so odds are it’s not MIT/BSD either.

OpenLDAP's license is a pretty standard BSD 3-clause.

It's not BSD: https://www.openldap.org/software/release/license.html

Why would you want that? Genuine question. You say "lightweight" but what does that mean, and why is it "fraught"?

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 "lightweight" in terms of text and comprehension.

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/

Thank you for this project. I don't plan to use it in production, but it will be interesting to test it in a small network.

It says it only supports subset of LDAP, but it like to know what is included. Or better, what is missing.

It only implements read-only queries and bind, plus password modification. User creation has to go through the web UI or API, and custom schemas are not supported. Any esoteric feature is probably also not implemented.

This sounds amazing! I'm going to have to try it out tonight.

I've been searching for this for a long time. Thank you!

Does anyone actually use LDAP as a user store these days anymore?

What do you use instead?

A lot of SaaS services just auth against other SaaS accounts, like Google/Azure/Github/AWS.

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.

Guess what Google, Microsoft base your SaaS auth on (can't speak for GH,AWS).

> I don't love this state of affairs as I'd rather just use my pass

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.

Yeah, because there's nothing else and everything supports LDAP. Even if you're using some SaaS offering when it comes time to integrate it with off-the-shelf on-prem software the path of least resistance is pretty much always LDAP.

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.

Its extensible, standartised and available as backend in many products.

Just about every major enterprise in the world?

Nope. No one. Everyone uses cloud nowadays.

absolutely.

Paging hyc!

Meh.

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.

I hear you, I initially didn't want to reimplement a whole server for that. And there are arguments for scrapping the API I slapped in front of it and make everything go through LDAP.

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.

I'm guessing you mean "and the software is fast enough", because OpenLDAP itself has been the world's fastest distributed database for over a decade, and nothing else even comes close.

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.

Reply on news.ycombinator.com