Le 21/04/2023 à 18:00, Quanah Gibson-Mount a écrit :

--On Friday, April 21, 2023 2:36 PM +0200 Benjamin Renard brenard@easter-eggs.com wrote:

...

Hello,

I have problem with the olcPPolicyForwardUpdates option that seem not Do you have any idea of what I doing wrong ?

Hello,

you failed to provide any OpenLDAP version information.

You'r right, I'm using slapd 2.4.57+dfsg-3+deb11u1 (on Debian stable).

Hello,

You'r right, 2.5 is available in backports, but I still preferred to used stable version for fast delivery of security update. The next release of Debian is coming soon, I will update my installations at this time.

I reconfigure chaining on frontend instead on the database, but I still have problem. Same as before, if I try to connect on LDAP slave with a bad password, the error is not reported on LDAP master and I have nothing in logs (level stats) that suggested it tried.

Furthermore, I tried to make a change on LDAP to test the chaining and I have the following error :

ldap_modify: Proxied Authorization Denied (123)

So, I mean I have an error to fix in chaining before hoping olcPPolicyForwardUpdates will works.

See next my chaining configuration :

dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig objectClass: top olcOverlay: {0}chain olcChainReturnError: TRUE olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1

dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase= {-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase objectClass: top olcDatabase: {0}ldap olcDbURI: ldaps://ldap-master olcDbCancel: abandon olcDbChaseReferrals: TRUE olcDbConnectionPoolMax: 8 olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbProtocolVersion: 3 olcDbProxyWhoAmI: FALSE olcDbRebindAsUser: TRUE olcDbSessionTrackingRequest: TRUE olcDbSingleConn: FALSE olcDbUseTemporaryConn: FALSE olcDbACLBind: bindmethod=simple binddn="uid=syncrepl,ou=sysaccounts,o=example" credentials="secret" keepalive=10:30:60 network-timeout=0 timeout=0 olcDbIDAssertBind: mode=self bindmethod=simple binddn="uid=syncrepl,ou=sysaccounts,o=example" credentials="secret" authz=proxyauthz keepalive=10:30:60 network-timeout=0 timeout=0

I also configure authzProxy on master and slave :

dn: cn=config [...] olcAuthzPolicy: to

dn: olcDatabase={1}mdb,cn=config [...] olcAccess: {0}to dn.subtree="cn=subschema" by * read olcAccess: {1}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {2}to attrs=authzTo by self read olcAccess: {3}to attrs=authzFrom by * read [...] olcUpdateRef: ldaps://ldap-master

dn: uid=syncrepl,ou=sysaccounts,o=example [...] authzTo: {0}dn.regex:^uid=.*,o=example$ authzTo: {1}dn.regex:^mail=.*,o=example$

Do you see something I'm doing wrong ?

Many thanks !

Le 24/04/2023 à 23:48, Quanah Gibson-Mount a écrit :

--On Saturday, April 22, 2023 6:07 PM +0200 Benjamin Renard brenard@easter-eggs.com wrote:

...

...

you failed to provide any OpenLDAP version information.

You'r right, I'm using slapd 2.4.57+dfsg-3+deb11u1 (on Debian stable).

Hi,

As a side note, OpenLDAP 2.4 series is historic and no longer supported.  I believe Debian has 2.5 available in backports for stable? Or there are builds for currently supported release series available from Symas or the LTB project:

https://repo.symas.com/ https://ltb-project.org/download.html

with that out of the way....

If you read the admin guide (https://www.openldap.org/doc/admin25/overlays.html#Chaining), it is explicitly stated that the chain configuration exists before any database definitions (i.e., in the frontend). Here's what my cn=config looks like for chain and back-ldap sitting on top of it with OpenLDAP 2.6.  Note that I populate both olcDbACLBind and olcDbIDAssertBind:

dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: TRUE

dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldaps://<provider>:<port> olcDbACLBind: bindmethod=... olcDbIDAssertBind: mode=self ... olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 8 olcDbSessionTrackingRequest: TRUE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE

Hope that helps!

Regards, Quanah

Le 25/04/2023 à 17:04, Quanah Gibson-Mount a écrit :

--On Tuesday, April 25, 2023 4:00 PM +0200 Benjamin Renard brenard@easter-eggs.com wrote:

...

Hello,

You'r right, 2.5 is available in backports, but I still preferred to used stable version for fast delivery of security update. The next release of Debian is coming soon, I will update my installations at this time.

Deliver of what security updates?  OpenLDAP 2.4 is dead and hasn't been updated for 2 years.  If you think Debian's backporting the security fixes going into 2.5 and 2.6, I think you'll find that's not the case.

The Debian security team always maintain the 2.4 version, even if there have not been many security updates since the switch to 2.4 :

https://metadata.ftp-master.debian.org/changelogs//main/o/openldap/openldap_...

I'll look further into the chaining configs when I have a bit more time.

Many thanks !

Le 25/04/2023 à 18:15, Quanah Gibson-Mount a écrit :

--On Tuesday, April 25, 2023 6:40 PM +0200 Benjamin Renard brenard@easter-eggs.com wrote:

...

The Debian security team always maintain the 2.4 version, even if there have not been many security updates since the switch to 2.4 :

https://metadata.ftp-master.debian.org/changelogs//main/o/openldap/openld ap_2.4.57+dfsg-3+deb11u1_changelog

Yes, I talk with Ryan regularly.  You're missing the point.  If you're whole issue is security updates, then you're not getting it running 2.4. You're also missing out on significant bug fixes to the ppolicy overlay and other backends that may impact your deployment.

--Quanah

OK, thanks for your advice. I will try to update it on the preprod to be sure I will be able to manage any upgrade issue.

Hello,

Le 25/04/2023 à 18:48, Quanah Gibson-Mount a écrit :

--On Tuesday, April 25, 2023 7:40 PM +0200 Benjamin Renard brenard@easter-eggs.com wrote:

...

OK, thanks for your advice. I will try to update it on the preprod to be sure I will be able to manage any upgrade issue.

You may find this helpful as well:

https://repo.symas.com/soldap2.5/upgrading/

One of the largest changes that will impact you initially is the removal of the ppolicy schema from the schema tree (it's now built into the ppolicy overlay directly).

--Quanah

After successfully upgrade the preprod in 2.5, I try this upgrade in the same way on prod master and slave hosts. I had to fallback in 2.4 because of a strange bug/error : slapd stop it self/crash with the following message in logs :

Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=0 BIND dn="uid=syncrepl,ou=sysaccounts,o=example" method=128 Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=0 BIND dn="uid=syncrepl,ou=sysaccounts,o=example" mech=SIMPLE bind_ssf=0 ssf=256 Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=0 RESULT tag=97 err=0 qtime=0.000036 etime=0.000164 text= Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=1 SRCH base="o=example" scope=2 deref=0 filter="(objectClass=*)" Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=1 SRCH attr=* + Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=1 syncprov_op_search: got a persistent search with a cookie=rid=000,csn=20190213173033.952331Z#000000#000#000000;20230427155638.609257Z#000000#001#000000;20190916120217.913828Z#000000#003#000000 Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=1 syncprov_findbase: searching Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=1 syncprov_op_search: registered persistent search Apr 27 18:45:35 gavotte slapd[1086662]: Stopping OpenLDAP: slapd.

It seem related with syncprov and in fact, in preprod, I have no slave/replication.

My syncrepl configuration is quite simple :

On master:

dn: olcOverlay={3}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig objectClass: top olcOverlay: {3}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE

On slave:

dn: olcDatabase={1}mdb,cn=config [...] olcSyncrepl: {0}rid=0 provider=ldaps://ldap-master bindmethod=simple timeout=0 network-timeout=0 binddn="uid=syncrepl,ou=sysaccounts,o=example" credentials="secret" keepalive=0:0:0 filter="(objectclass=*)" searchbase="o=example" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" olcUpdateRef: ldaps://ldap.enercoop.org

Do you have idea of what could produce these crashs/stops ?

Thanks !

Le 27/04/2023 à 19:17, Quanah Gibson-Mount a écrit :

--On Thursday, April 27, 2023 8:12 PM +0200 Benjamin Renard brenard@easter-eggs.com wrote:

...

Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=1 syncprov_op_search: registered persistent search Apr 27 18:45:35 gavotte slapd[1086662]: Stopping OpenLDAP: slapd.

This shows two completely different PIDs for slapd? 1086351 and 1086662

Effectively : I found no other reference to the second PID (1086662) in logs. I check and I have the same PID difference on other crashs/stops. It's could be a systemd related issue, but on each crashs/stops, the last logged messages are always the same about a connection from the slave host (another example) :

Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 fd=53 ACCEPT from IP=1.2.3.4:58806 (IP=0.0.0.0:636) Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 fd=53 TLS established tls_ssf=256 ssf=256 tls_proto=TLS1.3 tls_cipher=AES-256-GCM Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=0 BIND dn="uid=syncrepl,ou=sysaccounts,o=example" method=128 Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=0 BIND dn="uid=syncrepl,ou=sysaccounts,o=example" mech=SIMPLE bind_ssf=0 ssf=256 Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=0 RESULT tag=97 err=0 qtime=0.000036 etime=0.000164 text= Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=1 SRCH base="o=example" scope=2 deref=0 filter="(objectClass=*)" Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=1 SRCH attr=* + Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=1 syncprov_op_search: got a persistent search with a cookie=rid=000,csn=20190213173033.952331Z#000000#000#000000;20230427155638.609257Z#000000#001#000000;20190916120217.913828Z#000000#003#000000 Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=1 syncprov_findbase: searching Apr 27 18:45:35 gavotte slapd[1086351]: conn=1224 op=1 syncprov_op_search: registered persistent search Apr 27 18:45:35 gavotte slapd[1086662]: Stopping OpenLDAP: slapd. Apr 27 18:45:35 gavotte systemd[1]: slapd.service: Succeeded. Apr 27 18:45:35 gavotte systemd[1]: slapd.service: Consumed 8.302s CPU time.

Do you have any idea of what is going wrong ?

Thanks !

Le 27/04/2023 à 19:28, Stefan Kania a écrit :

Why do you have two csn from 2019 and one from 2023?

Hum... I not sure to understand your question :( My two hosts was on the same slapd version (2.5.13+dfsg-2~bpo11+1) from Debian Bullseye Backports repository.

Le 27/04/2023 à 19:53, Stefan Kania a écrit :

Your log is telling that you have three server 000, 001 and 003 csn=20190213173033.952331Z#000000#000#000000;20230427155638.609257Z#000000#001#000000;20190916120217.913828Z#000000#003#000000

And as you can see the csn from 000 and 003 is from 2019 and from 001 it's 2023 loos a little bit stange to my. And you also wrote that you have only two two hosts.

Effectively! In fact, I detected yesterday during the upgrade that I have old traces of a multi-master cluster with a third server that does not exist anymore. To clean this, I dropped the olcSyncrepl and olcMirrorMode properties of the database. May be I have to clean something else in the database content : How I could clean references to this old third server in database CSNs ?

Futhermore, can this explain the crashes/stops?

Thanks!