4 ms·

Could you expand on this? > LDAP management on non-Windows systems is like stepping back 30 years. How so? And managing which components -- the directory serv

by jms18 10y ago

Could you expand on this? > LDAP management on non-Windows systems is like stepping back 30 years. How so? And managing which components -- the directory server or the clients? > there wasn't even a supported UI for directory operations What directory operations? add/mod/del? There are quite a few packages that handle that. Or are you talking about operations on the server side? > typing DN's by hand is for the birds! I concur. Though, it's pretty rare to type in a DN anywhere. I can't think of many places where a simple RDN or search filter on a unique value (uid, mail, etc.) doesn't suffice.

Karunamon 10y ago
Both. Again, I may be coming from a standpoint of ignorance here, but setting up a Linux client requires manual mucking about with PAM and its associated config files, with different steps required for every major distro. Same with the server side - there's no good equivalent to the Windows' "Active Directory Users & Computers". Plenty of good command line tools, but I don't think those are that useful when reasoning about a "tree" structure used in LDAP.
- teacup50 10y ago
  We got hosed by PADL and rfc2307/rfc2307bis. In short: We never standardized a viable schema that covered the majority of real-world enterprise use-cases. Active Directory did. We got stuck with the broken rfc2307 (essentially NIS-in-LDAP), and the slightly better but abandoned rfc2307bis. Without a standardized schema, every management tool out there had to either expose LDAP directly, or provide a limited subset of operations supportable across random schema. We could solve this issue with a new RFC defining a modern standard server schema, including things like sshPublicKey, but I don't know if there's any UNIX/Linux vendor still alive that would invest in doing so.
- vidarh 10y ago
  I've never managed an LDAP server from the command line on Linux. As for PAM, I did a PAM LDAP config once about 8 years ago, and have never needed to make a change since. Since then it's been a matter of a few config files that are part of the standard config we deploy automatically to new systems. It's not exactly particularly much effort.
jamiesonbecker 10y ago
We actually offer a pretty robust LDAP/AD integration on Userify, but I still recommend against it, especially since it's not just painful but adding LDAP/AD decreases overall security. I used to like LDAP in the early 00's, but now I just think it's anything but lightweight.. as well as insecure and obsolete.
- Karunamon 10y ago
  Could you elaborate a bit? I've heard many criticisms leveled at LDAP over the years, but never that it's insecure or obsolete.
  - jamiesonbecker 10y ago
    Thank you for your civility :). The word 'secure' is subjective and thus always a matter of opinion (since obviously nothing is truly secure). LDAP is insecure: it has a long history of serious problems. (for example, https://www.cvedetails.com/vulnerability-list/vendor_id-439/Openldap.html https://www.cvedetails.com/vulnerability-list/vendor_id-439/... ) (389ds and IPA are all based on the slapd OpenLDAP code.) 0) it's enormous: both as an implemented application and as a protocol and specification. Complexity is the enemy of security. 1) it widens your network footprint and isn't hardened against modern attacks (all LDAP directories that I'm aware of also have a regrettable history a la bugtraq/cert). (even without bringing krb5 into the picture) 2) it is complex and allows schema/ACL changes to expose attributes in non-obvious ways 3) no commercially available LDAP implementation natively encrypts all data 4) ouch, LDAP injection (https://www.owasp.org/index.php/LDAP_injection https://www.owasp.org/index.php/LDAP_injection) 5) A centrally managed directory represents a very rich target for the secrets it contains 6) particularly when used as an authentication backend, it also presents a nice DoS target. (I have personal experience from a previous life..) :( 7) An LDAP server exposed to a LAN is rapidly (today) approaching being exposed to the Internet as VPN connections join multiple clouds and formerly internal datacenters, for anything but the tiniest of network footprints. 8) Most of the interlocking services, such as KRB5, have a sordid history of really bad root-level vulns.(https://www.cvedetails.com/vulnerability-list/vendor_id-42/product_id-61/MIT-Kerberos.html https://www.cvedetails.com/vulnerability-list/vendor_id-42/p...) Obviously many of these concerns can be somewhat mitigated but my strong personal opinion is that the size and complexity of LDAP makes it its own worst enemy. With that said, there's no real replacement for it, right? With regards to things like SSO and SAML2, oauth (which also has its own share of problems due to the same problems of size and complexity) is beginning to make the need for an enterprise-wide directory moot, but this will obviously take time. Not to mention - implementation to integrate with something like FreeIPA or similar is just unmitigated pain, both up front (i.e., if you want to run it somewhere like AWS without control over reverse DNS) or on each node (I've written PAM modules before and I still think making PAM changes is a big pain and not without significant risk.)

by jms18 10y ago

Karunamon 10y ago

Both. Again, I may be coming from a standpoint of ignorance here, but setting up a Linux client requires manual mucking about with PAM and its associated config files, with different steps required for every major distro. Same with the server side - there's no good equivalent to the Windows' "Active Directory Users & Computers". Plenty of good command line tools, but I don't think those are that useful when reasoning about a "tree" structure used in LDAP.

teacup50 10y ago
We got hosed by PADL and rfc2307/rfc2307bis. In short: We never standardized a viable schema that covered the majority of real-world enterprise use-cases. Active Directory did. We got stuck with the broken rfc2307 (essentially NIS-in-LDAP), and the slightly better but abandoned rfc2307bis. Without a standardized schema, every management tool out there had to either expose LDAP directly, or provide a limited subset of operations supportable across random schema. We could solve this issue with a new RFC defining a modern standard server schema, including things like sshPublicKey, but I don't know if there's any UNIX/Linux vendor still alive that would invest in doing so.
vidarh 10y ago
I've never managed an LDAP server from the command line on Linux. As for PAM, I did a PAM LDAP config once about 8 years ago, and have never needed to make a change since. Since then it's been a matter of a few config files that are part of the standard config we deploy automatically to new systems. It's not exactly particularly much effort.

jamiesonbecker 10y ago

We actually offer a pretty robust LDAP/AD integration on Userify, but I still recommend against it, especially since it's not just painful but adding LDAP/AD decreases overall security. I used to like LDAP in the early 00's, but now I just think it's anything but lightweight.. as well as insecure and obsolete.

Karunamon 10y ago
Could you elaborate a bit? I've heard many criticisms leveled at LDAP over the years, but never that it's insecure or obsolete.
- jamiesonbecker 10y ago
  Thank you for your civility :). The word 'secure' is subjective and thus always a matter of opinion (since obviously nothing is truly secure). LDAP is insecure: it has a long history of serious problems. (for example, https://www.cvedetails.com/vulnerability-list/vendor_id-439/Openldap.html https://www.cvedetails.com/vulnerability-list/vendor_id-439/... ) (389ds and IPA are all based on the slapd OpenLDAP code.) 0) it's enormous: both as an implemented application and as a protocol and specification. Complexity is the enemy of security. 1) it widens your network footprint and isn't hardened against modern attacks (all LDAP directories that I'm aware of also have a regrettable history a la bugtraq/cert). (even without bringing krb5 into the picture) 2) it is complex and allows schema/ACL changes to expose attributes in non-obvious ways 3) no commercially available LDAP implementation natively encrypts all data 4) ouch, LDAP injection (https://www.owasp.org/index.php/LDAP_injection https://www.owasp.org/index.php/LDAP_injection) 5) A centrally managed directory represents a very rich target for the secrets it contains 6) particularly when used as an authentication backend, it also presents a nice DoS target. (I have personal experience from a previous life..) :( 7) An LDAP server exposed to a LAN is rapidly (today) approaching being exposed to the Internet as VPN connections join multiple clouds and formerly internal datacenters, for anything but the tiniest of network footprints. 8) Most of the interlocking services, such as KRB5, have a sordid history of really bad root-level vulns.(https://www.cvedetails.com/vulnerability-list/vendor_id-42/product_id-61/MIT-Kerberos.html https://www.cvedetails.com/vulnerability-list/vendor_id-42/p...) Obviously many of these concerns can be somewhat mitigated but my strong personal opinion is that the size and complexity of LDAP makes it its own worst enemy. With that said, there's no real replacement for it, right? With regards to things like SSO and SAML2, oauth (which also has its own share of problems due to the same problems of size and complexity) is beginning to make the need for an enterprise-wide directory moot, but this will obviously take time. Not to mention - implementation to integrate with something like FreeIPA or similar is just unmitigated pain, both up front (i.e., if you want to run it somewhere like AWS without control over reverse DNS) or on each node (I've written PAM modules before and I still think making PAM changes is a big pain and not without significant risk.)