openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

Q: odd accesslog entry and unchanged attributes
by Windl, Ulrich 29 Apr '25

29 Apr '25

Hi! Debugging issues with my OpenLDAP configuration I inspected the changelog. One entry had some "odd" values (IMHO). Consider this example: dn: reqStart=20250423131324.000185Z,cn=audit objectClass: auditModify structuralObjectClass: auditModify reqStart: 20250423131324.000185Z reqEnd: 20250423131324.000188Z reqType: modify reqSession: 1024 reqAuthzID: cn=config reqDN: olcDatabase={4}mdb,cn=config reqResult: 0 reqMod: olcRootPW:= {SSHA256}REDACTED agNLQ== reqMod: entryCSN:= 20250423131324.377585Z#000000#005#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20250423131324Z reqOld: olcRootPW: REDACTED reqOld: entryCSN: 20250423131324.038419Z#000000#005#000000 reqOld: modifiersName: cn=config reqOld: modifyTimestamp: 20250423131324Z reqEntryUUID: 7b0b106c-b490-103f-8f46-3bae5e23549d entryUUID: 7b40af6a-b490-103f-8f7d-3bae5e23549d creatorsName: cn=audit createTimestamp: 20250423131324Z entryCSN: 20250423131324.377585Z#000000#005#000000 modifiersName: cn=audit modifyTimestamp: 20250423131324Z The change in entryCSN and modifyTimestamp are: OLD: 20250423131324.038419Z#000000#005#000000 NEW: 20250423131324.377585Z#000000#005#000000 OLD: 20250423131324Z NEW: 20250423131324Z So the change happened within the same second, and modifyTimestamp did not actually change. So the question is kind of philosophical: Are attibutes logged as changed when actually they did not change? This would apply to modifyTimestamp and modifyTimestamp in this case. Kind regards, Ulrich Windl

2 1

LDAP URI for slapcat -H
by Windl, Ulrich 29 Apr '25

29 Apr '25

Hi! After reading the manual of slapcat (for 2.5) it recommends using option -H and an URI instead of other obsolete options. So I tried it, but all I get is a usage message, even with "-v" and "-d9". Like this: # slapcat -d9 -H 'ldap:///?entryCSN?sub?(objectClass=*)' 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] However when I use # slapcat -H 'ldap://?entryCSN?dc=...,dc=de?sub?(objectClass=*)' I get output. The URI should be: scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION extensions]]]]] Do I have tomatoes on my eyes? Anyway I think slapcat could provide a better error message. Even an ltrace did not enlighten me: # ltrace slapcat -d9 -H 'ldap:///?entryCSN?sub?(objectClass=*)?' ber_set_option(0, 0x8002, 0x55ad287ce980, 0x7f7d383ff680) = 0 ldap_pvt_thread_initialize(0x7f7d3862c1c0, 0x55ad287ce980, 32, 0x55ad287ce980) = 0 ldap_create(0x55ad287d6a78, 0, 0, 0) = 0 ldap_pvt_tls_set_option(0x55ad56df1a50, 0x6006, 0x7ffd5d8d1f6c, 48) = 0 strrchr("slapcat", '/') = nil strcmp("slapcat", "slapd") = -1 strcmp("slapcat", "slapadd") = 2 strcmp("slapcat", "slapcat") = 0 ldap_set_option(0, 0x5001, 0x55ad287d12d0, 0x7ffd5d8d2158) = 0 getopt(4, 0x7ffd5d8d2158, "a:b:cd:f:F:gH:l:n:o:s:v") = 100 __ctype_b_loc() = 0x7f7d384c1d60 strtoul(0x7ffd5d8d36a9, 0x7ffd5d8d1bb0, 0, 0) = 9 getopt(4, 0x7ffd5d8d2158, "a:b:cd:f:F:gH:l:n:o:s:v") = 72 ldap_url_parse_ext(0x7ffd5d8d36ae, 0x7ffd5d8d1cb0, 5, 0) = 10 __fprintf_chk(0x7f7d384004e0, 1, 0x55ad2877a9f0, 0x55ad2875c4ddusage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]]) = 88 fputs(" [-c]\n\t[-g] [-n databasenumber |"..., 0x7f7d384004e0 [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] ) = 1 exit(1 <no return ...> +++ exited (status 1) +++ Kind regards, Ulrich Windl

2 3

SBOM required!
by Sahil Sharma D 29 Apr '25

29 Apr '25

Hi team, Could you please provide the SBOM for OpenLDAP version REL_ENG_2_6_4 , or advise me on where I can locate the SBOMs for all versions? Regards, Sahil

2 1

core dump when using olcSpSessionlogSource
by Windl, Ulrich 24 Apr '25

24 Apr '25

Hi! Configuring delta-syncrepl, I tried olcSpSessionlogSource instead of olcSPSessionlog. After slapd war started, it dumped core like this: … Apr 24 11:25:41 v05 slapd[5030]: syncprov_db_open: starting syncprov for suffix cn=config Apr 24 11:25:41 v05 slapd[5030]: conn=-1 op=0 syncprov_findcsn: mode=FIND_MAXCSN csn= Apr 24 11:25:41 v05 slapd[5030]: syncprov_db_open: starting syncprov for suffix dc=sap,dc=klinik,dc=uni-regensburg,dc=de Apr 24 11:25:41 v05 slapd[5030]: slapd starting Apr 24 11:25:41 v05 start[5017]: Starting ldap-server Apr 24 11:25:41 v05 systemd[1]: Started OpenLDAP Server Daemon. Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1000 op=1 generated new csn=20250424092541.888430Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a01217d0 20250424092541.888430Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a01217d0 20250424092541.888430Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5035]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1001 op=1 generated new csn=20250424092541.896113Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0122df0 20250424092541.896113Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: conn=1001 op=1 syncprov_checkpoint: running checkpoint Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0122df0 20250424092541.896113Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5037]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1002 op=1 generated new csn=20250424092541.900818Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0128240 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a012b820 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a012b820 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0128240 20250424092541.900818Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5039]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1003 op=1 generated new csn=20250424092541.920778Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c106d00 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c107760 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c107760 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c106d00 20250424092541.920778Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5041]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1004 op=1 generated new csn=20250424092541.937140Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c10c9f0 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd19c11c110 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c11c110 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd19c10c9f0 20250424092541.937140Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5043]: DIGEST-MD5 common mech free Apr 24 11:25:41 v05 slapd[5030]: slap_get_csn: conn=1005 op=1 generated new csn=20250424092541.989098Z#000000#005#000000 manage=1 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a012b920 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0107320 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0107320 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a012b920 20250424092541.989098Z#000000#005#000000 Apr 24 11:25:41 v05 ldapmodify[5044]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 slapd[5030]: slap_get_csn: conn=1006 op=1 generated new csn=20250424092542.004124Z#000000#005#000000 manage=1 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a01277f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: index objectClass 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index entryCSN 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqEnd 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqResult 0x0004 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a02376f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a02376f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a01277f0 20250424092542.004124Z#000000#005#000000 Apr 24 11:25:42 v05 ldapmodify[5046]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 slapd[5030]: slap_get_csn: conn=1007 op=1 generated new csn=20250424092542.020297Z#000000#005#000000 manage=1 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a010a230 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: index objectClass 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index entryCSN 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqEnd 0x0004 Apr 24 11:25:42 v05 slapd[5030]: index reqResult 0x0004 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0117770 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a0117770 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: slap_graduate_commit_csn: removing 0x7fd1a010a230 20250424092542.020297Z#000000#005#000000 Apr 24 11:25:42 v05 ldapmodify[5048]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 slapd[5030]: slap_get_csn: conn=1008 op=1 generated new csn=20250424092542.036954Z#000000#005#000000 manage=1 Apr 24 11:25:42 v05 slapd[5030]: slap_queue_csn: queueing 0x7fd1a0237570 20250424092542.036954Z#000000#005#000000 Apr 24 11:25:42 v05 slapd[5030]: syncprov_db_open: starting syncprov for suffix cn=changelog-0 Apr 24 11:25:42 v05 slapd[5030]: [71B blob data] Apr 24 11:25:42 v05 slapd[5030]: olcSpSessionlogSource: value #0: <olcSpSessionlogSource> failed startup (cn=changelog-0)! Apr 24 11:25:42 v05 systemd[1]: Started Process Core Dump (PID 5051/UID 0). Apr 24 11:25:42 v05 systemd-coredump[5052]: [🡕] Process 5030 (slapd) of user 1000 dumped core. Stack trace of thread 5034: #0 0x00007fd1b82a8dfc __pthread_kill_implementation (libc.so.6 + 0xa8dfc) #1 0x00007fd1b8257842 raise (libc.so.6 + 0x57842) #2 0x00007fd1b823f5cf abort (libc.so.6 + 0x3f5cf) #3 0x00007fd1b8240497 __libc_message.cold (libc.so.6 + 0x40497) #4 0x00007fd1b82b34b7 malloc_printerr (libc.so.6 + 0xb34b7) #5 0x00007fd1b82b5a69 _int_free (libc.so.6 + 0xb5a69) #6 0x00007fd1b82b81df free (libc.so.6 + 0xb81df) #7 0x00007fd1b8159bee n/a (syncprov.so + 0x3bee) #8 0x000056122f1a02ee overlay_destroy_one (slapd + 0xb82ee) #9 0x000056122f1156bd n/a (slapd + 0x2d6bd) #10 0x000056122f115fb0 n/a (slapd + 0x2dfb0) #11 0x000056122f19f533 overlay_op_walk (slapd + 0xb7533) #12 0x000056122f19f6be n/a (slapd + 0xb76be) #13 0x000056122f1319ad fe_op_add (slapd + 0x499ad) #14 0x000056122f1328d9 do_add (slapd + 0x4a8d9) #15 0x000056122f12b18f n/a (slapd + 0x4318f) #16 0x000056122f12b98d n/a (slapd + 0x4398d) #17 0x00007fd1b86bcda0 n/a (libldap-2.5.releng.so.0 + 0x48da0) #18 0x00007fd1b82a6f6c start_thread (libc.so.6 + 0xa6f6c) #19 0x00007fd1b832e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 5030: #0 0x00007fd1b82a3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007fd1b82a8b83 __pthread_clockjoin_ex (libc.so.6 + 0xa8b83) #2 0x000056122f1281ca slapd_daemon (slapd + 0x401ca) #3 0x000056122f10b88e main (slapd + 0x2388e) #4 0x00007fd1b8240e6c __libc_start_call_main (libc.so.6 + 0x40e6c) #5 0x00007fd1b8240f35 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x40f35) #6 0x000056122f10b90a _start (slapd + 0x2390a) Stack trace of thread 5038: #0 0x00007fd1b82a3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007fd1b82a6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007fd1b86bce40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fd1b82a6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007fd1b832e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 5032: #0 0x00007fd1b832e796 epoll_wait (libc.so.6 + 0x12e796) #1 0x000056122f12507b n/a (slapd + 0x3d07b) #2 0x00007fd1b82a6f6c start_thread (libc.so.6 + 0xa6f6c) #3 0x00007fd1b832e338 __clone3 (libc.so.6 + 0x12e338) ELF object binary architecture: AMD x86-64 Apr 24 11:25:42 v05 ldapmodify[5050]: DIGEST-MD5 common mech free Apr 24 11:25:42 v05 systemd[1]: slapd.service: Main process exited, code=dumped, status=6/ABRT Apr 24 11:25:42 v05 systemd[1]: slapd.service: Failed with result 'core-dump'. Apr 24 11:25:42 v05 systemd[1]: systemd-coredump(a)1-5051-0.service: Deactivated successfully. Looks a bit like a bad free() to me. I was adding the syncprov overlay with the accesslog DB being defined, but the accesslog overlay to set “olcAccessLogDB: cn=changelog-0” wasn’t done yet. The changelog-0 database may have contained outdated entries. Kind regards, Ulrich Windl

1 2

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

← Newer
1
...
6
7
8
9
10
11
12
...
994
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical