openldap-technical

openldap-technical@openldap.org

6 participants
9858 discussions

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

Re: migration 2.4 -> 2.5 (bdb -> mdb) | monitoring & health checks
by cYuSeDfZfb cYuSeDfZfb 22 Jun '23

22 Jun '23

Hi Quanah, Thanks for your answer and kind suggestions! We will implement them. And anyone here using zabbix, and has some scripting for monitoring laying around..? Thanks! On Fri, 16 Jun 2023 at 16:42, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, June 15, 2023 10:51 PM +0200 sacawulu <cyusedfzfb(a)gmail.com> > > wrote: > > > > Most of these things can be done similarly in 2.4/bdb and 2.5/mbd but not > > the db_verify, which is bdb specific. > > > > I don't find a lot of info on the maintenance / integrity checks that can > > be done on mdb databases. In fact: Mostly what I can find is: "MDB uses > > no caching and requires no tuning to deliver maximum search performance" > > There's very little necessary to be done when using back-mdb as you've > already discovered > > > That is very good. :-) We have already discovered that we need to > > increase maxsize, as our database is (much) larger than 10MB. > > The rule of thumb for maxsize is to set it to something larger than you > ever expect to hit. For example, with a database I'm using that's ~3.4GB > in size, I have a 20GB maxsize set. You may want to monitor the size of > your database vs the configured maxsize. This can be done with data > available in the back-monitor database (at least with 2.6, not sure with > 2.5) or via the mdb_stat utility. > > python-ldap3 snippet using back-monitor: > > try: > tls = Tls(validate=ssl.CERT_NONE, version=ssl.PROTOCOL_TLSv1_2) > conn = Connection(Server(ldap_url, tls=tls, use_ssl=True), > auto_bind=True) > conn.search( > "cn=monitor", > "(&(objectClass=olmMDBDatabase))", > attributes=["olmMDBPagesMax", "olmMDBPagesUsed", > "namingContexts"], > ) > > for db in conn.entries: > suffix = db.namingContexts.value > # 4096 is the page size in use > # can be found with mdb_stat -e /path/to/database > max_size = int(db.olmMDBPagesMax.value) * 4096 > current_size = int(db.olmMDBPagesUsed.value) * 4096 > pct_used = float(current_size / max_size * 100) > > > > > Anyone else with tips and tricks on daily maintenance or monitoring? > > Scripts to share..? Perhaps zabbix templates..? > > The only other bits I would recommend is if you have object in the > directory that have very large multi-valued attribute data. For example, > if you use groups extensively, and the 'member' attribute has hundreds of > entries, you would probably want to do something like: > > a) Add member as an attribute to be handled by olcSortvals > > b) Add a multival configuration to back-mdb if the attribute is indexed. > For example, if you indexed member "eq". I usually do 100,10. This will > put the index databse into its own subdb, which helps keep fragmentation > from being an issue. > > For example, I had a ~5.5GB DB that was swelling to over 11GB in size due > to fragmentation before implementing those two configuration options. > > > Regards, > Quanah > > > >

2 2

Data migration
by Jean-Luc Chandezon 16 Jun '23

16 Jun '23

Hello dear community, I have to migrate our ldap database from OpenLDAP (from 2019 version hosted on Debian, to Symas OpenLDAP 2.4.59 on ). I need to change our DN from "dc=lexp,dc=fr" to "dc=directory,dc=lan-explore,dc=fr". I installed OpenLDAP and configure directory with new DN. For data migration, I exported data: slapcat -b dc=lexp,dc=fr > /tmp/20230616_save_data.ldif .. and for recovery, I changed all dn mentions from old to new dn. 1. Is the correct way? When import, you can see error message: slapadd: slap_init invalid suffix ("dc=directory,dc=lan-explore,dc=fr ") 2. When searching, I discovered that each line can contains 77 columns. Next, line is truncated, and it's difficult to replace all dn. Thanks, Jean-Luc

4 4

migration 2.4 -> 2.5 (bdb -> mdb) | monitoring & health checks
by sacawulu 16 Jun '23

16 Jun '23

Hi, We are in the middle of a move from 2.4/bdb to 2.5/mdb, and I am working on implementing monitoring for the new systems. In the 2.4/bdb environment, we run several scripts to check sanity of the servers: * checks of the contextCSN value across the masters/slaves * regular db_verify on the actual bdb files * compare all DN & entryCSN in the DB across all the masters/slaves * do a write on a master, and verify that it is replicated everywhere Most of these things can be done similarly in 2.4/bdb and 2.5/mbd but not the db_verify, which is bdb specific. I don't find a lot of info on the maintenance / integrity checks that can be done on mdb databases. In fact: Mostly what I can find is: "MDB uses no caching and requires no tuning to deliver maximum search performance" That is very good. :-) We have already discovered that we need to increase maxsize, as our database is (much) larger than 10MB. Two questions: - Is there really nothing else to tune or adjust? - Is there really no way to verify the internal structures within the MDB file, to make sure everything is valid and healthy? Perhaps things I have missed with our four checks above? Anyone else with tips and tricks on daily maintenance or monitoring? Scripts to share..? Perhaps zabbix templates..? If anyone would be interested in (for example) my script to verify the complete directory contents based on DN&entryCSN across a (multi)master/(multi)slave setup, I'd be happy to share too, of course. Thanks!

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical