On Tue, Jul 30, 2024 at 2:29 PM Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Sunday, July 28, 2024 7:09 PM -0700 Travis Bean tbean74@gmail.com wrote:
I developed a Bash script (https://launchpad.net/linuxha) to automate the installation and configuration of complex Linux software that is out of reach for most people. I want the syntax of this script to be perfect so I can use it as a teaching tool to educate people about Linux.
If anyone on this mailing list is knowledgeable about multi-master OpenLDAP with SASL/GSSAPI authentication, please review the OpenLDAP/SASL/GSSAPI code that is part of my LinuxHA script and provide feedback. Thank you.
Just glancing at your script I see errors, such as:
SASL_MECH GSSAPI PLAIN
for ldap.conf. The man page clearly notes this takes a SINGLE mechanism.
If ldap.conf(5) only supports one SASL mechanism for the SASL_MECH variable, then the man page at https://www.openldap.org/software/man.cgi?query=ldap.conf needs to be updated to clarify this.
I originally configured the SASL_MECH variable for OpenLDAP's ldap.conf(5) the same way I configured the mech_list variable for Postfix's smtpd.conf and the auth_mechanisms variable for Dovecot's 10-auth.conf. I configured multiple SASL mechanisms for each of these variables for testing purposes.
For a local area network, a system administrator has complete control over all the workstations and can make sure they all have Kerberos installed. For internet facing servers providing services to the wide area network (WAN), it makes sense to use a second SASL mechanism (something other than SASL/GSSAPI) in case any WAN devices do not have Kerberos installed, since a sysadmin may have no control over what is installed on WAN devices.
I recently replaced libpam-ldap and libnss-ldap with sssd-ldap and sssd-krb5 for LinuxHA, since SSSD is a much better solution for identity and authentication.
Also, SASL/PLAIN is insecure and should never be used.
Technically this is true. Even though when SASL/PLAIN is used in conjunction with Transport Layer Security, the credentials are encrypted.
When ldap.conf(5) is installed on a server (as was the case when I was testing ldap.conf(5) on LinuxHA), using SASL/PLAIN is not insecure because it is only connected to a local socket on the local machine.
Another note is that SASL/GSASPI is extremely dependent on valid hostname resolution. The pam ldap.conf seems unlikely to work (ldap://localhost for the URI).
When /etc/ldap.conf (the configuration file for PADL’s pam_ldap and nss_ldap modules) or /etc/ldap/ldap.conf (the configuration file for client applications such as ldapsearch, ldapadd, ldapmodify, and ldapdelete) is installed on a server rather than a workstation, you use "uri ldap://localhost", or "uri ldap://127.0.0.1", or better yet use LDAP over IPC mechanisms (LDAP over Inter-Process Communication) a.k.a. UNIX domain sockets (i.e., "uri ldapi:///"). See the following webpage for further details: https://datatracker.ietf.org/doc/html/draft-chu-ldap-ldapi-00
I see so many things that are bad practice in this script in general I'm not going to spend any more time reviewing it.
I have tried very hard to make sure there are no “bad practices” incorporated into LinuxHA. From a security standpoint, I have attempted to design LinuxHA so it is one step ahead of standard security policies.
Everytime Canonical releases a new version of Ubuntu Server, the configuration for LinuxHA has to be updated. I have tested LinuxHA on seven versions of Ubuntu Server thus far — from 12.04 to 24.04. Even though I try to go through all the software packages incorporated into LinuxHA everytime Canonical releases a new version of Ubuntu Server to see if any configuration file has changed and needs to be updated, it may take awhile to complete these updates.
If you find any misconfiguration in LinuxHA, please submit a bug report: https://bugs.launchpad.net/linuxha/+filebug
Kind regards,
Travis Bean