4 ms·

The point of this is that OpenLDAP, while an ok solution which has stood the test of time, isn't well integrated with anything a systems vendor would want to do

The point of this is that OpenLDAP, while an ok solution which has stood the test of time, isn't well integrated with anything a systems vendor would want to do with it. Getting it working with Kerberos or anything else to make it a reasonable alternative to AD is 100 miles of duct tape and random LDIFs. 389 doesn't have any of those problems. Yes, you can argue that Red Hat/SuSE should/could have simply contributed to OpenLDAP, but it hasn't seen a major release in a decade, and there was an incredible amount of friction in trying to contribute anything large.

hyc_symas 8y ago
> Getting it working with Kerberos or anything else to make it a reasonable alternative to AD is 100 miles of duct tape and random LDIFs. That's nonsense. OpenLDAP has had seamless integration with Heimdal Kerberos for literally decades. And the support for running a KDC on top of LDAP was written by OpenLDAP contributors (Luke Howard and myself). https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-ldap.c https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-l... as an aside, I also wrote the support for using the KDC on top of LMDB https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-mdb.c https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-m... As for duct tape and random LDIFs - again, Symas Corp and the OpenLDAP Project were the only guys funding efforts to standardize this integration. http://kerberos.996246.n3.nabble.com/Ietf-krb-wg-LDAP-schema-for-kdc-td34649.html http://kerberos.996246.n3.nabble.com/Ietf-krb-wg-LDAP-schema... https://datatracker.ietf.org/doc/draft-chu-ldap-kdc-schema/ https://datatracker.ietf.org/doc/draft-chu-ldap-kdc-schema/ The fact that Kerberos works well on top of LDAP today is because the OpenLDAP Project laid the groundwork for that to happen. > Yes, you can argue that Red Hat/SuSE should/could have simply contributed to OpenLDAP, but it hasn't seen a major release in a decade, and there was an incredible amount of friction in trying to contribute anything large. RedHat has never tried to contribute anything large to OpenLDAP. And large contributions aren't a problem. We have entirely new DB backends still being contributed by 3rd parties. E.g. the WiredTiger backend http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;f=servers/slapd/back-wt;h=5ad3be00bfb1e8beea31e213d8159361e050ec00;hb=HEAD http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tr...
briffle 8y ago
I had nothing but pain with openLDAP. Every guide I could find trying to learn gave examples using the 'old config format' even though the newer db config format had been around for many, many years at that time.
- hyc_symas 8y ago
  This comment is nonsense. The OpenLDAP Project isn't responsible for 3rd parties not updating their guides. Use the official documentation if you want docs that are up to date.
- ti_ranger 8y ago
  > I had nothing but pain with openLDAP. Every guide I could find trying to learn gave examples using the 'old config format' even though the newer db config format had been around for many, many years at that time. This is a poor excuse. While the flat file (slapd.conf) is deprecated in 2.4, it still works fine if you don't mind restarting to apply changes, and you can easily switch from slapd.conf to back-config (but not the other way) when you are finished getting a new stack up.
  - ansible 8y ago
    > This is a poor excuse. I encourage you to look at things from the perspective of someone new to LDAP, or maybe someone new to directory services in general. LDAP already introduces its own terminology which is a little confusing at first. And it is an object database, which will be less familiar to many people than a relational database. Add to that the 'database number' thing when it might not be clear to beginners what is going into which one and why.
    - philjohn 8y ago
      If you're totally new to LDAP (which despite being "just an object database" has many bells and whistles to fit into various deployments) there is always going to be a little friction at first - there's a reason people make good money offering consultancy and support for LDAP servers. It's not something you're going to be able to get setup and running in an afternoon, and that's fine, some things are too complex to just be thrown together.

hyc_symas 8y ago

> Getting it working with Kerberos or anything else to make it a reasonable alternative to AD is 100 miles of duct tape and random LDIFs. That's nonsense. OpenLDAP has had seamless integration with Heimdal Kerberos for literally decades. And the support for running a KDC on top of LDAP was written by OpenLDAP contributors (Luke Howard and myself). https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-ldap.c https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-l... as an aside, I also wrote the support for using the KDC on top of LMDB https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-mdb.c https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb-m... As for duct tape and random LDIFs - again, Symas Corp and the OpenLDAP Project were the only guys funding efforts to standardize this integration. http://kerberos.996246.n3.nabble.com/Ietf-krb-wg-LDAP-schema-for-kdc-td34649.html http://kerberos.996246.n3.nabble.com/Ietf-krb-wg-LDAP-schema... https://datatracker.ietf.org/doc/draft-chu-ldap-kdc-schema/ https://datatracker.ietf.org/doc/draft-chu-ldap-kdc-schema/ The fact that Kerberos works well on top of LDAP today is because the OpenLDAP Project laid the groundwork for that to happen. > Yes, you can argue that Red Hat/SuSE should/could have simply contributed to OpenLDAP, but it hasn't seen a major release in a decade, and there was an incredible amount of friction in trying to contribute anything large. RedHat has never tried to contribute anything large to OpenLDAP. And large contributions aren't a problem. We have entirely new DB backends still being contributed by 3rd parties. E.g. the WiredTiger backend http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;f=servers/slapd/back-wt;h=5ad3be00bfb1e8beea31e213d8159361e050ec00;hb=HEAD http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tr...

briffle 8y ago

I had nothing but pain with openLDAP. Every guide I could find trying to learn gave examples using the 'old config format' even though the newer db config format had been around for many, many years at that time.

hyc_symas 8y ago
This comment is nonsense. The OpenLDAP Project isn't responsible for 3rd parties not updating their guides. Use the official documentation if you want docs that are up to date.
ti_ranger 8y ago
> I had nothing but pain with openLDAP. Every guide I could find trying to learn gave examples using the 'old config format' even though the newer db config format had been around for many, many years at that time. This is a poor excuse. While the flat file (slapd.conf) is deprecated in 2.4, it still works fine if you don't mind restarting to apply changes, and you can easily switch from slapd.conf to back-config (but not the other way) when you are finished getting a new stack up.
- ansible 8y ago
  > This is a poor excuse. I encourage you to look at things from the perspective of someone new to LDAP, or maybe someone new to directory services in general. LDAP already introduces its own terminology which is a little confusing at first. And it is an object database, which will be less familiar to many people than a relational database. Add to that the 'database number' thing when it might not be clear to beginners what is going into which one and why.
  - philjohn 8y ago
    If you're totally new to LDAP (which despite being "just an object database" has many bells and whistles to fit into various deployments) there is always going to be a little friction at first - there's a reason people make good money offering consultancy and support for LDAP servers. It's not something you're going to be able to get setup and running in an afternoon, and that's fine, some things are too complex to just be thrown together.