[teacup50]

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]

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

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 (see 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-fi... Sometimes even our larger partners don't do that unfortunately.. ( 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.

[vidarh]

> but I find it hard to argue that they're 'secure' based on their long and sordid history of vulns

The big difference here is that vs. a third party setup, my LDAP setup is running entirely behind our firewalls and not reachable from outside a suitably encrypted VPN. It's certainly possible to do stupid stuff with it.

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

This is only an issue if you don't ensure you have at least one account that is present locally on the box that you can authenticate against.

With what I suggested - LDAP for user info, OpenSSH certificates for authentication and authorisation, any user that can be looked up locally on the box can be logged into (with the caveat that you then need to explicitly revoke keys for those users) even when LDAP is down, giving you an easy out.

But making LDAP quite resilient to outages is easy, by replicating it and specifying more than one server to connect to. For that matter, slapd is lightweight enough that you could run replicas on most servers if this is actually a problem (it's never been for me).

> nor would I want to expose my enterprise directory infrastructure to my VPC.

Why would you need to? Filtering what you replicate is easy enough.

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

This is only true if you want it to be. It is not true if you use OpenSSH certificates for the authentication.

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

That's got nothing to do with LDAP, and everything to do whether a specific application supports periodically checking whether or not a user or key is still authorised, or not. LDAP is just a replicated data store.

Some applications do, some don't. For my part it's not generally an issue because their VPN key will get revoked and will immediately stop working, at which point all other connections will fail and time out whether or not individual applications pick up that the keys have been revoked and the user removed.

If you insist on doing this at the level of individual ssh connections, it's not particularly hard to force connections through a command that will periodically check that the key is still authorised.

I don't doubt that you have a slick solution, and I'm sure it'll be great for some. I don't particularly like LDAP. But for me at least, trusting this to a third party - even though it sounds like you're doing a lot of things the right way - is something I'd be extremely reluctant to, while LDAP is proven and despite various warts and problems, it's well understood and well supported by most applications we use.