3 ms·

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 de

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.)
  - Karunamon 10y ago
    Thanks for the details. Regarding insecurity: I don't give much credence to a "history of serious problems". Any (and I do mean any) application which deals with arbitrary input and data types has had a history of particularly nasty security holes. You'd eliminate every major web browser here too. I see a large number of CVEs as a good thing, as that means there are eyes on the code and the exploits are getting found and fixed. The alternative is worse; it means there are bugs and they aren't being found. Survivor bias :) Regarding complexity: Security/authentication tools are complex, and they kind of have to be given the number of requirements, ciphers, data types, etc. There is no solution to this problem. Regarding attack targeting: Any repository used for authentication will be a DoS/hacking target. Again, it's nature of the beast, it's a high value target and always will be. Regarding SSO/SAML/oauth: Those have to authenticate against something, yes? What is that "something" in this case that makes it a true alternative?
teacup50 10y ago
LDAP/AD is neither insecure nor obsolete. Using a 3rd-party cloud-based service to manage server authentication, SSH keys, et al, seems insanely insecure however -- especially when your alternative is simply running LDAP locally.
- jamiesonbecker 10y ago
  0. I believe that both LDAP and AD have complex models (well, arguably less complex than Vines/NDS/x.500/etc if you go back that far) and they're certainly more secure than NIS/NIS+ based on historical vulns, but I find it hard to argue that they're 'secure' based on their long and sordid history of vulns ( https://www.cvedetails.com/vulnerability-list/vendor_id-439/Openldap.html https://www.cvedetails.com/vulnerability-list/vendor_id-439/... ) 0a. and, well, I wouldn't want to connect boxes to LDAP because I prefer to log into my boxes, even when LDAP is unavailable, the VPN is down, etc. but, nscd et al.. caching doesn't work either on an autoscaled box in the cloud, nor would I want to expose my enterprise directory infrastructure to my VPC. I also don't want to introduce a new PAM and NSS configuration on every single box (with separate layering for different boxes into different projects etc) and introduce yet another avenue for mistakes and compromise... was that required, requisite, or optional? Ergo, obsolete. :) (imo) 1. (btw, We don't do server authentication. That is a key difference between a directory and Userify. We only distribute keys. The servers themselves authenticate their own users with Userify just like with the traditional model, whereas with a directory the LDAP/AD server itself performs every authentication.) 2. We also recommend purchasing and running Userify Enterprise locked down locally to your VPC/LAN, and our larger customers tend to prefer that as well (especially when connected to LDAP w/ the same disconnected model we designed into our core product). We also offer a free cloud-based edition for unlimited use because we're nice like that. 3. We're paranoid, just like you: we go through bi-monthly independent penetration tests, we encrypt all data w/ NaCl, we avoid using passwords where possible and has with bcrypt elsewhere, and we're hardened against XSS, CSRF, and any sort of injection. The shim source is available here: https://github.com/userify/shim https://github.com/userify/shim (see https://userify.com/faq/ https://userify.com/faq/ for more on the security stuff we do and we're open to more ideas) and, please, find our vulnerabilities. We'll pay you for them. https://support.userify.com/solution/articles/14000036246-find-our-vulns https://support.userify.com/solution/articles/14000036246-fi... Sometimes even our larger partners don't do that unfortunately.. ( https://github.com/aws/aws-codedeploy-agent/issues/30 https://github.com/aws/aws-codedeploy-agent/issues/30 ) But, seriously, people who are happy with their current solution should probably stick with it. I don't expect to convince you to take another look, and I do agree that there are good arguments to be made that LDAP/AD is neither insecure nor obsolete. I just disagree with (most of) those arguments. ;) note: AD/LDAP connectivity in Userify: you can still authenticate natively via LDAP/AD, while Userify provides a user-friendly dashboard for key management for your teams. A particularly cool demo: remove or disable an account in Windows AD and seconds later watch all of the SSH sessions on all of the servers in all of the projects terminate. It's very slick.. and that's another thing that LDAP/AD directory authenticated solutions can't do.

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.)
- Karunamon 10y ago
  Thanks for the details. Regarding insecurity: I don't give much credence to a "history of serious problems". Any (and I do mean any) application which deals with arbitrary input and data types has had a history of particularly nasty security holes. You'd eliminate every major web browser here too. I see a large number of CVEs as a good thing, as that means there are eyes on the code and the exploits are getting found and fixed. The alternative is worse; it means there are bugs and they aren't being found. Survivor bias :) Regarding complexity: Security/authentication tools are complex, and they kind of have to be given the number of requirements, ciphers, data types, etc. There is no solution to this problem. Regarding attack targeting: Any repository used for authentication will be a DoS/hacking target. Again, it's nature of the beast, it's a high value target and always will be. Regarding SSO/SAML/oauth: Those have to authenticate against something, yes? What is that "something" in this case that makes it a true alternative?

teacup50 10y ago

LDAP/AD is neither insecure nor obsolete. Using a 3rd-party cloud-based service to manage server authentication, SSH keys, et al, seems insanely insecure however -- especially when your alternative is simply running LDAP locally.

jamiesonbecker 10y ago
0. I believe that both LDAP and AD have complex models (well, arguably less complex than Vines/NDS/x.500/etc if you go back that far) and they're certainly more secure than NIS/NIS+ based on historical vulns, but I find it hard to argue that they're 'secure' based on their long and sordid history of vulns ( https://www.cvedetails.com/vulnerability-list/vendor_id-439/Openldap.html https://www.cvedetails.com/vulnerability-list/vendor_id-439/... ) 0a. and, well, I wouldn't want to connect boxes to LDAP because I prefer to log into my boxes, even when LDAP is unavailable, the VPN is down, etc. but, nscd et al.. caching doesn't work either on an autoscaled box in the cloud, nor would I want to expose my enterprise directory infrastructure to my VPC. I also don't want to introduce a new PAM and NSS configuration on every single box (with separate layering for different boxes into different projects etc) and introduce yet another avenue for mistakes and compromise... was that required, requisite, or optional? Ergo, obsolete. :) (imo) 1. (btw, We don't do server authentication. That is a key difference between a directory and Userify. We only distribute keys. The servers themselves authenticate their own users with Userify just like with the traditional model, whereas with a directory the LDAP/AD server itself performs every authentication.) 2. We also recommend purchasing and running Userify Enterprise locked down locally to your VPC/LAN, and our larger customers tend to prefer that as well (especially when connected to LDAP w/ the same disconnected model we designed into our core product). We also offer a free cloud-based edition for unlimited use because we're nice like that. 3. We're paranoid, just like you: we go through bi-monthly independent penetration tests, we encrypt all data w/ NaCl, we avoid using passwords where possible and has with bcrypt elsewhere, and we're hardened against XSS, CSRF, and any sort of injection. The shim source is available here: https://github.com/userify/shim https://github.com/userify/shim (see https://userify.com/faq/ https://userify.com/faq/ for more on the security stuff we do and we're open to more ideas) and, please, find our vulnerabilities. We'll pay you for them. https://support.userify.com/solution/articles/14000036246-find-our-vulns https://support.userify.com/solution/articles/14000036246-fi... Sometimes even our larger partners don't do that unfortunately.. ( https://github.com/aws/aws-codedeploy-agent/issues/30 https://github.com/aws/aws-codedeploy-agent/issues/30 ) But, seriously, people who are happy with their current solution should probably stick with it. I don't expect to convince you to take another look, and I do agree that there are good arguments to be made that LDAP/AD is neither insecure nor obsolete. I just disagree with (most of) those arguments. ;) note: AD/LDAP connectivity in Userify: you can still authenticate natively via LDAP/AD, while Userify provides a user-friendly dashboard for key management for your teams. A particularly cool demo: remove or disable an account in Windows AD and seconds later watch all of the SSH sessions on all of the servers in all of the projects terminate. It's very slick.. and that's another thing that LDAP/AD directory authenticated solutions can't do.