Super User Asked by Graham Leggett on November 27, 2021
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:DNComps
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:
[sssd]
config_file_version = 2
domains = LDAP
services = nss, pam
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75
[pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
# A native LDAP domain
[domain/LDAP]
enumerate = true
cache_credentials = TRUE
debug_level = 9
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://ldap.example.com:636
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
Certificate
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.
Update:
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?
This should answer your last question regarding sssd not trying to use client certificate. From sssd-ldap, version 1.1.14 (https://jhrozek.fedorapeople.org/sssd/1.14.2/man/sssd-ldap.5.html):
ldap_default_authtok_type (string)
The type of the authentication token of the default bind DN. The two mechanisms currently supported are: password obfuscated_password 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
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP