[arch-devops] LDAP role

[Thore Bödecker]

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

-- 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-devops/attachments/20180306/f4cc9af4/attachment.asc>