Hello Howard,
I may need some enlightment about it. First, I'd like to precise that we're
using OpenLDAP 2.5. The goal is to let clients with SSSD and x509
authentication access our LDAP, as well as classic password accounts query or
servers. The base setup on our slaves use an olcAuthzregexp map SASL DN to
existing DN's, and a set of ACL for all this people. It works pretty fine.
What I want to achieve is the same but through a back_ldap proxy, in a
different network zone. (May I not have been clear on my first explanation).
I ran many tests today based on your suggestion and I could make some
assertions that you eventually might want to comment:
*
Whenever I use olcAuthzRegexp on the proxy, SASL binds are always
unauthenticated on the backend, thus failing because it is forbidden.
*
I test many setup with legacy mode and at best the account setup in
idassert-bind was used with no control of the user's identity (granting full
access over the directory, a glitch with a lazy setup on dev servers)
*
As I wrote, setting authz=native at the begining of the olcIdassertBind
directive, in conjunction with authcId was rejected with the message
'authz=native is incompatible with auth' (at best it could be included at the
end, after the certificates definition, without apparent effects)
I wonder if I didn't understand your comment
What seems to work now is using self mode without authzregexp on the proxy. In
the backend log file I have these traces:
Aug 12 16:39:55 dev7-donnee01 slapd[662]: conn=365323 fd=18 ACCEPT from IP=*
(IP=*:636)
Aug 12 16:39:55 dev7-donnee01 slapd[662]: conn=365323 fd=18 TLS established
tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
Aug 12 16:39:55 dev7-donnee01 slapd[662]: conn=365323 op=0 BIND dn="cn=auth"
method=163
Aug 12 16:39:55 dev7-donnee01 slapd[662]: conn=365323 op=0 BIND
authcid="cn=*.test.local,ou=1234,o=test,c=fr"
authzid="*.test.local,ou=1234,o=test,c=fr"
Aug 12 16:39:55 dev7-donnee01 slapd[662]: conn=365323 op=0 BIND
dn="cn=synchronisation,ou=dsa,dc=test" mech=EXTERNAL bind_ssf=0 ssf=256
# this last DN is mapped with the backends authzregexp
...
Aug 12 20:57:20 dev7-donnee01 slapd[662]: conn=371877 op=6 PROXYAUTHZ
dn="uid=client,ou=sssd,ou=tech,dc=test" # This DN is also mapped with the
backend's authzregexp even if the is no more details under the hood
Aug 12 20:57:20 dev7-donnee01 slapd[662]: conn=371877 op=6 [IP=*
USERNAME=cn=5e4dfa9fae9.clients.test.local,ou=1234,o=test,c=fr] SRCH
base="ou=sudoers,dc=test" scope=2 deref=0 filter="(objectClass=*)"
Aug 12 20:57:20 dev7-donnee01 slapd[662]: conn=371877 op=6 [IP=*
USERNAME=cn=5e4dfa9fae9.clients.test.local,ou=1234,o=test,c=fr] ENTRY
dn="ou=sudoers,dc=doors"
Aug 12 20:57:20 dev7-donnee01 slapd[662]: conn=371877 op=6 [IP=*
USERNAME=cn=5e4dfa9fae9.clients.test.local,ou=1234,o=test,c=fr] SEARCH RESULT
tag=101 err=0 qtime=0.000044 etime=0.000932 nentries=1 text=
Using session-tracking-request gives us some insight about the enduser identity
on the backend's logs (I hope that it will be fullfiled with the proxy protocol
informations, more tests soon)
After this detailed report about what's working or not, can you tell me if it
is the way to go ? because this is the only working setup that I tested so far.
(not that I removed the flags as the man pages states they are defaults).
Thanks for your precious help
Jerome
________________________________
De : Howard Chu <h...@symas.com>
Envoyé : vendredi 8 août 2025 16:18
À : BECOT Jérôme <jbe...@itsgroup.com>; openldap-technical
<openldap-technical@openldap.org>
Objet : Re: Certificate authentication through LDAP Proxy (back_ldap)
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.
BECOT Jérôme wrote:
> Thank you Howard for your short answer. That confirms what I though. I still
> have an issue to make it work. I've try a lot of different setup and I don't
> make
> the proxy use the idassert-bind parameters. All of my tests sends the
> authentication information directly to the backend:
>
> *
> simple binds
> *
> anonymous binds
> *
> sasl with certificate binds
>
>
> I can read the following message into the proxy's logs with SASL:
> ldap_back_dobind_int: DN="uid=test,ou=tech,dc=local" without creds, binding
> anonymously
> Simple binds must be sent without assertion.
>
> I think I missed something to trigger proxy authorization on the proxy side.
You're using mode=legacy, which relies on authcID being configured. Since
you're using
SASL/EXTERNAL and a certificate, you can just set this to a dummy value. You
should also
set authz=native since you can use SASL proxy authorization and don't need the
proxyauthz control.
You also have an obvious error in the TLS config below.
>
> Here is the setup on the proxy:
>
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> *olcAuthzPolicy*: to # I think it has to be configured on the backend only,
> this is a try
> *olcAuthzRegexp*:
> {0}cn="[^.]*\.[Bb][0-9]{3}\.[^.]{3,5}\.([^.]{3})\.[^.]{3}\.[^,]*,ou=test,o=some,c=fr"
> "uid=$1,ou=tech,dc=local" # To map the cert id of the
> client to a remote account
> olcLocalSSF: 256
> olcLogLevel: stats stats2
> olcTLSCACertificateFile: /etc/certificates/local.ca
> olcTLSCertificateFile: /etc/certificates/proxy.local.crt
> olcTLSCertificateKeyFile: /etc/certificates/proxy.local.key
>
> dn: cn=module{0},cn=config
> objectClass: olcModuleList
> cn: module{0}
> olcModulePath: /usr/local/openldap/libexec/openldap
> olcModuleLoad: {0}argon2.la
> olcModuleLoad: {1}back_ldap.la
>
> dn: olcDatabase={2}ldap,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcLDAPConfig
> olcDatabase: {2}ldap
> olcSuffix: dc=local
> olcDbURI: "ldaps://backend.local:636"
> olcDbIDAssertBind:
> mode=legacy
> flags=prescriptive,proxy-authz-non-critical
> bindmethod=sasl saslmech=EXTERNAL
> tls_cacert="/etc/certificates/local.ca"
> tls_cacert="/etc/certificates/proxy.local.crt"
> tls_cacert="/etc/certificates/proxy.local.key"
You've set tls_cacert 3 times. You need to set cert and key.
> olcDbIDAssertAuthzFrom: {0}*
> olcDbRebindAsUser: FALSE
> olcDbChaseReferrals: TRUE
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
> *De :* Howard Chu <h...@symas.com>
> *Envoyé :* mercredi 6 août 2025 17:51
> *À :* BECOT Jérôme <jbe...@itsgroup.com>; openldap-technical
> <openldap-technical@openldap.org>
> *Objet :* Re: Certificate authentication through LDAP Proxy (back_ldap)
>
> 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.
>
> BECOT Jérôme wrote:
>> Hello,
>>
>> We have a working setup with two mirror master and two slaves:
>>
>> *
>> Syncrepl uses a certificate on each node to fetch data, with an
>> olcAuthzRegexp rule to map it to a DSA (simpleSecurityObject).
>> *
>> Client SSSD servers also use a dedicated certificate to authenticate on
>> the slaves, with another olcAuthzRegexp to map them to a "per project" DSA.
>> *
>> We use different ACL on the main db because some DSA have privileged
>> access to some branches
>>
>>
>> We want to expose data on another subnets through proxies, and cyber ask to
>> use OpenLDAP with back_ldap.
>>
>> How should we configure them to use client certificate authentication to the
>> backend slaves ?
>
> back-ldap cannot use the client's certificates on the backend slaves. All you
> can do is configure
> back-ldap to use proxy authorization to assert the client's identity on its
> connections to the
> backends. back-ldap itself can use its own certificate or any other
> authentication method to
> authenticate itself to the backends, and then proxy authorize on behalf of
> the clients.
>>
>> Any thoughts appreciated
>> Regards
>> Jerome
>>
>
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
