10 ms·

RedHat and SUSE Withdrawing Support for OpenLDAP

99 points by djsumdog 8y ago

vorpalhex 8y ago
Source was down for me, here's the archive link: https://web.archive.org/web/20180828133125/https://www.ostechnix.com/redhat-and-suse-announced-to-withdraw-support-for-openldap/ https://web.archive.org/web/20180828133125/https://www.ostec...
amyjess 8y ago
According to the article (and articles I've read on this subject before), they are not ditching LDAP entirely but rather they are switching which implementation they'll be supporting from now on: instead of supporting OpenLDAP, they will be supporting the 389 Directory Server, which does everything OpenLDAP does.
- kazen44 8y ago
  so i assume people running freeIPA will be fine? Considering it is based on 389?
- xenophonf 8y ago
  389 is based on Netscape Directory Server which forked UMN's slapd way back when. Red Hat sells a branded version of it called "Red Hat Directory Server", although last I checked everything was released under reasonably free software licenses. Frankly, as long as I can install current OpenLDAP packages on CentOS/Fedora from base, an SCL, or EPEL, I'm OK with this change.
_wmd 8y ago
This is a real shame, Howard is an absolute asset not just for his LDAP work, but for the LMDB database engine borne from it and the ton of supporting technical materials surrounding it. Symas (Chu's consulting company) have a far clearer take on the matter: https://symas.com/message-president-regarding-red-hat-suse-removing-openldap-linux-distributions/ https://symas.com/message-president-regarding-red-hat-suse-r... , seems this is entirely motivated by upsell. Red Hat's move here is a bit like taking a trusted well-supported tool like bash and replacing it with some shit branch of ksh from 1984, and forcing people to pay for it.
- amyjess 8y ago
  That article is incredibly biased. Precisely because it's run by Chu's consulting company, I cannot trust them when they describe 389DS as "a less-capable LDAP server". It is simply one company attacking a competitor's product. And of course the article contains direct links to both a page where you can buy support packages for OpenLDAP and something called "OpenLDAP Gold".
  - reqa 8y ago
    To clarify for others: You are talking about Symas. Univention is a Linux distributor that builds their products based on Debian and is in no way related to Symas. See e.g. https://wiki.debian.org/Derivatives/Census/UniventionCorporateServer https://wiki.debian.org/Derivatives/Census/UniventionCorpora...
  - _wmd 8y ago
    That is not an opinion based on any marketing material - 389DS is an unreliable dog, and even today it's still built on top of an Oracle-owned database engine. There is no need to attack Symas for selling a supported variant of OpenLDAP, it's valid under the license after all, they have been the exclusive maintainers for OpenLDAP for many, many years, and it is of course the exact same model used for 389 DS. Meanwhile everyone is free to share links to counterpoints in support of 389DS, assuming you can find any.
    - amyjess 8y ago
      > There is no need to attack Symas for selling a supported variant of OpenLDAP, it's valid under the license after all That's not what I'm saying. I'm saying that one shouldn't take their criticisms of a competitor's product seriously when they are selling their own product in the press release itself. It's a conflict of interest.
    - Twirrim 8y ago
      > That is not an opinion based on any marketing material ... >they have been the exclusive maintainers for OpenLDAP for many, many years, I think your critical source analysis skills might need some brushing off.
Allaman 8y ago
The link has an internal server error :(
MattSteelblade 8y ago
Reading the article, it doesn't look like RedHat announced anything recently. In the SUSE release notes, "389 Directory Server replaces OpenLDAP to provide a sustainable directory service." Is there really any news here?
oneplane 8y ago
If I'm reading this correctly, they are withdrawing commercial support. I don't see the problem here; if you want 'normal' FOSS support you'll get whatever you are used to, and if you want paid support from your distro vendor it matters just a little bit what implementation you use since you're paying someone else to make it 'just work'.
VLM 8y ago
Will the LDAP server merge into systemd or will it merely exclusively product tie or will it just be marketing? Just curious how easy it'll be to continue using what works as opposed to what marketing wants to sell.
zaarn 8y ago
I recently installed OpenLDAP on a server because I wanted an LDAP Server. Sadly, LDAP isn't the most accessible system in the world and I only managed to set it up using FreeIPA, which is based no the 389 system mentioned in the article. Most advice online around LDAP seems to amount to "ask your sysadmin", which isn't terribly useful either when I'm the sysadmin. I hope 389DS will make LDAP a bit easier for newcomers like me.
- foepys 8y ago
  If you search the internet for advice on how to install OpenLDAP, you will also get thousands of results with examples for outdated versions and configurations that will not work. It's a real headache.
- gargravarr 8y ago
  I built my company's LDAP infrastructure using OpenLDAP from scratch. It's redefined my pain threshold in the process! OpenLDAP is a solid piece of software, no doubt, but there's one critical problem - most of the guides are third-party because the OpenLDAP documentation has been pretty lacking for a long time, and those guides are usually from the era before the entire thing was redesigned around OLC and LDIF! Adapting the guides is beyond irritating. I'm now at the stage where I have the schema defined and I no longer want to touch it, /ever/!
  - oblio 8y ago
    My guess is that it's consultingware. Open Source projects with crap documentation usually are. You're meant to hire the devs as consultants. I could be wrong, but it's a common pattern.
AllegedAlec 8y ago
Shouldn't the title in some way allude to that the article was written by a RedHat/Suse competitor?
LinuxBender 8y ago
If they linked to the Redhat article, it would have removed some confusion I believe. [1] Or maybe they did and I missed it? [1] - https://access.redhat.com/solutions/2440481 https://access.redhat.com/solutions/2440481 >Important: Starting with Red Hat Enterprise Linux 7.4, the openldap-servers package has been deprecated and will not be included in a future major release of Red Hat Enterprise Linux.
- JoshTriplett 8y ago
  > If they linked to the Redhat article, it would have removed some confusion I believe. Given the source of the article, they're not looking to remove confusion, they're looking to benefit from it.
- jwilk 8y ago
  They did link to this announcement.
amaccuish 8y ago
I wish 389ds would get rid of the java requirement. I'm sticking with Samba4 right now, both for AD and as an LDAP store for apps; replication handles itself, sites etc, makes life so much easier.
- dboreham 8y ago
  There is no Java requirement.
  - vetinari 8y ago
    Java is needed for the admin console. For the server itself, it is not needed.
  - amaccuish 8y ago
    As "vetinari", you need it for the console.
    - dboreham 8y ago
      And you don't need the console.
rkeene2 8y ago
For a large enterprise deployment of LDAP I used OpenLDAP over 389DS/RHDS/FreeIPA because it was straight-forward and solved the problems of a multi-master and slave-to-each-master architecture well. The initial deployment used Sun Directory Server Enterprise Edition (Sun DSEE, now Oracle DSEE) but when Oracle bought Sun we had conversations with Oracle's product team where they explicitly stated that going forward Sun DSEE would be discontinued and replaced by Oracle's competing (but from our perspective, inferior) product. Contrary to most of the posters here I had no significant trouble figuring out OpenLDAP and found the documentation complete. The main pain points I ran into were: - OpenLDAP was trying to move configuration inside the DIT, which made system administration harder - I ran into some bugs with MDB on Solaris/UltraSPARC before it was officially announced - I ran into some bugs, which the OpenLDAP team fixed In a later job, I was supporting a customer who purcashed RedHat Directory Services (RHDS) and therefore they wanted to use this in preference to OpenLDAP, but it conveyed no advantages, and had worse characteristics and licensing requirements with regards to multi-master replication. The reason the customer purchased RHDS was because their "Solution Architect" team thought they could use it to integrate with Active Directory authentication. However, RHDS's integration mechanism required that something be installed on all Active Directory servers (of which there were around 200, managed by various other companies) this plan was not feasible. Instead, I created a PAM module and used RHDS's "pam_tally" to pass through authentication attempts. This was not as good as could be done on OpenLDAP, however, because pam_tally creates a lock in RHDS and no authentication could happen while it was authenticating -- leading to a few nation-wide lockouts while I figured this undocumented feature out.
JoshTriplett 8y ago
> Since 2003 Univention supports OpenLDAP for enterprise use. It is one of the central components of their product Univention Corporate Server (UCS). ... > This is a guest post from Univention.
kakwa_ 8y ago
ahh, OpenLDAP, I've a weird Stockholm syndrome with that piece of software. It's probably one of the most reliable nosql DB out there. And you can actually implement schemas to ensure data formatting \o/ (provided you like OIDs...). It can support quite rich ACLs, but those are a little hard to debug and fix. But it's nice it is there. You also have an interesting query language using polish notations (okay, I prefer to slapcat the complete directory and do '|less' or '|grep' if I've direct access to the server and if it's not too big, I could never remember the options names in ldapsearch). Lastly the ldif syntax is so great, I always have to google it even for the most basic edits... More seriously, ldap is somewhat painful to deploy: * Indeed the documentation is a bit lacking, the zytrax one is great but somewhat dated (specially with the cn=config paradigm). * If you are doing complex setups like n-way multi-masters replication the documentation is somewhat verbose and really hard to understand (https://www.openldap.org/doc/admin24/replication.html https://www.openldap.org/doc/admin24/replication.html). Generally it involves a lot of trial and errors in a lab to figure it out. * There can be traps if you are not aware of the internals. For example, in one of our deployments we were maintaining large groups, and batch updates were taking a really long time. After digging, I finally understood why: each time you add or remove an entry in a group, it rewrites the complete group entry (at least with the BDB backend), rewritting 100000 entries each time you update one is somewhat costly... Not sure if it's still the case with the lmdb backend however. * The source code is not really easy to read in my opinion. I did try it once (debugging the issue mentioned above), but was not successful at roughly understanding how it worked from reading the source code, at least in the few hours I devoted to it (I know, it's not necessarily a lot). * Usually, with replication, schema tweaking, backups, monitoring and some testing, deploying OpenLDAP can easily be a one or two months project. * deploying all the integrations correctly is also quite hard (ldap auth for ssh or web authentication on each web applications), That being said, 389 Directory/RedHat Directory Server is not much better, the setup is done through a weird perl script. Setup ssl/tls is a pain (I learn to hate certutil, and its certs/ca/private keys in DBs, deploying flat pem files is so much easier and convenient). The "rich" client looks like it has not changed in years (or removed all together), and it looks so much like the Old Sun One I'm wondering if it has changed since the Netscape days apart from code maintenance. Also, I'm not sure if it's still the case, but IIRC RDS is a separate subscription from RedHat, it doesn't come with a basic RHEL OS subscription (I recall having to recompile the srpm my self when 6.0 went out). RHEL was also not a really great maintainer of their OpenLDAP packages, I remember for example a breaking change because they went from 2.4.38 to 2.4.41 (I'm expecting a stable distro like RHEL to not introduce breaking changes, and to not update software like a rolling release, Debian does a far better job at it for example). After all this 'praise' of the ldap world, you must think I actually hate it. No, I actually kind of like it (to the point of maintaining an ldap web UI). Having a centralized user DB makes things so much easier for everybody, the user only has one password, the security officer can trustfully enable/disable accesses, the sysadmin as one source of truth. If you maintain local accounts for each of your applications you are in for a lot of troubles down the line. It's also an authentication method that is widely supported by most applications, and if it's not, there is probably a ticket/PR/patch somewhere to add it. Lastly once it's setup and configured, it's generally quite reliable even with complex replication setups, this makes it relatively low maintenance. And at least for reads, it has quite good performances. OpenLdap: I love to hate you, but I love you.
jakobdabo 8y ago
There is an interesting fork of OpenLDAP called ReOpenLDAP - https://github.com/leo-yuriev/ReOpenLDAP https://github.com/leo-yuriev/ReOpenLDAP
nineteen999 8y ago
As a long time OpenLDAP user (ie. probably going on 20+ years at this point), and as somebody who will be rolling out LDAP again on a long-term project on RHEL 7.5 shortly I have a few questions about 389DS. I've considered migrating to it for this project, but I just have too many open questions regarding setting it up right now. 1) I need support for both RFC2307 and RFC2307bis. I haven't found any good documentation on how to set these up from scratch with 389DS where it's fairly trivial to make them work together with OpenLDAP and the memberof overlay. 2) I also have a need for an equivalent of the Tacacs schema that works with the mavis-Tacacs fork that Google maintains. Will this schema work with 389DS? 3) Same goes for the sudo.schema that is provided with sudo - does this work with 389DS? 4) Same goes for the ppolicy.schema (password policy) schema (ppolicy overlay) and memberof overlay. What are the equivalents of these for 389DS? 5) multi-master replication - OpenLDAP makes this a breeze, but not so sure with 389DS. Finding information about how to implement these things from scratch seems extremely hard for 389DS. Granted, it was also hard for OpenLDAP, but that work is behind me now. I have serious misgivings about trying to reimplement all of this on 389DS within my given timeframe. Other things that irk me about this decision: a) I really dislike the Java console - doesn't feel like it changed much since the 1990's. It's still slow, ugly and doesn't feel like it integrates well. b) feels like a weird choice to drop the openldap-server packages but not the openldap-clients package. Are they going to provide a replacement for the OpenLDAP client libraries eventually as well? Is there even a good alternative (ie. API compatible and replacements for all the command line utilities) to openldap-clients? While it seems like an easy decision to move on the surface, most OpenLDAP deployments have a massive amount of customisations to make all the third-party applications work, and 389DS making those kind of migrations easy doesn't currently seem like one of its strong selling points.
- hyc_symas 8y ago
  >b) feels like a weird choice to drop the openldap-server packages but not the openldap-clients package. Are they going to provide a replacement for the OpenLDAP client libraries eventually as well? Is there even a good alternative (ie. API compatible and replacements for all the command line utilities) to openldap-clients? They have no choice here, they use OpenLDAP's libraries. Mozilla/Netscape's own LDAP SDK has been unmaintained for more than a decade; it's abandonware.
h1d 8y ago
I'm in a small (< 10 users) shop having OpenLDAP to store users that integrates with Apache authentication, postfix/dovecot authentication and manages users with (patched) phpLdapAdmin but hearing that OpenLDAP may not have a bright future, what should I replace it with for central user management for Linux?
- reqa 8y ago
  OpenLDAP will not go away, see https://lwn.net/Articles/755207/ https://lwn.net/Articles/755207/ for a current road map. Only RedHat doesn't support it any longer, that's all, no worries.
  - h1d 8y ago
    Seeing how I need a patched version of phpLdapAdmin maintained by a third party instead of the one provided by Ubuntu 18.04 and a lack of easy to use GUI app for LDAP administration, let alone any third party client interface for users to login and change their password, I'm starting to think no one likes LDAP and should move over, perhaps even to MySQL as user management database.

99 points by djsumdog 8y ago

Source was down for me, here's the archive link: https://web.archive.org/web/20180828133125/https://www.ostechnix.com/redhat-and-suse-announced-to-withdraw-support-for-openldap/ https://web.archive.org/web/20180828133125/https://www.ostec...

amyjess 8y ago

According to the article (and articles I've read on this subject before), they are not ditching LDAP entirely but rather they are switching which implementation they'll be supporting from now on: instead of supporting OpenLDAP, they will be supporting the 389 Directory Server, which does everything OpenLDAP does.

kazen44 8y ago
so i assume people running freeIPA will be fine? Considering it is based on 389?
xenophonf 8y ago
389 is based on Netscape Directory Server which forked UMN's slapd way back when. Red Hat sells a branded version of it called "Red Hat Directory Server", although last I checked everything was released under reasonably free software licenses. Frankly, as long as I can install current OpenLDAP packages on CentOS/Fedora from base, an SCL, or EPEL, I'm OK with this change.

_wmd 8y ago

This is a real shame, Howard is an absolute asset not just for his LDAP work, but for the LMDB database engine borne from it and the ton of supporting technical materials surrounding it. Symas (Chu's consulting company) have a far clearer take on the matter: https://symas.com/message-president-regarding-red-hat-suse-removing-openldap-linux-distributions/ https://symas.com/message-president-regarding-red-hat-suse-r... , seems this is entirely motivated by upsell. Red Hat's move here is a bit like taking a trusted well-supported tool like bash and replacing it with some shit branch of ksh from 1984, and forcing people to pay for it.

amyjess 8y ago
That article is incredibly biased. Precisely because it's run by Chu's consulting company, I cannot trust them when they describe 389DS as "a less-capable LDAP server". It is simply one company attacking a competitor's product. And of course the article contains direct links to both a page where you can buy support packages for OpenLDAP and something called "OpenLDAP Gold".
- reqa 8y ago
  To clarify for others: You are talking about Symas. Univention is a Linux distributor that builds their products based on Debian and is in no way related to Symas. See e.g. https://wiki.debian.org/Derivatives/Census/UniventionCorporateServer https://wiki.debian.org/Derivatives/Census/UniventionCorpora...
- _wmd 8y ago
  That is not an opinion based on any marketing material - 389DS is an unreliable dog, and even today it's still built on top of an Oracle-owned database engine. There is no need to attack Symas for selling a supported variant of OpenLDAP, it's valid under the license after all, they have been the exclusive maintainers for OpenLDAP for many, many years, and it is of course the exact same model used for 389 DS. Meanwhile everyone is free to share links to counterpoints in support of 389DS, assuming you can find any.
  - amyjess 8y ago
    > There is no need to attack Symas for selling a supported variant of OpenLDAP, it's valid under the license after all That's not what I'm saying. I'm saying that one shouldn't take their criticisms of a competitor's product seriously when they are selling their own product in the press release itself. It's a conflict of interest.
  - Twirrim 8y ago
    > That is not an opinion based on any marketing material ... >they have been the exclusive maintainers for OpenLDAP for many, many years, I think your critical source analysis skills might need some brushing off.

Allaman 8y ago

The link has an internal server error :(

MattSteelblade 8y ago

Reading the article, it doesn't look like RedHat announced anything recently. In the SUSE release notes, "389 Directory Server replaces OpenLDAP to provide a sustainable directory service." Is there really any news here?

oneplane 8y ago

If I'm reading this correctly, they are withdrawing commercial support. I don't see the problem here; if you want 'normal' FOSS support you'll get whatever you are used to, and if you want paid support from your distro vendor it matters just a little bit what implementation you use since you're paying someone else to make it 'just work'.

VLM 8y ago

Will the LDAP server merge into systemd or will it merely exclusively product tie or will it just be marketing? Just curious how easy it'll be to continue using what works as opposed to what marketing wants to sell.

zaarn 8y ago

I recently installed OpenLDAP on a server because I wanted an LDAP Server. Sadly, LDAP isn't the most accessible system in the world and I only managed to set it up using FreeIPA, which is based no the 389 system mentioned in the article. Most advice online around LDAP seems to amount to "ask your sysadmin", which isn't terribly useful either when I'm the sysadmin. I hope 389DS will make LDAP a bit easier for newcomers like me.

foepys 8y ago
If you search the internet for advice on how to install OpenLDAP, you will also get thousands of results with examples for outdated versions and configurations that will not work. It's a real headache.
gargravarr 8y ago
I built my company's LDAP infrastructure using OpenLDAP from scratch. It's redefined my pain threshold in the process! OpenLDAP is a solid piece of software, no doubt, but there's one critical problem - most of the guides are third-party because the OpenLDAP documentation has been pretty lacking for a long time, and those guides are usually from the era before the entire thing was redesigned around OLC and LDIF! Adapting the guides is beyond irritating. I'm now at the stage where I have the schema defined and I no longer want to touch it, /ever/!
- oblio 8y ago
  My guess is that it's consultingware. Open Source projects with crap documentation usually are. You're meant to hire the devs as consultants. I could be wrong, but it's a common pattern.

AllegedAlec 8y ago

Shouldn't the title in some way allude to that the article was written by a RedHat/Suse competitor?

LinuxBender 8y ago

If they linked to the Redhat article, it would have removed some confusion I believe. [1] Or maybe they did and I missed it? [1] - https://access.redhat.com/solutions/2440481 https://access.redhat.com/solutions/2440481 >Important: Starting with Red Hat Enterprise Linux 7.4, the openldap-servers package has been deprecated and will not be included in a future major release of Red Hat Enterprise Linux.

JoshTriplett 8y ago
> If they linked to the Redhat article, it would have removed some confusion I believe. Given the source of the article, they're not looking to remove confusion, they're looking to benefit from it.
jwilk 8y ago
They did link to this announcement.

amaccuish 8y ago

I wish 389ds would get rid of the java requirement. I'm sticking with Samba4 right now, both for AD and as an LDAP store for apps; replication handles itself, sites etc, makes life so much easier.

dboreham 8y ago
There is no Java requirement.
- vetinari 8y ago
  Java is needed for the admin console. For the server itself, it is not needed.
- amaccuish 8y ago
  As "vetinari", you need it for the console.
  - dboreham 8y ago
    And you don't need the console.

rkeene2 8y ago

For a large enterprise deployment of LDAP I used OpenLDAP over 389DS/RHDS/FreeIPA because it was straight-forward and solved the problems of a multi-master and slave-to-each-master architecture well. The initial deployment used Sun Directory Server Enterprise Edition (Sun DSEE, now Oracle DSEE) but when Oracle bought Sun we had conversations with Oracle's product team where they explicitly stated that going forward Sun DSEE would be discontinued and replaced by Oracle's competing (but from our perspective, inferior) product. Contrary to most of the posters here I had no significant trouble figuring out OpenLDAP and found the documentation complete. The main pain points I ran into were: - OpenLDAP was trying to move configuration inside the DIT, which made system administration harder - I ran into some bugs with MDB on Solaris/UltraSPARC before it was officially announced - I ran into some bugs, which the OpenLDAP team fixed In a later job, I was supporting a customer who purcashed RedHat Directory Services (RHDS) and therefore they wanted to use this in preference to OpenLDAP, but it conveyed no advantages, and had worse characteristics and licensing requirements with regards to multi-master replication. The reason the customer purchased RHDS was because their "Solution Architect" team thought they could use it to integrate with Active Directory authentication. However, RHDS's integration mechanism required that something be installed on all Active Directory servers (of which there were around 200, managed by various other companies) this plan was not feasible. Instead, I created a PAM module and used RHDS's "pam_tally" to pass through authentication attempts. This was not as good as could be done on OpenLDAP, however, because pam_tally creates a lock in RHDS and no authentication could happen while it was authenticating -- leading to a few nation-wide lockouts while I figured this undocumented feature out.

JoshTriplett 8y ago

> Since 2003 Univention supports OpenLDAP for enterprise use. It is one of the central components of their product Univention Corporate Server (UCS). ... > This is a guest post from Univention.

kakwa_ 8y ago

ahh, OpenLDAP, I've a weird Stockholm syndrome with that piece of software. It's probably one of the most reliable nosql DB out there. And you can actually implement schemas to ensure data formatting \o/ (provided you like OIDs...). It can support quite rich ACLs, but those are a little hard to debug and fix. But it's nice it is there. You also have an interesting query language using polish notations (okay, I prefer to slapcat the complete directory and do '|less' or '|grep' if I've direct access to the server and if it's not too big, I could never remember the options names in ldapsearch). Lastly the ldif syntax is so great, I always have to google it even for the most basic edits... More seriously, ldap is somewhat painful to deploy: * Indeed the documentation is a bit lacking, the zytrax one is great but somewhat dated (specially with the cn=config paradigm). * If you are doing complex setups like n-way multi-masters replication the documentation is somewhat verbose and really hard to understand (https://www.openldap.org/doc/admin24/replication.html https://www.openldap.org/doc/admin24/replication.html). Generally it involves a lot of trial and errors in a lab to figure it out. * There can be traps if you are not aware of the internals. For example, in one of our deployments we were maintaining large groups, and batch updates were taking a really long time. After digging, I finally understood why: each time you add or remove an entry in a group, it rewrites the complete group entry (at least with the BDB backend), rewritting 100000 entries each time you update one is somewhat costly... Not sure if it's still the case with the lmdb backend however. * The source code is not really easy to read in my opinion. I did try it once (debugging the issue mentioned above), but was not successful at roughly understanding how it worked from reading the source code, at least in the few hours I devoted to it (I know, it's not necessarily a lot). * Usually, with replication, schema tweaking, backups, monitoring and some testing, deploying OpenLDAP can easily be a one or two months project. * deploying all the integrations correctly is also quite hard (ldap auth for ssh or web authentication on each web applications), That being said, 389 Directory/RedHat Directory Server is not much better, the setup is done through a weird perl script. Setup ssl/tls is a pain (I learn to hate certutil, and its certs/ca/private keys in DBs, deploying flat pem files is so much easier and convenient). The "rich" client looks like it has not changed in years (or removed all together), and it looks so much like the Old Sun One I'm wondering if it has changed since the Netscape days apart from code maintenance. Also, I'm not sure if it's still the case, but IIRC RDS is a separate subscription from RedHat, it doesn't come with a basic RHEL OS subscription (I recall having to recompile the srpm my self when 6.0 went out). RHEL was also not a really great maintainer of their OpenLDAP packages, I remember for example a breaking change because they went from 2.4.38 to 2.4.41 (I'm expecting a stable distro like RHEL to not introduce breaking changes, and to not update software like a rolling release, Debian does a far better job at it for example). After all this 'praise' of the ldap world, you must think I actually hate it. No, I actually kind of like it (to the point of maintaining an ldap web UI). Having a centralized user DB makes things so much easier for everybody, the user only has one password, the security officer can trustfully enable/disable accesses, the sysadmin as one source of truth. If you maintain local accounts for each of your applications you are in for a lot of troubles down the line. It's also an authentication method that is widely supported by most applications, and if it's not, there is probably a ticket/PR/patch somewhere to add it. Lastly once it's setup and configured, it's generally quite reliable even with complex replication setups, this makes it relatively low maintenance. And at least for reads, it has quite good performances. OpenLdap: I love to hate you, but I love you.

jakobdabo 8y ago

There is an interesting fork of OpenLDAP called ReOpenLDAP - https://github.com/leo-yuriev/ReOpenLDAP https://github.com/leo-yuriev/ReOpenLDAP

nineteen999 8y ago

As a long time OpenLDAP user (ie. probably going on 20+ years at this point), and as somebody who will be rolling out LDAP again on a long-term project on RHEL 7.5 shortly I have a few questions about 389DS. I've considered migrating to it for this project, but I just have too many open questions regarding setting it up right now. 1) I need support for both RFC2307 and RFC2307bis. I haven't found any good documentation on how to set these up from scratch with 389DS where it's fairly trivial to make them work together with OpenLDAP and the memberof overlay. 2) I also have a need for an equivalent of the Tacacs schema that works with the mavis-Tacacs fork that Google maintains. Will this schema work with 389DS? 3) Same goes for the sudo.schema that is provided with sudo - does this work with 389DS? 4) Same goes for the ppolicy.schema (password policy) schema (ppolicy overlay) and memberof overlay. What are the equivalents of these for 389DS? 5) multi-master replication - OpenLDAP makes this a breeze, but not so sure with 389DS. Finding information about how to implement these things from scratch seems extremely hard for 389DS. Granted, it was also hard for OpenLDAP, but that work is behind me now. I have serious misgivings about trying to reimplement all of this on 389DS within my given timeframe. Other things that irk me about this decision: a) I really dislike the Java console - doesn't feel like it changed much since the 1990's. It's still slow, ugly and doesn't feel like it integrates well. b) feels like a weird choice to drop the openldap-server packages but not the openldap-clients package. Are they going to provide a replacement for the OpenLDAP client libraries eventually as well? Is there even a good alternative (ie. API compatible and replacements for all the command line utilities) to openldap-clients? While it seems like an easy decision to move on the surface, most OpenLDAP deployments have a massive amount of customisations to make all the third-party applications work, and 389DS making those kind of migrations easy doesn't currently seem like one of its strong selling points.

hyc_symas 8y ago
>b) feels like a weird choice to drop the openldap-server packages but not the openldap-clients package. Are they going to provide a replacement for the OpenLDAP client libraries eventually as well? Is there even a good alternative (ie. API compatible and replacements for all the command line utilities) to openldap-clients? They have no choice here, they use OpenLDAP's libraries. Mozilla/Netscape's own LDAP SDK has been unmaintained for more than a decade; it's abandonware.

h1d 8y ago

I'm in a small (< 10 users) shop having OpenLDAP to store users that integrates with Apache authentication, postfix/dovecot authentication and manages users with (patched) phpLdapAdmin but hearing that OpenLDAP may not have a bright future, what should I replace it with for central user management for Linux?

reqa 8y ago
OpenLDAP will not go away, see https://lwn.net/Articles/755207/ https://lwn.net/Articles/755207/ for a current road map. Only RedHat doesn't support it any longer, that's all, no worries.
- h1d 8y ago
  Seeing how I need a patched version of phpLdapAdmin maintained by a third party instead of the one provided by Ubuntu 18.04 and a lack of easy to use GUI app for LDAP administration, let alone any third party client interface for users to login and change their password, I'm starting to think no one likes LDAP and should move over, perhaps even to MySQL as user management database.