Integrating 3rd Party LDAP clients with bind credentials

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.

Prerequisites

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.

If you see SASL2 suppor then you can continue with this article.

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.

Overview

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

1. 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.
2. 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.
3. Alter and restart slapd server.
4. 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 Clients

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.

nslcd

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.

You will need to add the following line to the configurations.

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.

For your compute images reconfiguring and restarting the nslcd can be completed in one of two ways.

1. Reboot the node: This will pull the new configuration from the image and restart the daemon
2. Use of the imageupdate -w to 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.

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.

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.

SLAPD server

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.

After which you will need to restart slapd.

Testing

In the following tests we can see that both external auth and bind authentication are now successful.

Certificates

Bind