* In my opinion, the use of the idassert-bind parameter allows the proxy server to use its own certificate for authentication and to transmit its DN via SASL EXTERNAL to the backend server. * The TLS options in this parameter specify the paths to the certificates (CERT,KEY,CA) to be used.

And you're right, it's used directly by idassert-bind, but your openldap client may not be properly configured when you're testing, this is why I suggested to add a ldaprc file to ensure your tests are relevants. You have noticed I copied parameters from it.

Validating that it's ok with the client let you eliminate the backend side configuration issues, so you can focus on the proxy configuration then.

As noted by Quanah, OpenLDAP 2.4 is quite old, you'd better swith to a 2.5 or 2.6. ________________________________ De : fred750164@gmail.com fred750164@gmail.com Envoyé : lundi 20 janvier 2025 20:00 À : openldap-technical@openldap.org openldap-technical@openldap.org Objet : RE: ldap proxy

[Vous ne recevez pas souvent de courriers de fred750164@gmail.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

ATTENTION : Cet e-mail provient de l'extérieur de l'organisation. Ne cliquez pas sur les liens et n'ouvrez pas les pièces jointes à moins que vous ne reconnaissiez l'expéditeur et que vous sachiez que le contenu est sûr.

In my opinion, the use of the idassert-bind parameter allows the proxy server to use its own certificate for authentication and to transmit its DN via SASL EXTERNAL to the backend server.

The TLS options in this parameter specify the paths to the certificates (CERT,KEY,CA) to be used.

My interpretation may not be correct.

Have you got a solution for OpenLdap 2.5 or 2.6 ?

--On Wednesday, January 29, 2025 1:40 PM +0000 BECOT Jérôme jbecot@itsgroup.com wrote:

Sorry for the delay I'm quite buisy.

Do you still have the same messages in the logs ? On both backend and proxy side. You may want to remove tls_cacertdir=/etc/ssl/certs from idassert-bind config because it uses tls_cacert. Can you give both backend and proxy logs when you're trying to connect via the proxy ?

Either option is valid. One accepts any cert in the listed directory, the other takes a reference to a specific file. From the man page:

[tls_cacert=<file>] [tls_cacertdir=<path>]

--Quanah

Can you ensure the account running openldap is able to read certificate and key ?

like sudo -u <openldap_user> cat <path_to_files>

Sounds like the proxy is not able to send its certificate ________________________________ De : Fred N fred750164@gmail.com Envoyé : jeudi 30 janvier 2025 11:05 À : openldap-technical@openldap.org openldap-technical@openldap.org Objet : RE: ldap proxy

ATTENTION : Cet e-mail provient de l'extérieur de l'organisation. Ne cliquez pas sur les liens et n'ouvrez pas les pièces jointes à moins que vous ne reconnaissiez l'expéditeur et que vous sachiez que le contenu est sûr.

I remove the parameter (tls_cacertdir=/etc/ssl/certs) from idassert-bind config and result is :

Client log (other ldap server) : ldapsearch -H ldap://ldap-proxy.fr -b "dc=appli,dc=test,dc=com" -D "dn" -w "pwd" ldap_bind: Server is unavailable (52) additionnal info: Proxy operation retry failed

Proxy log: 679a61e2.1c43bb27 0x7f8d6cf56640 TLS trace: SSL3 alert read:fatal:unknown

Backend log: 679b49c4.0aa74b3e 0x7f39e25fd6c0 TLS trace: SSL3 alert write:fatal:unknown 679b49c4.0aa76a7f 0x7f39e25fd6c0 TLS trace: SSL_accept:error in error 679b49c4.0aa79f9f 0x7f39e25fd6c0 TLS: can't accept: error:0A0000C7:SSL routines::peer did not return a certificate. 679b49c4.0aa7fcfb 0x7f39e25fd6c0 connection_read(11): TLS accept failure error=-1 id=1001, closing 679b49c4.0aa83473 0x7f39e25fd6c0 connection_closing: readying conn=1001 sd=11 for close 679b49c4.0aa86f6f 0x7f39e25fd6c0 connection_close: conn=1001 sd=11

From client ldap, i want to query an LDAP backend via an LDAP proxy. I want the query from the client to be unsecured with a simple authentication (bindn), but the proxied communication between the LDAP proxy and the LDAP backend to be secured through mutual TLS authentication via SASL EXTERNAL.

my setup is not working at the moment.

(shudder when seeing your security settings)

Here we use ACLs on Linux ,like this: v07:/etc/ssl/serverkeys # getfacl ds.key # file: ds.key # owner: root # group: root user::rw- user:ldap:r-- group::--- mask::r-- other::---

Kind regards, Ulrich Windl

-----Original Message----- From: Fred N fred750164@gmail.com Sent: Thursday, January 30, 2025 6:29 PM To: openldap-technical@openldap.org Subject: [EXT] RE: ldap proxy

proxy ldap is running by : /usr/sbin/slapd -u ldap -h ldap://ldap-proxy.fr -f /etc/openldap/slapd.conf -d 1

and certifcates are configured : [root@ldap-proxy certs]# ls -lrt total 16 -rwxrwxrwx. 1 ldap ldap 1972 6 déc. 17:30 server.crt -rwxrwxrwx. 1 ldap ldap 3647 6 déc. 17:33 server.key -rwxrwxrwx. 1 ldap ldap 7763 13 déc. 21:48 ca-bundle.crt [root@ldap-proxy certs]#

Yes but have you checked that ldap is able to read this folder with the command I provided ? ________________________________ De : Fred N fred750164@gmail.com Envoyé : lundi 3 février 2025 20:45 À : openldap-technical@openldap.org openldap-technical@openldap.org Objet : RE: [EXT] RE: ldap proxy

ATTENTION : Cet e-mail provient de l'extérieur de l'organisation. Ne cliquez pas sur les liens et n'ouvrez pas les pièces jointes à moins que vous ne reconnaissiez l'expéditeur et que vous sachiez que le contenu est sûr.

I set these rights to try because at the moment the proxy server was not sending its certificate during mutual TLS authentication

Maybe you cannot log in (as intended), but you can "su -s /bin/bash - ldap", right?

Mit freundlichen Grüßen Ulrich Windl

-----Original Message----- From: Fred N fred750164@gmail.com Sent: Tuesday, February 4, 2025 9:58 AM To: openldap-technical@openldap.org Subject: [EXT] RE: RE: ldap proxy

I can't login with my account ldap : /usr/sbin/useradd -r -d /ldap -s /usr/sbin/nologin -g ldap ldap

I ran slapd as root, and I have the same problem. I modified the ACLs on certificates (777) for testing :

[root@ldap-proxy ~]# /usr/sbin/slapd -h ldap://ldap-proxy.fr -f /etc/openldap/slapd.conf -d 1

root@ldap-proxy certs]# getfacl * # file: ca-bundle.crt # owner: root # group: root user::rwx group::rwx other::rwx

# file: server.crt # owner: root # group: root user::rwx group::rwx other::rwx

# file: server.key # owner: root # group: root user::rwx group::rwx other::rwx

[root@ldap-proxy certs]#

backend logs:

67a1daee.1154b90b 0x7f64a65fd6c0 TLS: can't accept: error:0A0000C7:SSL routines::peer did not return a certificate. 67a1daee.115519eb 0x7f64a65fd6c0 connection_read(11): TLS accept failure error=-1 id=1003, closing 67a1daee.1157f6bd 0x7f64a65fd6c0 connection_closing: readying conn=1003 sd=11 for close 67a1daee.115914ae 0x7f64a65fd6c0 connection_close: conn=1003 sd=11 67a1daee.115930ce 0x7f64a75ff6c0 daemon: activity on 1 descriptor 67a1daee.115a630f 0x7f64a65fd6c0 daemon: removing 11 67a1daee.115b3150 0x7f64a75ff6c0 daemon: activity on:67a1daee.115cf5a9 0x7f64a65fd6c0 conn=1003 fd=11 closed (TLS negotiation failure)

My proxy is an intermediary between the client and the backend. It is the one that must send its certificate. I tried using an LDAPRC file in the current LDAP directory (/etc/openldap).

[root@ldap-proxy openldap]# cat LDAPRC TLS_REQCERT demand TLS_CACERT /etc/openldap/certs/ca-bundle.crt TLS_CERT /etc/openldap/certs/server.crt TLS_KEY /etc/openldap/certs/server.key SASL_MECH external [root@ldap-proxy openldap]#

slapd is running as root, the certificates are accessible, and I am getting the same error.

client : ldapsearch -H ldap://ldap-proxy.fr -b "dc=appli,dc=test,dc=com" -D "dn" -w "pwd" ldap_bind: Server is unavailable (52) additionnal info: Proxy operation retry failed

backend: 67a2399c.16545bc1 0x7fcd097fe6c0 TLS: can't accept: error:0A0000C7:SSL routines::peer did not return a certificate. 67a2399c.1654df65 0x7fcd097fe6c0 connection_read(11): TLS accept failure error=-1 id=1001, closing 67a2399c.1655ea96 0x7fcd097fe6c0 connection_closing: readying conn=1001 sd=11 for close 67a2399c.1656cbfb 0x7fcd097fe6c0 connection_close: conn=1001 sd=11 67a2399c.1656e627 0x7fcd09fff6c0 daemon: activity on 1 descriptor 67a2399c.16580ddb 0x7fcd097fe6c0 daemon: removing 11 67a2399c.1658da8c 0x7fcd09fff6c0 daemon: activity on:67a2399c.165a2375 0x7fcd097fe6c0 conn=1001 fd=11 closed (TLS negotiation failure) 67a2399c.165afc42 0x7fcd09fff6c0 67a2399c.165ca47b 0x7fcd09fff6c0 daemon: epoll: listen=7 active_threads=0 tvp=NULL

I am using both 2.5 and 2.6 also and I get the same results.

TLS options are duplicated in the slapd.conf file.

slapd.conf on proxy server: [...] # TLS TLSCACertificateFile /etc/openldap/certs/ca-bundle.crt TLSCertificateFile /etc/openldap/certs/server.crt TLSCertificateKeyFile /etc/openldap/certs/server.key TLSCipherSuite HIGH TLSVerifyClient demand

Database ldap suffix dc=test,dc=com uri ldaps://mytest.com:636 idassert-bind mode=self bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/openldap/certs/server.crt tls_key=/etc/openldap/certs/server.key tls_cacert=/etc/ssl/certs/ca-bundle.crt tls_cacertdir=/etc/ssl/certs tls_crlcheck=none tls_reqcert=allow [...]

What is the correct configuration to set for my use? why doesn't my proxy (as client) send his certificate?

On Wed, Feb 05, 2025 at 12:22:33PM -0000, Fred N wrote:

What is the correct configuration to set for my use? why doesn't my proxy (as client) send his certificate?

Use the 'tls' directive and put the configuration (what you have in idassert-bind) there. You really want to read the manpage I pointed you to earlier...

As for authz-regexp, no idea how you prepare the certificates' DNs and if they map to anything in the DIT (DB) or its ACLs. So first you'll have to decide how you want things to work in principle.

Regards,

I can't enable SASL External authentication mode after TLS handshake. Is there a reason and how to fix this issue?

sorry if I'm not clear

When my client performs a search, ldap proxy forwards the request to the backend.

client : ldapsearch -H ldap://ldap.fr -b "dc=appli,dc=test,dc=com" -D "uid=root,dc=test,dc=com" -w "pwd"

the logs are as follows (backend): 67b8c3fd.134650d5 0x7f12f7fff6c0 conn=1001 fd=11 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 67b8c3fd.13667ba6 0x7f12fcdfe6c0 conn=1001 op=0 BIND dn="uid=root,dc=test,dc=com" method=128 67b8c3fd.136c7879 0x7f12fcdfe6c0 conn=1001 op=0 BIND dn="uid=root,dc=test,dc=com" mech=SIMPLE bind_ssf=0 ssf=256 67b8c3fd.137b3dbf 0x7f12fcdfe6c0 conn=1001 op=0 RESULT tag=97 err=0 qtime=0.000627 etime=0.002286 text=

method=128 indicates that the proxy requests external sasl authentication but it does not happen. The proxy certificate does not seem to be used and the client bind is used.

Why is the proxy certificate not used even though the mutual TLS connection is established?