openldap-technical June 2023

openldap-technical@openldap.org

30 participants
37 discussions

Re: problem, and solution | database monitor
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

I created https://bugs.openldap.org/show_bug.cgi?id=10073 Thanks for making available a great product. On Mon, 26 Jun 2023 at 18:41, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, June 22, 2023 10:46 AM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi, > > > > > > I'm posting this mostly for the archives, so that a search for the error > > below will help a next person. > > Hi, > > Please open a bug on this issue at https://bugs.openldap.org > > Thanks! > > Regards, > Quanah > > > >

1 0

RE25 testing call (2.5.15) #1
by Quanah Gibson-Mount 26 Jun '23

26 Jun '23

This is the first testing call for OpenLDAP 2.5.15. Depending on the results, this may be the only testing call. NOTE: This release adds support for OpenSSL 3.0 to the 2.5 release series. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.5.15 Engineering Added libldap openssl3 support (ITS#9436, ITS#10030) Fixed libldap handling of TCP KEEPALIVE options (ITS#10015) Fixed libldap with async connections (ITS#10023) Fixed libldap openssl TLSv1.3 cipher suite handling (ITS#10035) Fixed slapd callback handling with overlays that do extended operations (ITS#9990) Fixed slapd conversion of pcache configurations (ITS#10031) Fixed slapd cn=config modification handling with abandon (ITS#10045) Fixed slapo-constraint handling of push replication (ITS#9953) Fixed slapo-dynlist filter evaluation efficiency (ITS#10041) Fixed slapo-pcache handling of invalid schema (ITS#10032) Fixed slapo-ppolicy handling of push replication (ITS#9953) Fixed slapo-ppolicy handling of pwdMinDelay (ITS#10028) Fixed slapo-syncprov abandon handling (ITS#10016) Fixed slapo-translucent handling of invalid schema (ITS#10032) Fixed slapo-unique handling of push replication (ITS#9953) Fixed slapo-variant to improve regex handling (ITS#10048) Build Environment Fixed compatibility with stricter C99 compilers (ITS#10011) Keep .pc files during make clean (ITS#9989) Contrib Fixed slapo-variant handling of push replication (ITS#9953) Minor Cleanup ITS#9855 ITS#9995 ITS#9996 ITS#9997 ITS#9998 ITS#9999 ITS#10000 ITS#10003 ITS#10004 ITS#10033 ITS#10037 ITS#10039 ITS#10046 Regards, Quanah

2 1

RE26 testing call (2.6.5) #1
by Quanah Gibson-Mount 26 Jun '23

26 Jun '23

This is the first testing call for OpenLDAP 2.6.5. Depending on the results, this may be the only testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.6.5 Engineering Fixed libldap handling of TCP KEEPALIVE options (ITS#10015) Fixed libldap with async connections (ITS#10023) Fixed libldap openssl TLSv1.3 cipher suite handling (ITS#10035) Fixed slapd callback handling with overlays that do extended operations (ITS#9990) Fixed slapd conversion of pcache configurations (ITS#10031) Fixed slapd cn=config modification handling with abandon (ITS#10045) Fixed slapd-mdb online indexer termination and cleanup (ITS#9993) Fixed slapd-mdb online indexer when interrupted (ITS#10047) Fixed slapd-monitor connection cleanup (ITS#10042) Fixed slapo-constraint handling of push replication (ITS#9953) Fixed slapo-dynlist filter evaluation efficiency (ITS#10041) Fixed slapo-pcache handling of invalid schema (ITS#10032) Fixed slapo-ppolicy handling of push replication (ITS#9953) Fixed slapo-ppolicy handling of pwdMinDelay (ITS#10028) Fixed slapo-syncprov abandon handling (ITS#10016) Fixed slapo-translucent handling of invalid schema (ITS#10032) Fixed slapo-unique handling of push replication (ITS#9953) Fixed slapo-variant to improve regex handling (ITS#10048) Build Environment Fixed compatibility with stricter C99 compilers (ITS#10011) Keep .pc files during make clean (ITS#9989) Contrib Fixed slapo-variant handling of push replication (ITS#9953) Minor Cleanup ITS#9855 ITS#9995 ITS#9996 ITS#9997 ITS#9998 ITS#9999 ITS#10000 ITS#10003 ITS#10004 ITS#10033 ITS#10037 ITS#10039 ITS#10046 Regards, Quanah

2 1

problem, and solution | database monitor
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

Hi, I'm posting this mostly for the archives, so that a search for the error below will help a next person. Today I wanted to setup the cn=Monitor backend, and after doing so, openldap failed to start with: backend_startup_one (type=monitor, suffix="cn=Monitor"): bi_db_open failed! (-1) The reason turned out to be: we had configured one of our databases ("database ldap") without a suffix. After I added a suffix, openldap started, and cn=Monitor worked as expected. I added a simple placeholder suffix (o=ldap,c=com) and now I need to find out what the database ldap was actually used for in our setup, and what the proper suffix should be. (does anyone perhaps know what openldap used as a default, if a "database ldap" suffix is omitted from the config?) Anyway: Hopefully this post will help a future someone with the same error message, as the error message had little to do the the cause.

2 1

slapacl issue
by Carsten Jäckel 26 Jun '23

26 Jun '23

Dear experts, in a testing environment (SLES 15 SP5, OpenLDAP 2.5.14) I use the following ACLs in olcAccess: {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by * none {1}to * by group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by * none break {2}to * by self read by anonymous auth by * none break If I run ldapmodify -xWD "cn=test,ou=users,dc=foo,dc=bar" to change the account cn=test,ou=users,dc=foo,dc=bar on the system with ip 10.10.10.10 everything works as expected. LDAP-Log: 2023-06-16T12:53:12.024030+02:00 tst1 slapd[1333]: conn=1016 fd=28 ACCEPT from IP=10.10.10.10:53558 (IP=0.0.0.0:636) 2023-06-16T12:53:12.039643+02:00 tst1 slapd[1333]: conn=1016 fd=28 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.3 tls_cipher=TLS_AES_128_GCM_SHA256 2023-06-16T12:53:12.039773+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND dn="cn=test,ou=users,dc=foo,dc=bar" method=128 2023-06-16T12:53:12.039841+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND dn="cn=test,ou=users,dc=foo,dc=bar" mech=SIMPLE bind_ssf=0 ssf=128 2023-06-16T12:53:12.041918+02:00 tst1 slapd[1333]: conn=1016 op=0 RESULT tag=97 err=0 qtime=0.000014 etime=0.002242 text= 2023-06-16T12:53:30.488074+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD dn="cn=test,ou=users,dc=foo,dc=bar" 2023-06-16T12:53:30.488474+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD attr=description 2023-06-16T12:53:30.557458+02:00 tst1 slapd[1333]: conn=1016 op=1 RESULT tag=103 err=0 qtime=0.000022 etime=0.069664 text= 2023-06-16T12:53:33.035486+02:00 tst1 slapd[1333]: conn=1016 fd=28 closed (connection lost) Running the above command from another machine results in a Insufficient access (50) error as also expected. So I assume the ACLs to be working correctly. If I run slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar on the system with ip 10.10.10.10 I get the following output: PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "DC" inserted. authcDN: "cn=test,ou=users,dc=foo,dc=bar" entry: none(=0) children: none(=0) description=test: none(=0) cn=test: none(=0) sn=test: none(=0) objectClass=person: none(=0) objectClass=top: none(=0) structuralObjectClass=person: none(=0) entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: none(=0) creatorsName=cn=manager,dc=foo,dc=bar: none(=0) createTimestamp=20230227131940Z: none(=0) userPassword=****: none(=0) pwdChangedTime=20230227131959Z: none(=0) authTimestamp=20230616065542Z: none(=0) pwdLastSuccess=20230616103806Z: none(=0) entryCSN=20230616103806.257186Z#000000#000#000000: none(=0) modifiersName=cn=test,ou=users,dc=foo,dc=bar: none(=0) modifyTimestamp=20230616103806Z: none(=0) I expected to see write access in slapacl's output. If I remove the 'peername.ip="10.10.10.10"' part from olcAccess {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by * none the above slapacl command outputs write access correctly no matter if the parameter '-o peername=10.10.10.10' is set or not. olcAccess: {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" write by * none {1}to * by group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by * none break {2}to * by self read by anonymous auth by * none break slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "DC" inserted. authcDN: "cn=test,ou=users,dc=foo,dc=bar" entry: write(=wrscxd) children: write(=wrscxd) description=first test cn=test: write(=wrscxd) sn=test: write(=wrscxd) objectClass=person: write(=wrscxd) objectClass=top: write(=wrscxd) structuralObjectClass=person: write(=wrscxd) entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: write(=wrscxd) creatorsName=cn=manager,dc=foo,dc=bar: write(=wrscxd) createTimestamp=20230227131940Z: write(=wrscxd) userPassword=****: write(=wrscxd) pwdChangedTime=20230227131959Z: write(=wrscxd) authTimestamp=20230616065542Z: write(=wrscxd) pwdLastSuccess=20230616105312Z: write(=wrscxd) entryCSN=20230616105330.487886Z#000000#000#000000: write(=wrscxd) modifiersName=cn=test,ou=users,dc=foo,dc=bar: write(=wrscxd) modifyTimestamp=20230616105330Z: write(=wrscxd) Am I doing something wrong? Any help is appreciated. Thanks, Carsten

2 1

Re: What drives CPU usage spikes?
by Erik de Waard 26 Jun '23

26 Jun '23

I see this on our consumers when waiting on writes to be accepted by the provider/ or when it's unreachable.

2 1

Re: unable to authenticate, ldaps
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

Hi, I was preparing some more logging to show. You were *really* quick in your reply! :-) Below more logging, and I will reply to your ACL question next. Replication after setting the password: Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 ACCEPT from IP= 192.168.16.36:45316 (IP=0.0.0.0:636) Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384 Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 closed (connection lost) Jun 26 16:36:09 ldapserver1 slapd[409642]: do_syncrep2: rid=234 cookie=rid=234,sid=0dd,csn=20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_message_to_entry: rid=234 DN: uid=testuser,ou=Users,o=ldap,c=com, UUID: a8ccf30a-88d0-103d-8b70-5f35ddf1cc44 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20230626143609.891703Z#000000#0dd#000000 tid 0x7f68a6afd640 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 be_search (0) Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 uid=testuser,ou=Users,o=ldap,c=com Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing 0x7f689c10e190 20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com on opc=0x7f689c008f90 Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_matchops: skipping original sid 0dd Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_matchops: skipping original sid 0dd Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn: removing 0x7f689c10e190 20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 be_modify uid=testuser,ou=Users,o=ldap,c=com (0) Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing 0x7f689c10a010 20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn: removing 0x7f689c10a010 20230626143609.891703Z#000000#0dd#000000 Failed authentication using the correct password: Jun 26 16:36:26 ldapserver1 slapd[409642]: conn=1164 fd=17 ACCEPT from IP= 192.168.16.36:46196 (IP=0.0.0.0:636) Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 BIND dn="uid=testuser,ou=Users,o=ldap,c=com" method=128 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 syncprov_matchops: recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com on opc=0x7f689c008ed0 Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_get_csn: conn=1164 op=0 generated new csn=20230626143627.270437Z#000000#0de#000000 manage=1 Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_queue_csn: queueing 0x7f689c110220 20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_qresp: set up a new syncres mode=2 csn=20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_graduate_commit_csn: removing 0x7f689c110220 20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_sendresp: to=0dd, cookie=rid=243,sid=0de,csn=20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_sendresp: sending LDAP_SYNC_MODIFY, dn=uid=testuser,ou=Users,o=ldap,c=com Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 RESULT tag=97 err=49 qtime=0.000015 etime=0.001002 text= Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=1 UNBIND Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 closed On Mon, 26 Jun 2023 at 16:36, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, June 26, 2023 5:28 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi all! > > > > > > We have this in place:olcAccess: {1}to attrs=userpassword by anonymous > > auth by * none break > > It's impossible to answer this question without knowing the rest of your > ACLs. For example the acl in slot {0} could mean that the acl in slot {1} > is never evaluated. > > --Quanah > > > >

2 2

unable to authenticate, ldaps
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

Hi all! We have this in place: olcAccess: {1}to attrs=userpassword by anonymous auth by * none break Using the RootDN to set a user password: # ldappasswd -H ldaps://my.ldapserver1.com -D "cn=admin,o=ldap,c=com" -W -S "uid=testuser,ou=Users,o=ldap,c=com" -v New password: <newpassword> Re-enter new password: <newpassword> Enter LDAP Password: <very_secret_and_difficult> ldap_initialize( ldaps://my.ldapserver1.com:636/??base ) Enter LDAP Password: Result: Success (0) We observe the password change replicate (master-master) to our other server. Then to test access: # ldapsearch -H ldaps://my.ldapserver1.com -s base -b o=ldap,c=com -D "uid=testuser,ou=Users,o=ldap,c=com" -w <newpassword> -v ldap_initialize( ldaps://my.ldapserver1.com:636/??base ) ldap_bind: Invalid credentials (49) More background: this is fresh a master-master setup, replication works with the root DN, and all other user authentications fails with the same Invalid credentials (49) The server ldaps://my.ldapserver1.com is an actual single (master) server, no load balancers, no firewalling. Configured an with actual (and valid) certificate, ldapsearch uses the correct CA, and ldapsearch with the root DN works fine. This is latest symas openldap 2.5 on RHEL9. Anyone with an idea why we can only authenticate as the RootDN, and all other authentications give Invalid credentials (49)? We have double checked whatever we can think of, and are *really* unsure what is going on.... Hoping for some clues from the experts here :-)

2 1

RE: Queries regarding Openldap migration from 2.6.2 to 2.6.4
by Quanah Gibson-Mount 23 Jun '23

23 Jun '23

--On Friday, June 23, 2023 2:19 PM +0000 "Sudarshan Sutar (EXT-NSB)" <sudarshan.sutar.ext(a)nokia-sbell.com> wrote: > > > Hi Team > > > Currently we are using openldap 2.6.2 and we want to upgrade it to latest > openldap i.e 2.6.4. So, is there any patch file available that can be > applied directly on to openldap 2.6.2 code base on our build machine ? > Or do I have to take the changes manually from below link ? Hello, a) Stop emailing openldap-technical-owner(a)openldap.org b) stop CCing people at your work This is not how you do proper software deployments/management. I would again *strongly* advise that if you are unable to generate properly packaged software that you use any of the freely available options I already listed. The correct way to get the source for a given release for building a new version is to download the source for the current release from: https://www.openldap.org/ Regards, Quanah

1 0

architectural question on master-slave vs multi-master
by cYuSeDfZfb cYuSeDfZfb 22 Jun '23

22 Jun '23

Hi, As you have already may have discovered by my many posts lately, we're busy with our ldap environment, and migrating from openldap 2.4 (bdb/RHEL7) to 2.5 on mbd/RHEL9. We've always had a duo of masters, replicating to a (READ ONLY) duo of slaves. All clients are configured to talk to the slaves, through a load balancer, and the masters pretty much only receive updates to the DIT from IdM. Our problem is: how to handle failed authentications (ppolicy) considering that the slaves are read-only and the slaves is where the failed authentications take place. Hence, my request for feedback: is master-slave still considered "the best way" of doing this? And then, is there a "standard way" to handle failed authentications on read-only slaves? Or perhaps... is it nowadays better to chose for a simpler multi-master (4 hosts) LDAP setup: four identical servers, where we choose to send clients to two specific servers (firewalled differently to handle client access) and two others to receive updates from IdM, but use multi-master replication so that all changes (either from IdM, or from failed authentications) are replicated equally between all four servers. Seems that new approach is much simpler. Any feedback? What is wise?

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical June 2023