36 ms·

Show HN: Lldap, a Simplified LDAP Server

229 points by nitnelave 4y ago

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.

deleted 4y ago
[deleted]
bch 4y ago
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.
- laumars 4y ago
  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.
  - hyc_symas 4y ago
    OpenLDAP's license is a pretty standard BSD 3-clause.
    - laumars 4y ago
      It's not BSD: https://www.openldap.org/software/release/license.html https://www.openldap.org/software/release/license.html
- bartvk 4y ago
  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.
  - bch 4y ago
    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/ https://ardour.org/
raxxorraxor 4y ago
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.
hdjjhhvvhga 4y ago
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.
aorth 4y ago
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.
- zokier 4y ago
  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
GuB-42 4y ago
I like the irony. LLDAP: lightweight lightweight directory access protocol I wonder how terrible DAP may be if LDAP is "lightweight".
- noselasd 4y ago
  "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 https://en.wikipedia.org/wiki/X.500 (aka. DAP)
  - dfox 4y ago
    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.
    - dboreham 4y ago
      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.
      - hyc_symas 4y ago
        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.
candiddevmike 4y ago
Another project with similar goals, glauth: https://github.com/glauth/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.
- kbumsik 4y ago
  I was looking for an LDAP server and this looks promising. Thanks for sharing!
- vidarh 4y ago
  It's trivial to reload openldap data from ldif, so you can already manage LDAP via Ansible easily enough.
  - xorcist 4y ago
    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.
    - vidarh 4y ago
      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.
      - xorcist 4y ago
        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.)
majewsky 4y ago
FWIW, I have another entry in the same genre: https://github.com/majewsky/portunus https://github.com/majewsky/portunus - Seems like there really is a lot of pain with LDAP to go around.
- sanxiyn 4y ago
  Note that Portunus still uses OpenLDAP, it's just "OpenLDAP server is completely managed by Portunus". lldap doesn't use OpenLDAP at all.
  - majewsky 4y ago
    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.
    - solarkraft 4y ago
      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.
spockz 4y ago
Interesting. Maybe we will use this as a lightweight mock of our ldap server for integratie tests. Or glauth mentioned by candiddevmike.
usrn 4y ago
This sounds amazing! I'm going to have to try it out tonight.
yuri91 4y ago
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!
- dizhn 4y ago
  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.
  - cassianoleal 4y ago
    I configured Authelia in about 5 minutes, using glauth for LDAP. Authentik looks good though, it's in my queue of things to try.
    - dizhn 4y ago
      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.
  - yuri91 4y ago
    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.
- dmd 4y ago
  I have a PhD and can't configure openldap
  - znpy 4y ago
    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/ 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...
dingleberry420 4y ago
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.
- Timon3 4y ago
  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/ http://ldapjs.org/
- mgbmtl 4y ago
  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.
  - dingleberry420 4y ago
    Right, I want to hook this up to my existing postgres/mysql database with existing schema.
- nitnelave 4y ago
  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.
  - dingleberry420 4y ago
lukeh 4y ago
Paging hyc!
- hyc_symas 4y ago
  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.
  - nitnelave 4y ago
    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.
lakomen 4y ago
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?
- nitnelave 4y ago
  The data is stored in an sqlite database, it's very easy to backup/copy. I'm planning on supporting alternate DBs as well.
blantonl 4y ago
Does anyone actually use LDAP as a user store these days anymore?
- ekianjo 4y ago
  What do you use instead?
  - mikepurvis 4y ago
    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.
    - Jiocus 4y ago
      Guess what Google, Microsoft base your SaaS auth on (can't speak for GH,AWS).
    - laumars 4y ago
      > 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.
- Spivak 4y ago
  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.
- 4y ago
mrweasel 4y ago
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.
- easrng 4y ago
  Isn't integrating everything with LDAP how we got log4j though
  - dboreham 4y ago
    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.
- p4l4g4 4y ago
  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.
jollyllama 4y ago
Looks like the frontend is Rust via webassembly. Is that right? I haven't seen that before. What other intermediate packages are used?
- nitnelave 4y ago
  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.
  - jollyllama 4y ago
    Yew framework answers my question. Thanks!
znpy 4y ago
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...
- derekzhouzhen 4y ago
  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.
- yrro 4y ago
  > 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_directory_server/12/html/red_hat_directory_server_12_release_notes/assembly_red-hat-directory-server-12-0_rhds-12-rn#ref_highlighted-updates-and-new-features_assembly_red-hat-directory-server-12-0 https://access.redhat.com/documentation/en-us/red_hat_direct... [1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/release_notes/directory-server-11.5#highlighted-updates-and-new-features-11.5 https://access.redhat.com/documentation/en-us/red_hat_direct... [2] https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/release_notes/directory-server-11.4#highlighted-updates-and-new-features-11.4 https://access.redhat.com/documentation/en-us/red_hat_direct... [3] https://directory.fedoraproject.org/docs/389ds/FAQ/roadmap.html https://directory.fedoraproject.org/docs/389ds/FAQ/roadmap.h...
ta988 4y ago
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.
nitnelave 4y ago
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 :)
- hangonhn 4y ago
  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.
- throw0101a 4y ago
  An updated draft was just released last week: * https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque
- jdswain 4y ago
  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.
- hyc_symas 4y ago
  You could use an LDAP SASL Bind instead, using any of a variety of strong authentication mechanisms then without plaintext passwords.
exabrial 4y ago
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.
- nitnelave 4y ago
  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.
  - exabrial 4y ago
    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.
Jiocus 4y ago
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.
- lukeh 4y ago
  Samba uses a home-grown LDAP server, rather than OpenLDAP.
  - Jiocus 4y ago
    That's correct. UCS makes use of both.
gscho 4y ago
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".
muhehe 4y ago
It says it only supports subset of LDAP, but it like to know what is included. Or better, what is missing.
- nitnelave 4y ago
  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.
Datagenerator 4y ago
Or setup Samba and get LDAP for free and can be managed with Active Directory Users and Computers (ADUC)
KronisLV 4y ago
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).
- robohoe 4y ago
  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.
- mschuster91 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - KronisLV 4y ago
    > 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/ 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).
0xbadcafebee 4y ago
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.
- mffap 4y ago
  You might want to give ZITADEL a spin https://github.com/zitadel/zitadel 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)
- ggop 4y ago
  > Can anyone suggest an open source self-hosted IdP for use with SAML and/or OAuth? Have you tried KeyCloak?
majkinetor 4y ago
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.
- jborean93 4y ago
  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-samba.sh 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.
lazypenguin 4y ago
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!
mindwok 4y ago
I've been searching for this for a long time. Thank you!
whartung 4y ago
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.
yrro 4y ago
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.

229 points by nitnelave 4y ago

deleted 4y ago

[deleted]

bch 4y ago

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.

laumars 4y ago
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.
- hyc_symas 4y ago
  OpenLDAP's license is a pretty standard BSD 3-clause.
  - laumars 4y ago
    It's not BSD: https://www.openldap.org/software/release/license.html https://www.openldap.org/software/release/license.html
bartvk 4y ago
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.
- bch 4y ago
  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/ https://ardour.org/

raxxorraxor 4y ago

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.

hdjjhhvvhga 4y ago

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.

aorth 4y ago

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.

zokier 4y ago
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

GuB-42 4y ago

I like the irony. LLDAP: lightweight lightweight directory access protocol I wonder how terrible DAP may be if LDAP is "lightweight".

noselasd 4y ago
"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 https://en.wikipedia.org/wiki/X.500 (aka. DAP)
- dfox 4y ago
  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.
  - dboreham 4y ago
    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.
    - hyc_symas 4y ago
      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.

candiddevmike 4y ago

Another project with similar goals, glauth: https://github.com/glauth/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.

kbumsik 4y ago
I was looking for an LDAP server and this looks promising. Thanks for sharing!
vidarh 4y ago
It's trivial to reload openldap data from ldif, so you can already manage LDAP via Ansible easily enough.
- xorcist 4y ago
  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.
  - vidarh 4y ago
    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.
    - xorcist 4y ago
      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.)

majewsky 4y ago

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

sanxiyn 4y ago
Note that Portunus still uses OpenLDAP, it's just "OpenLDAP server is completely managed by Portunus". lldap doesn't use OpenLDAP at all.
- majewsky 4y ago
  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.
  - solarkraft 4y ago
    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.

spockz 4y ago

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

usrn 4y ago

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

yuri91 4y ago

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!

dizhn 4y ago
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.
- cassianoleal 4y ago
  I configured Authelia in about 5 minutes, using glauth for LDAP. Authentik looks good though, it's in my queue of things to try.
  - dizhn 4y ago
    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.
- yuri91 4y ago
  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.
dmd 4y ago
I have a PhD and can't configure openldap
- znpy 4y ago
  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/ 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...

dingleberry420 4y ago

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.

Timon3 4y ago
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/ http://ldapjs.org/
mgbmtl 4y ago
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.
- dingleberry420 4y ago
  Right, I want to hook this up to my existing postgres/mysql database with existing schema.
nitnelave 4y ago
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.
- dingleberry420 4y ago

lukeh 4y ago

Paging hyc!

hyc_symas 4y ago
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.
- nitnelave 4y ago
  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.

lakomen 4y ago

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?

nitnelave 4y ago
The data is stored in an sqlite database, it's very easy to backup/copy. I'm planning on supporting alternate DBs as well.

blantonl 4y ago

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

ekianjo 4y ago
What do you use instead?
- mikepurvis 4y ago
  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.
  - Jiocus 4y ago
    Guess what Google, Microsoft base your SaaS auth on (can't speak for GH,AWS).
  - laumars 4y ago
    > 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.
Spivak 4y ago
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.
4y ago

mrweasel 4y ago

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.

easrng 4y ago
Isn't integrating everything with LDAP how we got log4j though
- dboreham 4y ago
  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.
p4l4g4 4y ago
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.

jollyllama 4y ago

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

nitnelave 4y ago
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.
- jollyllama 4y ago
  Yew framework answers my question. Thanks!

znpy 4y ago

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

derekzhouzhen 4y ago
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.
yrro 4y ago
> 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_directory_server/12/html/red_hat_directory_server_12_release_notes/assembly_red-hat-directory-server-12-0_rhds-12-rn#ref_highlighted-updates-and-new-features_assembly_red-hat-directory-server-12-0 https://access.redhat.com/documentation/en-us/red_hat_direct... [1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/release_notes/directory-server-11.5#highlighted-updates-and-new-features-11.5 https://access.redhat.com/documentation/en-us/red_hat_direct... [2] https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/release_notes/directory-server-11.4#highlighted-updates-and-new-features-11.4 https://access.redhat.com/documentation/en-us/red_hat_direct... [3] https://directory.fedoraproject.org/docs/389ds/FAQ/roadmap.html https://directory.fedoraproject.org/docs/389ds/FAQ/roadmap.h...

ta988 4y ago

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.

nitnelave 4y ago

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

hangonhn 4y ago
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.
throw0101a 4y ago
An updated draft was just released last week: * https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-opaque
jdswain 4y ago
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.
hyc_symas 4y ago
You could use an LDAP SASL Bind instead, using any of a variety of strong authentication mechanisms then without plaintext passwords.

exabrial 4y ago

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.

nitnelave 4y ago
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.
- exabrial 4y ago
  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.

Jiocus 4y ago

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.

lukeh 4y ago
Samba uses a home-grown LDAP server, rather than OpenLDAP.
- Jiocus 4y ago
  That's correct. UCS makes use of both.

gscho 4y ago

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

muhehe 4y ago

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

nitnelave 4y ago
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.

Datagenerator 4y ago

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

KronisLV 4y ago

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

robohoe 4y ago
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.
mschuster91 4y ago
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.
- deleted 4y ago
  [deleted]
- KronisLV 4y ago
  > 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/ 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).

0xbadcafebee 4y ago

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.

mffap 4y ago
You might want to give ZITADEL a spin https://github.com/zitadel/zitadel 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)
ggop 4y ago
> Can anyone suggest an open source self-hosted IdP for use with SAML and/or OAuth? Have you tried KeyCloak?

majkinetor 4y ago

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.

jborean93 4y ago
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-samba.sh 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.

lazypenguin 4y ago

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!

mindwok 4y ago

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

whartung 4y ago

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.

yrro 4y ago

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.