1. Home
  2. Support and Documentation
  3. Integrating 3rd Party LDAP clients with bind credentials
  1. Home
  2. Third Party Software
  3. Integrating 3rd Party LDAP clients with bind credentials
  1. Home
  2. User Management
  3. Integrating 3rd Party LDAP clients with bind credentials

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.

# 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.

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.

# force external authentication by default
SASL_MECH external

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.

# # 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.

  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.

Nov 08 16:17:05 node001 nslcd[1897]: [534a82] <passwd="cmsupport"> connected to LDAP server ldaps://ldapserver/
Nov 08 16:17:05 node001 nslcd[1897]: [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.

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.

TLSVerifyClient demand

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
#

Testing

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

Certificates

# 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

Bind

# 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

Updated on November 19, 2021

Was this article helpful?

Related Articles

Leave a Comment