[arch-devops] LDAP role
Hi Guys, Now that the wiki was migrated, I'm starting to work on the LDAP role. But, since this will certainly be a complex role and it will involve a lot of other roles/applications, I want to discuss with you some of the approaches we can take. First of all, we need to choose on the Directory Service application that we are going to use: 1) OpenLDAP [0]: It's the established open source directory server and the basis for many others. We have it on [core]. It does support having more than one server, either in master-slave or multi-master (I'll talk more about topology below). Pros: Being the "de facto" implementation and well know. It's relatively easy to setup and has multiple options for topology. 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. 2) 389-ds (formerly fedora ds) [1]: It's the second contender here. I have personally used it extensively in the past, so I might be biased towards it. It does not have an official package, but there is one on the AUR [2]. Pros: It is very easy to setup and comes up the console tool for management which is a java GUI. Also has a great multi-master replication support. Cons: We don't package it currently and it's somewhat more intensive on resource usage than OpenLDAP. 3) FreeIPA [3]: It is basically a bundle of a lot of software that is complimentary to a DS but not always required, like DNS, NTP server, Kerberos and PKI. It's DS part is provided by 389-ds. Pros: Easier to setup than OpenLDAP, has a nice web management tool and comes with a lot of pre-configured stuff. 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. 4) Samba 4 [4]: Since Samba 4, you can create one DS quite easily, there's even a wizard for it. It uses OpenLDAP, bind and some other bundled stuff behind the scenes, just like FreeIPA does. Pros: It is quite easy to setup and we have it packaged. 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. There are some other options, but they are either outdated or do not provide everything we need. Having discussed DS software options, I want to discuss regarding the topology. The idea is to eventually bring all the applications and systems authenticating to this DS. In order for us to do that, more than one will be required to handle the load. We have the master-slave relationship or the multi-master one. There are arguments pro and con to both, but I like the description that the OpenLDAP documentation gives [5]. 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). We have to define if we are going to use the plain internet for this or some private network. I'm bringing this up right now, because we need to decide if we are going to allow anonymous connections to the DS (I'm against it) to query for users or not. Basically if we are going to allow anyone to query it or not. If not, then we need to use SASL or other mechanism for authenticating the clients, which compounds on the complexity. There's also the possibility of limiting the fields that anonymous clients can query, as well as the number of queries/responses. This would be similar to the AUR TOS case, but for everything, so it should be discussed upfront. I'm eager to hear your replies and whatever we decide here we should bring to adp for further enhancements. I don't want to turn this into a bikeshed discussion, though. So, keep your ideas within the limits of what was presented. Regards, Giancarlo Razzolini [0] https://www.openldap.org/ [1] http://directory.fedoraproject.org/ [2] https://aur.archlinux.org/packages/389-ds-base/ [3] https://www.freeipa.org/page/Main_Page [4] https://www.samba.org/ [5] http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master%20...
On 03/05/18 at 05:12pm, Giancarlo Razzolini via arch-devops wrote:
Hi Guys,
Now that the wiki was migrated, I'm starting to work on the LDAP role. But, since this will certainly be a complex role and it will involve a lot of other roles/applications, I want to discuss with you some of the approaches we can take.
First of all, we need to choose on the Directory Service application that we are going to use:
1) OpenLDAP [0]: It's the established open source directory server and the basis for many others. We have it on [core]. It does support having more than one server, either in master-slave or multi-master (I'll talk more about topology below).
Pros: Being the "de facto" implementation and well know. It's relatively easy to setup and has multiple options for topology. 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.
2) 389-ds (formerly fedora ds) [1]: It's the second contender here. I have personally used it extensively in the past, so I might be biased towards it. It does not have an official package, but there is one on the AUR [2].
Pros: It is very easy to setup and comes up the console tool for management which is a java GUI. Also has a great multi-master replication support. Cons: We don't package it currently and it's somewhat more intensive on resource usage than OpenLDAP.
3) FreeIPA [3]: It is basically a bundle of a lot of software that is complimentary to a DS but not always required, like DNS, NTP server, Kerberos and PKI. It's DS part is provided by 389-ds.
Pros: Easier to setup than OpenLDAP, has a nice web management tool and comes with a lot of pre-configured stuff. 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.
4) Samba 4 [4]: Since Samba 4, you can create one DS quite easily, there's even a wizard for it. It uses OpenLDAP, bind and some other bundled stuff behind the scenes, just like FreeIPA does.
Pros: It is quite easy to setup and we have it packaged. 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.
Thanks for the list, I've only worked with OpenLDAP on an amateur level :-) I'm eager to also see a list of how easy it would be to integrate either of these options with our application stack, as in what do we want to move to LDAP? * archweb * bbs * bugtracker * aurweb * ssh auth? * kanban board? -- Jelle van der Waa
On 06.03.2018 10:58, Jelle van der Waa wrote:
I'm eager to also see a list of how easy it would be to integrate either of these options with our application stack, as in what do we want to move to LDAP?
* archweb * bbs * bugtracker * aurweb * ssh auth? * kanban board?
Eventually I'd like to have all of these (+ wiki if possible) in LDAP so that when someone becomes a TU/dev we can just change the group setting in LDAP and everything else adjusts automatically. Ideally, when someone joins the team they already have an account there and things like SSH and GPG keys are already configured because the AUR requires them. We then just change the group and be done with it. For now I'd start with, in that order, ssh, kanboard (only a few users so far so it should be easy to migrate), archweb. Later we can work on getting the other services migrated, but there we'll have to come up with a way to resolve conflicts regarding usernames so this requires some more effort. About the rest: 389ds and VPN sound good. Also I'd still use TLS even on a VPN so that we have multiple layers of security. I've once had a DNS problem with my personal syslog server, but thanks to TLS (with a private CA) there were no connections to the wrong machine. I imagine that we'll use DNS for easier management even if we use private IPs so this also applies here. It will probably be /etc/hosts, but there can still be a mistake at some point. Regarding topology I'd like master-master if that works well, otherwise master-slave. How does 389ds resolve conflicts in a master-master setup and what's the performance like? Florian
Em março 6, 2018 8:18 Florian Pritz via arch-devops escreveu:
Eventually I'd like to have all of these (+ wiki if possible) in LDAP so that when someone becomes a TU/dev we can just change the group setting in LDAP and everything else adjusts automatically. Ideally, when someone joins the team they already have an account there and things like SSH and GPG keys are already configured because the AUR requires them. We then just change the group and be done with it.
We can have the SSH and GPG keys on the directory itself, yes, and that's accessible by any application.
For now I'd start with, in that order, ssh, kanboard (only a few users so far so it should be easy to migrate), archweb. Later we can work on getting the other services migrated, but there we'll have to come up with a way to resolve conflicts regarding usernames so this requires some more effort.
I would say, as name conflicts goes, we look at our application where we have the biggest number of users. And we determine that as the authoritative source for usernames. Anyone with a username conflicting against that, will need to change. I think the AUR is that application, right?
About the rest: 389ds and VPN sound good. Also I'd still use TLS even on a VPN so that we have multiple layers of security. I've once had a DNS problem with my personal syslog server, but thanks to TLS (with a private CA) there were no connections to the wrong machine. I imagine that we'll use DNS for easier management even if we use private IPs so this also applies here. It will probably be /etc/hosts, but there can still be a mistake at some point.
TLS will be used regardless of VPN or not. And we are going to use valid certs, no self signed. As for the VPN, I would say that tinc or openvpn are options.
Regarding topology I'd like master-master if that works well, otherwise master-slave. How does 389ds resolve conflicts in a master-master setup and what's the performance like?
Coming to think of this, we want multi-master replication, because we need the ability of bringing up and down the servers for upgrades and other stuff. If we go with the master-slave topology, the master machine will require a lot of attention. Regards, Giancarlo Razzolini
Em março 6, 2018 6:58 Jelle van der Waa escreveu:
Thanks for the list, I've only worked with OpenLDAP on an amateur level :-)
It has been a while since I worked with this. I usually only interact with Microsoft's AD these days. As I said, I used 389-ds when it was still fedora-ds.
I'm eager to also see a list of how easy it would be to integrate either of these options with our application stack, as in what do we want to move to LDAP?
* archweb
Django has some ways to authenticate against ldap, so it's a mattter of picking one and trying it out. [0] [1]
* bbs
I was not able to find anything for fluxbb. Perhaps because when I type fluxbb ldap on google it gets into a loop and search all the fluxbb forums on the internet for ldap.
* bugtracker
Looked into bugzilla (not even considering flyspray here anymore). It has native LDAP support. [2]
* aurweb
Would need to be developed.
* ssh auth?
We get this for free when using pam_ldap. There are ways for us to even store the public key for the users on the LDAP directory itself.
* kanban board?
Surprisingly, kanboard also has native LDAP authentication support. [3] Now, for the things you forgot to mention: Wiki - Has support [4] Patchwork (same as archweb) Zabbix - Has support [5] Grafana - Has support [6] Mailman - I found some stuff using external perl scripts, but I don't see the point into putting this in LDAP. It will require work from a lot of people to integrate all this. I can change application by application, but I will need help from you guys to test, develop and use all this. The good thing is, since we are starting this LDAP server from scratch, we can do it the way we want and there's no issues in doing it again if needed. [0] https://bitbucket.org/psagers/django-auth-ldap/ [1] https://github.com/etianen/django-python3-ldap [2] https://www.bugzilla.org/docs/3.0/html/parameters.html [3] https://github.com/kanboard/kanboard/blob/master/doc/en_US/ldap-authenticati... [4] https://www.mediawiki.org/wiki/Extension:LDAP_Authentication [5] https://www.zabbix.com/documentation/3.2/manual/web_interface/frontend_secti... [6] http://docs.grafana.org/installation/ldap/
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 --
Em março 6, 2018 7:37 Thore Bödecker via arch-devops escreveu:
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.
Well, this is why we are using ansible for this. So we can set it up and maintain it in a way that anyone from our devops team can do it. And we have other people with LDAP knowledge as well.
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?
No, I don't. And OpenLDAP now uses mdb so it might be that OpenLDAP is the same, resource usage wise. I'll make some tests.
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.
I don't want to use it either, but we have it packaged on our repos.
It would be great to have some kind of CLI/TUI locally on the server which could be used through SSH.
389-ds has a java console that you can run locally and tunnel over SSH or run remotely with SSH X forwarding.
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.
I have not included other options, like OpenDJ and apache's because of their licenses.
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.
There's also the option of using SSSD for caching, as it was pointed out to me on IRC.
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.
This is expected, yes.
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.
We can have a multi-master scenario. In fact, since we reboot the machines now and then, it's even advised to.
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.
I don't like the idea either of leaving LDAP open to the internet. Even if it is without anonymous connections support. But we do have other services in this situation. They use TLS and the internal auth of the service, but that's that. If we go the VPN route, it would add complexity. Let's see how this goes.
That's all what I've got so far.
Thanks. Regards, Giancarlo Razzolini
participants (4)
-
Florian Pritz
-
Giancarlo Razzolini
-
Jelle van der Waa
-
Thore Bödecker