Hey, thanks for the time and effort you put into this, much appreciated! Although I only have worked with OpenLDAP briefly (mainly just fiddling around for university purposes), I'll just throw my feedback/ideas/questions into here. Please correct me if I misunterstood something :) On 05.03.18 - 17:12, Giancarlo Razzolini via arch-devops wrote:
1) OpenLDAP Cons: It doesn't have any GUI tool for management and needs external projects (like phpldapadmin) to do so. Adding users sometimes requires messing with LDIF's and others.
During my brief contact with OpenLDAP I was really annoyed by that LDIF stuff. The learning curve for this is rather steep and when you've never done anything with it before it can get really frustrating. This makes it more difficult to distribute the responsibilities / knowledge of our future LDAP setup. We most likely do not want to have only a single person capable of maintaining it.
2) 389-ds Cons: We don't package it currently and it's somewhat more intensive on resource usage than OpenLDAP.
From what I've heard (never used it myself) 389-ds seems to be more straightforward to setup and use. Do you have some actual numbers for the difference in resource usage?
3) FreeIPA Cons: It is complex and has a lot of stuff that's not required for our use case. Also does not have an official package, and doesn't have a server package on the AUR either.
Fully agree with you here, way too complex and it comes with many additional services that we do not need. KISS!
4) Samba 4 Cons: It is more meant for AD integration and I think we can assume there won't be any possibility of that happening in the near future.
Same here, it doesn't realy fit our use case. Regarding (G)UIs for the LDAP servers: I would strongly advise against phpLDAPadmin, it is cumbersome and the last stable release was over 5 years ago. It would be great to have some kind of CLI/TUI locally on the server which could be used through SSH. In case our DS software choice does not come with that, there is always Apache Directory Studio (aur/apachedirectorystudio). It is also not really *great* but most of the time it just works. This could be used through an SSH port tunnel without the need to expose the LDAP(s) port publicly.
Having discussed DS software options, I want to discuss regarding the topology. [...] I would say for us to set a master and each machine having its own slave server running. TLS should be used everywhere, but I don't think we need to set TLS client authentication, at least, not for now (see below).
I support the idea of each machine/server having a local (replicated) slave running. This distributes the load more or less evenly across the servers, has shorter delays and doesn't require a remote service to be online/available. However: When the slaves are used locally for the services (aur, wiki, archweb, ...), we do need to provide a way for the users to change their password (among other account settings) which uses the master backend as the slaves won't be able to change any data. Having only one master means that changes to the LDAP data are not possible while the master is down. I would strongly recommend to run at least two masters if that is possible without severe drawbacks or heavily increased complexity. Regarding TLS: Using TLS for the replication traffic between the servers is an absolute must-have, I fully agree with this. We should also restrict access to the LDAP(s) port through iptables to our own services which should only allow replication traffic. However, having seen live how broken some TLS/x509 implementations are (e.g. MySQL) I would opt for a VPN between our servers using tinc for example. The VPN network across the servers can still be firewalled and it enforces all traffic between the servers to be encrypted. That's all what I've got so far. Cheers, Thore --