How do I configure sssd to authenticate against LDAP using client certificates / SASL EXTERNAL

I have a need to configure various Ubuntu Trusty machines using sssd against a 389ds server that expects to be bound to using a binddn selected automatically via a client certificate mapping.

I have successfully set up 389ds with a certmap as follows:

# By default, we trust any valid certificate that has an ou attribute that
# matches an entry (currently ou=Servers) in the DIT
certmap default     default
default:FilterComps ou
default:verifycert  off

In addition, I have disabled anonymous binds and forced SASL external binds as follows:

# disable anonymous binds
dn: cn=config
changetype: modify
replace: nsslapd-allow-anonymous-access
nsslapd-allow-anonymous-access: off

# force sasl external binds to use cert
dn: cn=config
changetype: modify
replace: nsslapd-force-sasl-external
nsslapd-force-sasl-external: on

On the sssd side, I have /etc/sssd/sssd.conf that looks as follows:

config_file_version = 2
domains = LDAP
services = nss, pam

filter_groups = root
filter_users = root
reconnection_retries = 3
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75

reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5

# A native LDAP domain
enumerate = true
cache_credentials = TRUE
debug_level = 9

id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

ldap_uri = ldaps://
ldap_user_search_base = dc=example,dc=com
tls_reqcert = demand
ldap_tls_cacert = /etc/ssl/certs/root-ca.crt
ldap_tls_cert = /etc/ssl/certs/my.crt
ldap_tls_key = /etc/ssl/private/my.key
ldap_sasl_mech = EXTERNAL

When I start up sssd, sssd attempts to bind to 389ds, first by attempting to bind anonymously (which then fails), and then by using the SASL EXTERNAL mechanism (which also fails):

(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0400): Search result: Inappropriate authentication(48), Anonymous access is not allowed.
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Inappropriate authentication(48), Anonymous access is not allowed.
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_get_generic_done] (0x0100): sdap_get_generic_ext_recv failed [5]: Input/output error
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_get_server_opts_from_rootdse] (0x0200): No known USN scheme is supported by this server!
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1458231814
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: EXTERNAL, user: (null)
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-6)[Unknown authentication method]
(Thu Mar 17 16:08:34 2016) [sssd[be[LDAP]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-4): no mechanism available: ]

Using ssldump, it appears that the client side sent a client certificate, however the ssldump -A option is buggy and it refuses to tell me anything about this cert:

1 3  0.0283 (0.0218)  C>SV3.3(7)  Handshake

The questions I have is:

  • Why is sssd’s attempt to bind anonymously failing? In theory the “nsslapd-force-sasl-external: on” should cause all bind attempts to be ignored in favour of the client certificate.

  • Why is ssd’s attempt to bind using SASL/EXTERNAL failing?

  • Is there any kind of guide or howto that describes sssd+ldap along with client certificates?

For the avoidance of doubt, in this scenario simple binds are not an option.


When I try use openssl s_client to connect to the 389ds server using the correct client certificate, the following correctly appears in the 389ds log indicating that the client certificate triggered a successful bind:

[17/Mar/2016:16:35:02 +0000] conn=130 SSL 128-bit AES-GCM; client CN=stuff,OU=Servers,O=Example,DC=example,DC=com; issuer CN=morestuff,OU=Example Signing CA,O=Example,DC=example,DC=com
[17/Mar/2016:16:35:02 +0000] conn=130 SSL client bound as ou=Servers,dc=example,dc=com

It appears in this case that sssd is not attempting to bind with the certificate and key provided. Anyone know why?

Super User Asked by Graham Leggett on November 27, 2021

2 Answers

2 Answers

This should answer your last question regarding sssd not trying to use client certificate. From sssd-ldap, version 1.1.14 (

ldap_default_authtok_type (string)

The type of the authentication token of the default bind DN.

The two mechanisms currently supported are:



Default: password

ldap_sasl_mech (string)

Specify the SASL mechanism to use. Currently only GSSAPI is tested and supported.

Default: not set

I've heard rumors as if this functionality was to be included in 1.1.13, but man page doesn't say anything new in this regard.

Answered by badbishop on November 27, 2021

The recommended setting (by RedHat) for anonymouse access is to set nsslapd-allow-anonymous-access to 'rootdse', rather than 'off'. I'm curious whether that would fix the problem you are seeing. This setting allows anonymous clients to read the server configuration, but not the directory data such as users. This is on p 412 of the RedHat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy Guide.

# force sasl external binds to use cert
dn: cn=config
changetype: modify
replace: nsslapd-force-sasl-external
nsslapd-force-sasl-external: rootdse

Answered by jdelaporte on November 27, 2021

Add your own answers!

Related Questions

Expanding inner Veracrypt volume (FAT)

1  Asked on December 27, 2021


Failed to create Menus

2  Asked on December 27, 2021 by user1071368


spaceport.sys is corrupt – windows 10

1  Asked on December 27, 2021 by developerharon


Duplicate UDP packets using iptable

0  Asked on December 27, 2021 by kapil-gupta


Ask a Question

Get help from others!

© 2022 All rights reserved.