Bright Cluster Manager provides a managed LDAP database for user and group management but, by default, it is protected with TLS certificates which limit the ability for some third party tools to access the directory. This article will go through the steps to reconfigure the Bright LDAP server to allow 3rd parties to connect and query the LDAP server after authentication with bind credentals.
Note: This procedure has been tested under CentOS 7 on Bright Cluster Manager 9.1. Caution should be taken when making changes to any authentication settings as improper procedures may prevent LDAP from working and users from accessing the system.
You will require a third party system that needs to connect to the LDAP which is unable to use client certificates. Configuration and support of the third party system is beyond the scope of this article.
You need to be using the Bright LDAP to manage users and groups. If you are using another authentication mechanism such as AD these steps will not work without changes.
In order for the steps in this article to work correctly slapd needs to be built with SASL2 support. Currently RedHat and derivative systems builds have this support and Ubuntu based systems do not. Please confirm that your system has this support with the following command.
# ldd /cm/local/apps/openldap/sbin/slapd | grep sasl2 && echo SASL2 OK || echo NO SASL2 SUPPORT libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00002aaaac7cc000) SASL2 OK
If you see SASL2 suppor then you can continue with this article.
# ldd /cm/local/apps/openldap/sbin/slapd | grep sasl2 && echo SASL2 OK || echo NO SASL2 SUPPORT NO SASL2 SUPPORT
If you do not see
SASL2 OK then STOP, attempting to enable bind authentication will break your system.
Bright is working to enable SASL2 support on Ubuntu based systems.
By default, the Bright LDAP configuration is secured by mTLS connections between the clients and the server. This is very secure but prevents many 3rd party tools from integrating with the Bright LDAP directory due to lack of support for mTLS. By leveraging SASL2 we can allow the certificates to be one form of authentication but still allow connections without a client certificate to use LDAP bind authentication. This means we keep the strong security guarantees of the certificate authentication but allow third party tools to connect using a bind account and password.
SASL2 external authentication exposes the client certificate CN to the server for use as a form of valid authentication.
The general procedure for this is as follows
- Enable SASL2 External authentication on all of the certificate based clients. Documentation here will cover OpenLDAP, nslcd, and sssd. If you have other certificate based clients you will need to confirm they are sending the SASL2 external authentication with their request.
- All clients need to be restarted. When slapd changes become effective existing clients not sending a SASL2 external authentication will no longer be allowed to access the LDAP.
- Alter and restart slapd server.
- Add account to LDAP for use in bind requests
Enable SASL2 Clients
SASL2 must be enabled in the clients before enabling it on the server. Clients sending this extra information will still be able to connect without an issue. If you have altered your configuration to use a different authentication mechanism then you will need to adapt these changes to your environment.
OpenLDAP default configuration is in
/etc/openldap/ldap.conf you can add the following lines to the bottom of the file to enable external authentication.
# force external authentication by default SASL_MECH external
The default LDAP system client is nslcd. This will need to be updated on both the head node(s) as well as the compute images. You can find the nslcd configuration in with the following check.
# # Presuming images are in standard location # find /etc /cm/images/* -maxdepth 2 -name nslcd.conf /etc/nslcd.conf /cm/images/default-image/etc/nslcd.conf
You will need to add the following line to the configurations.
# Use certificate as auth sasl_mech external
Once it has been added the nslcd client must be restarted to use the new configuration. On the head node this is a simple matter of restarting the service.
# # On head node # systemctl restart nslcd #
For your compute images reconfiguring and restarting the nslcd can be completed in one of two ways.
- Reboot the node: This will pull the new configuration from the image and restart the daemon
- Use of the
imageupdate -wto push the image changes to the node and then restarting the nslcd on each node.
Failure to configure nslcd properly will likely result in errors similar to the following in the logs.
Nov 08 16:17:05 node001 nslcd: [534a82] <passwd="cmsupport"> connected to LDAP server ldaps://ldapserver/ Nov 08 16:17:05 node001 nslcd: [534a82] <passwd="cmsupport"> ldap_result() failed: Server is unwilling to perform: authentication required
sss ( non-standard )
Sssd is an alternate authentication and caching daemon, if you are running a stock Bright Cluster sssd will not be enabled and you can skip this section.
You will want to identify the configuration block that includes the Bright LDAP server. This can usually be identified by the following statement
ldap_uri = ldaps://ldapserver/ in the
/etc/sssd/sssd.conf file. Within that block you will want to add the following statement.
ldap_sasl_mech = EXTERNAL
You will then need to restart sssd. If your compute nodes are running sssd their configuration will need to be updated and sssd restarted as well.
Once all clients have been updated to send SASL2 external authentication it is necessary to enable the changes on the server.
For this change we will want to alter the file
/cm/local/apps/openldap/etc/slapd.conf. By default you will find the following statement in the file. This means that the server will require that the client presents a valid TLS client certificate for the connection.
You will want to alter the line above and add an additional statement so that it looks like the block below. In combination these two lines will allow client certificated to be sufficient authentication for directory access but will also allow bind credentials.
# allow mTLS but don't require it TLSVerifyClient try # was demand # demand authentication before LDAP queries mTLS counts as authentication # without this line the server will allow anonymous queries require authc
After which you will need to restart slapd.
# systemctl restart slapd #
In the following tests we can see that both external auth and bind authentication are now successful.
# ldapsearch uid=cmsupport SASL/EXTERNAL authentication started SASL username: cn=ew-ldap SASL SSF: 0 # extended LDIF # # LDAPv3 # base <dc=cm,dc=cluster> (default) with scope subtree # filter: uid=cmsupport # requesting: ALL # # cmsupport, cm.cluster dn: uid=cmsupport,dc=cm,dc=cluster uid: cmsupport cn: cmsupport objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount sn: cmsupport shadowLastChange: 18908 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/cmsupport # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
# cmsh -c 'user; add test; set password private; commit' # # Allow users to see the ca.pem # chmod o+x /cm/local/apps/openldap/etc/certs/ # chmod o+r /cm/local/apps/openldap/etc/certs/ca.pem # su - test $ ldapsearch -H ldaps://ldapserver:636 uid=cmsupport # without bind it fails SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: $ ldapsearch -D uid=test,dc=cm,dc=cluster -W -H ldaps://ldapserver:636 uid=cmsupport Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=cm,dc=cluster> (default) with scope subtree # filter: uid=cmsupport # requesting: ALL # # cmsupport, cm.cluster dn: uid=cmsupport,dc=cm,dc=cluster uid: cmsupport cn: cmsupport objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount sn: cmsupport shadowLastChange: 18908 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/cmsupport # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1