November 2021 - openldap-technical

by Mark Cairney

Hi, I've been out the LDAP loop for a bit but the recent discussion of the memberof overlay on 2.5 piqued my curiosity. Having upgraded a Dev box, removed the memberof elements from the database and replaced the memberof overlay with dynlist the queries appear to work as expected but are both a) slow and b) heavily CPU-intensive on the LDAP server. 2021-09-01T12:47:17.603513+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 ACCEPT from IP=192.168.152.33:58738 (IP=129.215.17.9:636) 2021-09-01T12:47:17.687488+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 2021-09-01T12:47:17.688032+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" 2021-09-01T12:47:17.688470+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SRCH attr=supportedSASLMechanisms 2021-09-01T12:47:17.688878+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000014 etime=0.000214 nentries=1 text= 2021-09-01T12:47:17.811279+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=1 BIND dn="" method=163 2021-09-01T12:47:17.819249+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=1 RESULT tag=97 err=14 qtime=0.000030 etime=0.009084 text=SASL(0): successful result: 2021-09-01T12:47:17.908889+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=2 BIND dn="" method=163 2021-09-01T12:47:17.909836+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=2 RESULT tag=97 err=14 qtime=0.000031 etime=0.000181 text=SASL(0): successful result: 2021-09-01T12:47:17.938839+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND dn="" method=163 2021-09-01T12:47:17.939621+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND authcid="mcairney(a)EASE.ED.AC.UK" authzid="mcairney(a)EASE.ED.AC.UK" 2021-09-01T12:47:17.940213+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND dn="uid=mcairney,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk" mech=GSSAPI bind_ssf=256 ssf=256 2021-09-01T12:47:17.940616+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 RESULT tag=97 err=0 qtime=0.000024 etime=0.000409 text= 2021-09-01T12:47:18.227342+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SRCH base="dc=authorise-dev,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=mcairney)" 2021-09-01T12:47:18.227703+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SRCH attr=* + 2021-09-01T12:47:31.392255+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=5 UNBIND 2021-09-01T12:47:31.460705+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SEARCH RESULT tag=101 err=0 qtime=0.000031 etime=13.233679 nentries=1 text= 2021-09-01T12:47:31.461098+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 closed I'm guessing that as the values are computed that this will be heavier on the CPU but it seems a bit excessive? Has anyone else noticed any similar performance issues? This is a relatively low-specced DEV server (2 vCPUs, 4GB RAM) so I guess this could be a factor but there's no io waiting on the server and no swapping? The database is on a par in size with our Production service ( about 400K user objects with 1 group object per user and then about 80K actual groups of users) The config for the primary DB (ACLs and rootPW redacted) is: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /opt/openldap/var/openldap-data/authorise olcSuffix: dc=authorise-dev,dc=ed,dc=ac,dc=uk olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 2 olcReadOnly: FALSE olcSecurity: ssf=1 olcSecurity: update_ssf=112 olcSecurity: simple_bind=64 olcSizeLimit: unlimited olcSyncUseSubentry: FALSE olcTimeLimit: unlimited olcMonitoring: TRUE olcDbEnvFlags: writemap olcDbEnvFlags: nometasync olcDbNoSync: FALSE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: eduniType eq olcDbIndex: gecos pres,eq,sub olcDbIndex: eduniCategory eq olcDbIndex: mail pres,eq,sub olcDbIndex: eduniSchoolCode eq olcDbIndex: eduniIDStatus eq olcDbIndex: eduniCollegeCode eq olcDbIndex: eduniOrgCode eq olcDbIndex: memberOf pres,eq olcDbIndex: eduniLibraryBarcode pres,eq olcDbIndex: eduniOrganisation pres,eq,sub olcDbIndex: eduniServiceCode pres,eq olcDbIndex: krbName pres,eq olcDbIndex: eduPersonAffiliation pres,eq olcDbIndex: eduPersonEntitlement pres,eq olcDbIndex: sn pres,eq,sub olcDbIndex: eduniIdmsId pres,eq olcDbIndex: member pres,eq olcDbIndex: memberUid pres,eq olcDbIndex: eduniRefNo pres,eq olcDbIndex: eduniTitle pres,eq olcDbIndex: title pres,eq,sub olcDbIndex: eduniCardNumber pres,eq olcDbIndex: eduniYearOfStudy eq olcDbIndex: description pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: aliasedObjectName eq olcDbIndex: yubiKeyId pres,eq olcDbIndex: isMemberOf pres,eq olcDbIndex: hasMember pres,eq olcDbIndex: proxyAddresses pres,eq,sub olcDbMaxReaders: 96 olcDbMaxSize: 32212254720 olcDbMode: 0600 olcDbSearchStack: 16 structuralObjectClass: olcMdbConfig dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 02+00:00 00+04:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynListConfig olcOverlay: {2}dynlist olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames structuralObjectClass: olcDynListConfig -- /**************************** Mark Cairney ITI Enterprise Services Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

4 months, 4 weeks

12
27
0 / 0

OpenLDAP 2.6.0 testing call #3

by Quanah Gibson-Mount

This is the third testing call for OpenLDAP 2.6.0 Release. This is expected to be the final testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6...> 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. A list of items fixed and added in 2.6 can be found at: <https://bugs.openldap.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERI...> A major change with 2.6 is the optional ability to bypass syslog for logging (ITS#6949). This significantly improves slapd and lloadd performance. Additionally, the following deprecated backends have been removed: back-ndb back-shell Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 year, 5 months

2
2
0 / 0

2.6 rhel8 rpm pkg - lastbind module issue

by Dave Macias

Hello, Playing around with 2.6 Was attempting to add lastbind module but get error: cat <<EOF | ldapadd -D cn=config -w mysecret dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /opt/symas/lib/openldap/ olcModuleLoad: lastbind.la EOF adding new entry "cn=module,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcModuleLoad> handler exited with 1 I have no issues doing the above with 2.5 rpm rhel8 pkg. Is there something im doing wrong? Any input is appreciated. Thank you, Dave

1 year, 6 months

4
10
0 / 0

force resync of slave

by Enrico Weigelt, metux IT consult

Hello friends, I've encountered my slaves (Zimbra cluster) aren't fully in sync with master. Some entries are missing attributes. Maybe it's a fallout from previous errors in my MMR setup (several minutes clocks difference, so one master couldn't sync to another). * modifying an affected entry doesn't fix it, just changes the actually changed attributes (delta-sync ?) * starting the slave w/ -c 'rid=100,csn=0' showed lots of corresponding log traffic (on first start), but still tells the entries were equal, doesn't fix the entries * problem: I don't know which entries are affect, just found a few of them Can anyone give me a hint on how to do a full resync ? thx --mtx -- --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info(a)metux.net -- +49-151-27565287

1 year, 6 months

2
1
0 / 0

ppolicy-question

by A. Schulze

Hello, using slapo-ppolicy I could configure slapd to hash a password if it's sent unhashed. moduleload ppolicy.la moduleload argon2.la password-hash {ARGON2} database mdb suffix dc=test ... overlay ppolicy ppolicy_default "cn=default,ou=ppolicies,dc=test" ppolicy_hash_cleartext That work and I could hash them using ARGON2. But clients could still hash a password them self and write '{MD5}...' as userPassword for example. Is it possible to reject any userPasswords prefixed with hash schema? Andreas

1 year, 6 months

4
6
0 / 0

Multi-Master not syncing

by Enrico Weigelt, metux IT consult

Hello friends, I'm in huge trouble: my MMR setup (Zimbra) isn't syncing completely. * host A is the old master, host B a new one. * host B used to be a slave of A, but later was promoted to master (each has a syncrepl pointer to the other and mirrormode is TRUE) * sync from A to B seems to be fine, but the route back doesn't work * new objects (eg. new users) are synced up from B to A, but later changes don't get throught (eg. additional entries like mail aliases) On host B i get lots of repeated log messages like this: Nov 30 09:56:04 hz1-rz-mail-ldap-01 slapd[3999428]: conn=6002 op=1 syncprov_search_response: Entry uid=u37701,ou=people,dc=hs-harz,dc=de CSN 20211129215211.258933Z#000000#001#000000 older or equal to ctx 20211130085608.894386Z#000000#001#000000 On Host A I'm getting lots of log messages like this: Nov 30 10:12:38 inkataube slapd[17590]: dn_callback : new entry is older than ours uid=g50425,ou=people,dc=hs-harz,dc=de ours 20211130032044.897539Z#000000#001#000000, new 20211130032015.857165Z#000000#002#000000 It looks like both nodes can't agree on what's the most recent entries. Is there any way to force them taking either side's version ? thanks --mtx --- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info(a)metux.net -- +49-151-27565287

1 year, 6 months

2
1
0 / 0

symas gpg-key

by Stefan Kania

I installed the symas OpenLDAP 2.6. The first step was getting the gpg-key but the command on your web-page is : ---------------- root@ldap:~# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys DA26A148887DCBEB Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)). ---------------- is deprecated on debian 11. Do you provide a the key in .asc format so the key can be installed via: ---------------- wget -O- https://some-server.com/symas.gpg-key.asc | gpg --dearmor | tee /etc/apt/trusted.gpg.d/symas.gpg > /dev/null ---------------- If you do, where can I find it? If not, could you provide it? :-) Stefan

1 year, 6 months

2
2
0 / 0

delta-sync how to make sure

by frederic.goudal＠bordeaux-inp.fr

Hello, I have setup delta-sync replication on my servers, but how can I be sure it is used instead of just syncrepl ? What do I have to look at into the logs ? Thanks in advance -- Frédéric Goudal Administrateur Systèmes et Réseaux Bordeaux-INP

1 year, 6 months

1
0
0 / 0

how to build dynacl now.c?

by Michael Ströder

HI! Hmm, I cannot see what I'm doing wrong here. Compiling other contrib modules works just fine. $ make -B -C contrib/slapd-modules/acl now make: Entering directory '/home/michael/src/openldap-git/re26/openldap/contrib/slapd-modules/acl' gcc now.c -o now now.c:28:10: fatal error: portable.h: No such file or directory 28 | #include <portable.h> | ^~~~~~~~~~~~ compilation terminated. make: *** [<builtin>: now] Error 1 make: Leaving directory '/home/michael/src/openldap-git/re26/openldap/contrib/slapd-modules/acl' Ciao, Michael.

1 year, 6 months

2
2
0 / 0

Problem with attribute hasSubordinate

by frederic.goudal＠bordeaux-inp.fr

Hello, I'm upgrading an old ldap set of servers to a new one, going from 2.4.x to 2.6.0 What I'm currently doing is the following : old.2.4 <- multi-master syncrepl -> newMaster -> push-setup + delta-sync -> newSlave What I call push-setup is a hidden sufix on newMaster with newSlsave as ldap backend. The synchronisations occurs, but stop for now on the following error : Nov 23 14:47:47 ldap2021 slapd[57592]: conn=1000 op=662328 SRCH base="dc=ipb,dc=fr" scope=2 deref=0 filter="(entryUUID=d62c8932-e9aa-1034-9374-673a87a89e29)" Nov 23 14:47:47 ldap2021 slapd[57592]: conn=1000 op=662328 SRCH attr=* + Nov 23 14:47:47 ldap2021 slapd[57592]: conn=1000 op=662328 SEARCH RESULT tag=101 err=0 qtime=0.000046 etime=0.000808 nentries=1 text= Nov 23 14:47:47 ldap2021 slapd[57592]: conn=1000 op=662329 MOD dn="uid=xxxx,ou=people,dc=ipb,dc=fr" Nov 23 14:47:47 ldap2021 slapd[57592]: conn=1000 op=662329 MOD attr=entryCSN modifiersName modifyTimestamp hasSubordinates Nov 23 14:47:47 ldap2021 slapd[57592]: slap_queue_csn: queueing 0x7efedc155f70 20211123133002.586780Z#000000#00a#000000 Nov 23 14:47:47 ldap2021 slapd[57592]: conn=1000 op=662329 RESULT tag=103 err=16 qtime=0.000029 etime=0.000405 text=modify/delete: hasSubordinates: no such attribute Nov 23 14:47:47 ldap2021 slapd[57592]: slap_graduate_commit_csn: removing 0x7efedc155f70 20211123133002.586780Z#000000#00a#000000 I have donne slapcat on the old server, and on the the newMaster and there is no attribute hasSubordinates. I have dumped the schema ( ldapsearch -x -LLL -b cn=Subschema -s base '(objectClass=subschema)' +) and the attribute hasSubordinatess is defined both on newMaster and newSlave. I don't know what to do to fix this problem... Thanks in advance. -- Frédéric Goudal Administrateur Systèmes et Réseaux Bordeaux-INP

1 year, 6 months

2
2
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2021