openldap-technical April 2025

openldap-technical@openldap.org

7 participants
9 discussions

opt attribute oathHMACAlgorithm
by Stefan Kania 23 Apr '25

23 Apr '25

Hi to all, I would like to add the otp-attributes with the following LDIF: --------------- dn: ou=users,dc=example,dc=net changetype: modify add: objectClass objectClass: oathTOTPParams - add: oathOTPLength oathOTPLength: 6 - add: oathHMACAlgorithm oathHMACAlgorithm: 1.2.840.113549.2.11 - add: oathTOTPTimeStepPeriod oathTOTPTimeStepPeriod: 30 - add: oathTOTPTimeStepWindow oathTOTPTimeStepWindow: 3 --------------- But I'm getting: ----------- modifying entry "ou=users,dc=example,dc=net" ldap_modify: Invalid syntax (21) additional info: oathHMACAlgorithm: value #0 invalid per syntax ----------- If I switch to SHA1: ----------- oathHMACAlgorithm: 1.2.840.113549.2.7 ----------- it works. The manpage is telling me: ----------- oathHMACAlgorithm: <OID> The OID of the hash algorithm to use as defined in RFC 8018. Supported algorithms include SHA1, SHA224, SHA256, SHA384 and SHA512. ----------- and .11 is SHA512. Why is it not working? Do I have to give the OID in a different way? Stefan

3 4

slapcat compains "scheme not available" after using "olcPasswordHash: sha256"
by Windl, Ulrich 23 Apr '25

23 Apr '25

Hi! Using OpenLDAP 2.5 from SLES15 SP6 I added "olcPasswordHash: sha256" ("olcPasswordHash: {sha256}") to cn=config (I wanted to add it to the {-1}frontend database, but slapd refused. I was able to set {SHA256} RootPWs, but now when I try slapcat, I get an error saying: slapcat -n0 olcPasswordHash: value #0: <olcPasswordHash> scheme not available ({SSHA256}) olcPasswordHash: value #0: <olcPasswordHash> no valid hashes found config error processing cn=config: <olcPasswordHash> no valid hashes found slapcat: bad configuration file! For slapppasswd I can use option "-o module-load=pw-sha2", but slapcat does not have it: # slapcat -o module-load=pw-sha2 -n0 usage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]] [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] Is it my error, or slapcat's? Regards, Ulrich

2 2

Adding syncprov overlay to cn=config seems to freeze the server
by Windl, Ulrich 22 Apr '25

22 Apr '25

Hi! I'm trying to script a reconfiguration of out OpenLDAP servers, also changing the replication details. After dropping the old syncrepl overlay, I tried to add a new one like this: dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig I deliberately did not add more specific attributes, because I wanted to add them later. However I forgot to set olcOverlay. The point is that both, ldapmodify and slapd become unresponsive using that LDIF, at least when provided as ldapmodify -Y EXTERNAL -H ldapi:/// <<LDIF ... LDIF Is this a bug? Seen in OpenLDAP 2.5 provided by SLES15 SP6. From a coredump I forced, I see that the threads are all waiting, using one of these: __pthread_clockjoin_ex pthread_cond_wait __pthread_clockjoin_ex Kind regards, Ulrich Windl

2 4

Search performance pretty bad when result from index > 1
by Norbert 17 Apr '25

17 Apr '25

Hi, Used version 2.5.19.1 (ltb) We have a LDAP with about 4.6 million entries and an indexed attribute which occurs around 3.9 million times. We typicall filter for that attribute with a specific value (eq). Which is typicall very fast and no problems. As soon as the same value used twice the execution time for that filter is becoming really slow even when additional criteria of the filter limits the result to exact 1 entry. Search time is at ~5% for single entry results compared to potential 2 entry results. Some more details how this was determined: 1) enable "stats" logging on production server for 5 minutes. 2) collect the slowest ~1200 from several thousand searches within the 5 minutes from the log 3) create a separate ldap server with exact same data and configuration (imported with slapadd) 4) use a script running locally on the extra server which executes the 1200 filters one after the other and measure complete execution time of script With production data I measure around 11s for the ~1200 searches. For all these searches one attribute in the filter could have 2 hits, but it is actually limited to 1 hit because of following filter "(&(objectClass=value)(almost_uniqe_attr=value)(another_attr=*))" Means searching with only "almost_uniqe_attr=value" as filter it would return 2 results, but objectClass and another_attr limit it to exact 1 entry. When I now remove the second entry from the ldap server for these exact ~1200 filters the script run time will be ~0.5s . If re-add those ~1200 entries the runtime will be around 5s (and with a complete recreate of the db it will be 11s again.) Limiting the search scope by using a more specific base dn for the search does not change anything in regards to the execution time. So the question is: 1) can I change anything on the server side to speed up the execution time of these searches? Regards, Norbert

3 8

openldap 2.5: core dump in slap_tool_update_ctxcsn_check of lsapmodify when deleting syncprov overlay
by Windl, Ulrich 16 Apr '25

16 Apr '25

Hi! I'm trying to batch-convert an openLDAP 2.4 MMR configuration to an configuration using openLDAP 2.5, also using MMR, but on different hosts (SLES15 SP6 on x86_64). When my script tried to drop the syncprov overlay, slapmodify dumps core in function slap_tool_update_ctxcsn_check, like this: kernel: slapmodify[24757]: segfault at 28 ip 000055d656ea7526 sp 00007ffe9e0875f0 error 4 in slapd[55d656dea000+149000] likely on CPU 1 (core 0, socket 2) kernel: Code: 48 33 0c 25 28 00 00 00 48 c7 c0 ff ff ff ff 0f 85 74 01 00 00 48 83 c4 28 5b 5d 41 5c 41 5d c3 0f 1f 40 00 49 89 fd 48 89 f3 <48> 8b 7e 28 48 8b 35 cf fa 09 00 e8 1a f5 f8 ff 48 85 c0... Dump of assembler code for function slap_tool_update_ctxcsn_check: 0x000055d656ea74d0 <+0>: push %r13 0x000055d656ea74d2 <+2>: push %r12 0x000055d656ea74d4 <+4>: push %rbp 0x000055d656ea74d5 <+5>: push %rbx 0x000055d656ea74d6 <+6>: sub $0x28,%rsp 0x000055d656ea74da <+10>: mov 0x9fdd3(%rip),%r8d # 0x55d656f472b4 <tool_globals+20> 0x000055d656ea74e1 <+17>: mov %fs:0x28,%rax 0x000055d656ea74ea <+26>: mov %rax,0x18(%rsp) 0x000055d656ea74ef <+31>: xor %eax,%eax 0x000055d656ea74f1 <+33>: test %r8d,%r8d 0x000055d656ea74f4 <+36>: jne 0x55d656ea7520 <slap_tool_update_ctxcsn_check+80> 0x000055d656ea74f6 <+38>: mov 0x18(%rsp),%rcx 0x000055d656ea74fb <+43>: xor %fs:0x28,%rcx 0x000055d656ea7504 <+52>: mov $0xffffffffffffffff,%rax 0x000055d656ea750b <+59>: jne 0x55d656ea7685 <slap_tool_update_ctxcsn_check+437> 0x000055d656ea7511 <+65>: add $0x28,%rsp 0x000055d656ea7515 <+69>: pop %rbx 0x000055d656ea7516 <+70>: pop %rbp 0x000055d656ea7517 <+71>: pop %r12 0x000055d656ea7519 <+73>: pop %r13 0x000055d656ea751b <+75>: ret 0x000055d656ea751c <+76>: nopl 0x0(%rax) 0x000055d656ea7520 <+80>: mov %rdi,%r13 0x000055d656ea7523 <+83>: mov %rsi,%rbx => 0x000055d656ea7526 <+86>: mov 0x28(%rsi),%rdi 0x000055d656ea752a <+90>: mov 0x9facf(%rip),%rsi # 0x55d656f47000 <slap_schema+192> 0x000055d656ea7531 <+97>: call 0x55d656e36a50 <attr_find> ... Slapmodify had been started with "slapmodify -F /etc/openldap/slapd.d -g -n0 -S 5 -w", and the input was: dn: olcOverlay= {0}syncprov, olcDatabase={0}config,cn=config changetype: delete The version I'm using was provided by SLES support as openldap2_5-2.5.18+31-150500.11.12.1.29527.34.PTF.1239787.x86_64 If I run slapmodify without "-w", no core dump happens. Kind regards, Ulrich Windl

2 1

Using olcAuthRegexpr with Kerberos principalname
by Stefan Kania 14 Apr '25

14 Apr '25

Hi all, I want to rewrite the gssapi user name after authentication using olcAuthzRegex, but I want to rewrite the krbPrincipalName. If a principal is getting a ticket and then test the authentication with "ldapwhoami" I see: uid=my-principal,cn=gssapi,cn=auth So now I want to rewrite the uid to: krbPrincipalName=my-principal@REALM,cn=REALM,cn=kerberos,dc=example,dc=net the real object name. My first try was olcAuthzRegexp: {0}uid=(.+),cn=gssapi,cn=auth krbPrincipalName=$1@REALM,cn=REALM,cn=kerberos,dc=example,dc=net That is working. Now "ldapwhoami" is showing krbPrincipalName=my-principal@REALM,cn=realm,cn=kerbers,dc=example,dc=net then I changed olcAuthzRegexp to uid=(.+),cn=gssapi,cn=auth ldap:///cn=kerberos,dc=example,dc=net??sub?(krbPrincipalName=$1@REALM) I also tried: (krbPrincipalName=$1) (krbPrincipalName=$1@REALM,cn=REALM,cn=kerberos,dc=example,dc=net) but non of the filters is working. How do I have to configure the filter to rewrite the krbPrincipalName with in the search? Stefan

2 2

Usage of slapo-constraint to ensure existence of object
by Adrian Nöthlich 14 Apr '25

14 Apr '25

Hello all, we want to ensure that all entries added to the member and manager attributes are valid DNs and point to existing objects in our LDAP. We had the refint overlay do this on version 2.2 but as it seems 2.3 removed this undocumented feature. We lately moved to 2.5 and have issues with faulty entries. When I tried to configure the overlay with: olcConstraintAttribute: member uri ldap:///dc=example,dc=com?dn?sub?(objectClass=*) or olcConstraintAttribute: member uri ldap:///dc=example,dc=com??sub?(objectClass=*) or both URIs with an actual objectClass specified, my slapd (2.5.19) crashes on the URI verification step as it seems. Is my usage of the overlay itself correct (including the URI) or is there a better way to ensure the existence of an referenced object? Thanks a lot! Best, Adrian

2 2

Message "slapd[2734]: config error processing olcDatabase={0}config,cn=config: <olcMultiProvider> database is not a shadow"
by Windl, Ulrich 09 Apr '25

09 Apr '25

Hi! While setting up an OpenLDAP-2.5-based MMR configuration I had set up the master node, then dumped the config database, copied the LDIF to the other node. However when starting slapd, it failed with the message slapd[2734]: config error processing olcDatabase={0}config,cn=config: <olcMultiProvider> database is not a shadow See also https://stackoverflow.com/q/6792212/6607497 The context of olcMultiProvider is: dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config ... olcMultiProvider: TRUE On the first node I had updated the config using this LDIF: dn: olcDatabase=${db},cn=config changetype: modify delete: olcMirrorMode olcMirrorMode: TRUE - add: olcMultiProvider olcMultiProvider: TRUE So I don't understand why this won't work on the second node. Specifically I can restart the first node without an issue. The only difference is that the primary node has a patch against crashing on an invalid olcAuthzRegexp (I had reported). Well can anybody explain what this message means? Update: Reading https://www.openldap.com/lists/openldap-technical/201807/msg00051.html ("Do you have a unique olcServerID set in cn=config for both masters")I realized that I forgot to specify "-S SID" for slapadd. Unfortunately even after using option -S, the error message remains the same. Kind regards, Ulrich Windl

2 2

Q: "olcDatabase: {1}mdb" from slapcat: why "{1}"?
by Windl, Ulrich 03 Apr '25

03 Apr '25

I have an amost philosophical question about LDIF and OenLDAP: Considering dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb # ... I wonder why olcDatabase needs the "{1}" when olcDatabase is a single-valued attribute. I understand that "olcDatabase={1}mdb" is needed for ordering the databases within cn=config, But why is the "{1}" repeated for the actual attribute? When I tried to remove it, I saw that after a slapcat it's there again. Kind regards, Ulrich

2 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2025