openldap-technical April 2023

openldap-technical@openldap.org

28 participants
26 discussions

Use of olcTLSECName directive returns ‘wrong attibuteType’ error
by Lemons, Terry 20 Apr '23

20 Apr '23

Hi I’m attempting to modify the TLS ciphers that are used in an openldap2-2.4.41-22.16.1.x86_64 environment in our lab, running on SLES 12 SP5. I’ve used the following command to set the cipher list value to the returned value of ‘openssl ciphers HIGH’: ldpdd041:/tmp # cat set-ciphersuite.ldif dn: cn=config changetype: modify add: olcTLSCipherSuite olcTLSCipherSuite: HIGH ldpdd041:/tmp # ldapmodify -H ldapi:// -Y EXTERNAL -f set-ciphersuite.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldpdd041:/tmp # openssl ciphers HIGH ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DH-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DH-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DH-RSA-AES256-SHA256:DH-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DH-RSA-AES256-SHA:DH-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DH-RSA-CAMELLIA256-SHA:DH-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-GCM-SHA384:ADH-AES256-SHA256:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DH-DSS-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DH-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DH-RSA-AES128-SHA256:DH-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DH-RSA-AES128-SHA:DH-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:DH-RSA-CAMELLIA128-SHA:DH-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-GCM-SHA256:ADH-AES128-SHA256:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA ldpdd041:/tmp # So I had expected to see that all of these ciphers were being offered for use by the OpenLDAP server; instead, I see that only a subset of the list is offered: sslyze ldpdd041.hop.lab.emc.com:636 . . . * TLS 1.0 Cipher Suites: Attempted to connect using 80 cipher suites. The server accepted the following 4 cipher suites: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 128 TLS_RSA_WITH_AES_256_CBC_SHA 256 TLS_RSA_WITH_AES_128_CBC_SHA 128 The group of cipher suites supported by the server has the following properties: Forward Secrecy INSECURE - Not Supported Legacy RC4 Algorithm OK - Not Supported * TLS 1.1 Cipher Suites: Attempted to connect using 80 cipher suites. The server accepted the following 4 cipher suites: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 128 TLS_RSA_WITH_AES_256_CBC_SHA 256 TLS_RSA_WITH_AES_128_CBC_SHA 128 The group of cipher suites supported by the server has the following properties: Forward Secrecy INSECURE - Not Supported Legacy RC4 Algorithm OK - Not Supported * TLS 1.2 Cipher Suites: Attempted to connect using 156 cipher suites. The server accepted the following 8 cipher suites: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 128 TLS_RSA_WITH_AES_256_GCM_SHA384 256 TLS_RSA_WITH_AES_256_CBC_SHA256 256 TLS_RSA_WITH_AES_256_CBC_SHA 256 TLS_RSA_WITH_AES_128_GCM_SHA256 128 TLS_RSA_WITH_AES_128_CBC_SHA256 128 TLS_RSA_WITH_AES_128_CBC_SHA 128 I believe I know why the DHE-based ciphers are not being offered: I haven’t enabled use of the olcTLSDHParamFile directive. Rather than mess around with generating the DH param file, etc., I’d like to use ECDHE-based ciphers. According to p. 160 of https://www.openldap.org/doc/admin24/OpenLDAP-Admin-Guide.pdf, the ‘TLSECName’ directive allows an ECDHE curve to be specified. When I tried to enable use of the directive, I received a ‘wrong attibuteType’ error: ldpdd041:/tmp # cat set-ecname.ldif dn: cn=config changetype: modify add: olcTLSECName olcTLSECName : secp384r1 ldpdd041:/tmp # ldapmodify -H ldapi:// -Y EXTERNAL -f set-ecname.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 ldapmodify: wrong attributeType at line 4, entry "cn=config" ldpdd041:/tmp # Does OpenLDAP 2.4.41 not support this directive? Thanks tl Terry Lemons Senior Principal Software Engineer, Dell EMC Dell Technologies | Data Management Terry.Lemons(a)dell.com<mailto:Terry.Lemons@dell.com> Internal Use - Confidential

3 5

Re: Argon2-Support or secure hashing
by Braiam 14 Apr '23

14 Apr '23

On Thu, Apr 13, 2023 at 12:19 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > This is an annoying bit about the Debian/Ubuntu builds as > they strip that information out of the binary. I was curious about that, and Debian doesn't strip that information[1]: ldapadd -V ldapadd: @(#) $OpenLDAP: ldapmodify 2.5.13+dfsg-5 (Feb 8 2023 01:56:12) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> (LDAP library: OpenLDAP 20513) I don't have an Ubuntu box at hand but their devel branch has the same patch[2] applied. If I trust that the datetime on the version string is the build date time, and since they use reproducible builds, I would guess that the base version is 2.5.6, from this changelog [3]. -- Braiam [1]: https://salsa.debian.org/openldap-team/openldap/-/blob/master/debian/patche… [2]: https://git.launchpad.net/ubuntu/+source/openldap/tree/debian/patches [3]: https://git.launchpad.net/ubuntu/+source/openldap/tree/debian/changelog?h=u…

4 6

How to get detailed connection error information?
by Jordan Brown 14 Apr '23

14 Apr '23

How can I get detailed information about connection errors - host not found, timed out, connection refused, various TLS errors, et cetera? -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

4 10

How to update UNIX+Samba password?
by Jan Andersen 14 Apr '23

14 Apr '23

I have OpenLDAP 2.4.57 on a Debian 11 server and Samba 4.13.13, on another Debian 11 system. When I create a new user in LDAP Account Manager (LAM), I can log in to the linux client systems, and I can connect using smbclient; and I can change the password successfully from LAM for both Samba and Linux. However, I can't do the same from the linux command line with 'passwd'. I have found several articles pointing me to smbk5pwd, which I have installed and configured according to https://bangdash.space/2021/01/syncing-ldap-passwords-with-samba/ - but it doesn't make a difference. Clearly I have not set it up correctly; I would be grateful if someone with more insight than myself could help me find the problem. I have run a session where user 'zzuser' changed their password from linux and the server ran: /usr/sbin/slapd -h "ldap:/// ldapi:/// ldaps:///" -g openldap -u openldap -F /etc/ldap/slapd.d -d -1 It generated 42715 lines of output, which I have saved, but I hesitate to dump it here. However, please let me know what information you need to help me.

1 0

pcache not working with dirx
by A. Schulze 13 Apr '23

13 Apr '23

Hello, I'm playing with the slapo-pcache overlay (openldap-2.6.4). Using the folloging configuration: ``` # https://www.openldap.org/doc/admin26/guide.html#The%20Proxy%20Cache%20Engine database ldap suffix dc=dirx,dc=example rootdn dc=dirx,dc=example uri ldap://dirx.example/ overlay pcache pcache mdb 1000 2 1000 20 pcacheAttrset 0 DKIMSelector pcacheTemplate (&(DKIMDomain=)(DKIMActive=)(DKIMKeyType=)) 0 10 pcacheAttrset 1 DKIMDomain DKIMSelector DKIMKey pcacheTemplate (DKIMSelector=) 1 10 directory /spool/dc=dirx,dc=example database ldap suffix dc=openldap,dc=example rootdn dc=openldap,dc=example uri ldap://openldap.example/ overlay pcache pcache mdb 1000 2 1000 20 pcacheAttrset 0 DKIMSelector pcacheTemplate (&(DKIMDomain=)(DKIMActive=)(DKIMKeyType=)) 0 10 pcacheAttrset 1 DKIMDomain DKIMSelector DKIMKey pcacheTemplate (DKIMSelector=) 1 10 directory /spool/dc=openldap,dc=example ``` One upstream server is DirX, the other openldap-2.6.4. Dirx don't work Openldap-cache is running with "slapd ... -d Config,Stats,pcache ..." this are the logs from a failing attempt: openldap-cache_1 | 643667a0.0584c8aa 0x7fa20ffff700 conn=1002 op=0 BIND dn="cn=reader,dc=dirx,dc=example" method=128 openldap-cache_1 | 643667a0.05b4d722 0x7fa20ffff700 conn=1002 op=0 BIND dn="cn=reader,dc=dirx,dc=example" mech=SIMPLE bind_ssf=0 ssf=71 openldap-cache_1 | 643667a0.05b5b312 0x7fa20ffff700 conn=1002 op=0 RESULT tag=97 err=0 qtime=0.000018 etime=0.003246 text= openldap-cache_1 | 643667a3.1cdab2c4 0x7fa214d35700 conn=1002 op=1 SRCH base="ou=Domains,dc=dirx,dc=example" scope=2 deref=0 filter="(&(DKIMDomain=dirxdomain.de)(DKIMActive=TRUE)(DKIMKeyType=rsa))" openldap-cache_1 | 643667a3.1cdada18 0x7fa214d35700 conn=1002 op=1 SRCH attr=DKIMSelector openldap-cache_1 | 643667a3.1cdb0450 0x7fa214d35700 query template of incoming query = (&(DKIMDomain=)(DKIMActive=)(DKIMKeyType=)) openldap-cache_1 | 643667a3.1cdb36bf 0x7fa214d35700 Entering QC, querystr = (&(DKIMDomain=dirxdomain)(DKIMActive=TRUE)(DKIMKeyType=rsa)) openldap-cache_1 | 643667a3.1cdb4254 0x7fa214d35700 Lock QC index = 0x5572682fc520 openldap-cache_1 | 643667a3.1cdb4e08 0x7fa214d35700 Not answerable: Unlock QC index=0x5572682fc520 openldap-cache_1 | 643667a3.1cdb5617 0x7fa214d35700 QUERY NOT ANSWERABLE openldap-cache_1 | 643667a3.1cdb5cec 0x7fa214d35700 QUERY CACHEABLE openldap-cache_1 | 643667a3.1d40534b 0x7fa214d35700 conn=1002 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000014 etime=0.006697 nentries=0 text= and for a query to the openldap backend it works: openldap-cache_1 | 6436693c.35c382c5 0x7fa20ffff700 conn=1007 op=0 BIND dn="cn=reader,dc=openldap,dc=example" method=128 openldap-cache_1 | 6436693c.3663bbec 0x7fa20ffff700 conn=1007 op=0 BIND dn="cn=reader,dc=openldap,dc=example" mech=SIMPLE bind_ssf=0 ssf=71 openldap-cache_1 | 6436693c.36643fe0 0x7fa20ffff700 conn=1007 op=0 RESULT tag=97 err=0 qtime=0.000031 etime=0.010584 text= openldap-cache_1 | 64366940.08541952 0x7fa214d35700 conn=1007 op=1 SRCH base="ou=Domains,dc=openldap,dc=example" scope=2 deref=0 filter="(&(DKIMDomain=openldapdomain.de)(DKIMActive=TRUE)(DKIMKeyType=ed25519))" openldap-cache_1 | 64366940.08543f48 0x7fa214d35700 conn=1007 op=1 SRCH attr=DKIMSelector openldap-cache_1 | 64366940.0854686a 0x7fa214d35700 query template of incoming query = (&(DKIMDomain=)(DKIMActive=)(DKIMKeyType=)) openldap-cache_1 | 64366940.08547707 0x7fa214d35700 Entering QC, querystr = (&(DKIMDomain=openldapdomain.de)(DKIMActive=TRUE)(DKIMKeyType=ed25519)) openldap-cache_1 | 64366940.08547fde 0x7fa214d35700 Lock QC index = 0x5572682fda70 openldap-cache_1 | 64366940.08548a4b 0x7fa214d35700 Not answerable: Unlock QC index=0x5572682fda70 openldap-cache_1 | 64366940.0854925c 0x7fa214d35700 QUERY NOT ANSWERABLE openldap-cache_1 | 64366940.085499d1 0x7fa214d35700 QUERY CACHEABLE openldap-cache_1 | 64366940.0868a233 0x7fa214d35700 Added query expires at 1681287498 (POSITIVE) openldap-cache_1 | 64366940.0868bf3d 0x7fa214d35700 Lock AQ index = 0x5572682fda70 openldap-cache_1 | 64366940.0868cc0d 0x7fa214d35700 TEMPLATE 0x5572682fda70 QUERIES++ 1 openldap-cache_1 | 64366940.0868d3eb 0x7fa214d35700 Base of added query = ou=Domains,dc=openldap,dc=example openldap-cache_1 | 64366940.0868daa0 0x7fa214d35700 Unlock AQ index = 0x5572682fda70 openldap-cache_1 | 64366940.0868f2f2 0x7fa214d35700 UUID for query being added = 4d0928a8-6d56-103d-8d96-0b2b6342ea75 openldap-cache_1 | 64366940.092158fe 0x7fa214d35700 ENTRY ADDED/MERGED, CACHED ENTRIES=1 openldap-cache_1 | 64366940.09219238 0x7fa214d35700 STORED QUERIES = 1 openldap-cache_1 | 64366940.0921a8d6 0x7fa214d35700 conn=1007 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000014 etime=0.013522 nentries=1 text= If I run slapd with all Debug Logging enabled ( slapd ... -d -1 ...) I see, the DirX backend **do answer** with the expexted date but the log is so verbose, so I could not see a problem. using ldapsearch directly against both backend servers I verified, the requested data are accessible. One glitch I found in the Documentation at https://www.openldap.org/doc/admin26/guide.html#The%20Proxy%20Cache%20Engine Under "12.9.2.4. Example for slapd.conf" the is an Entry "cachesize 20" mentioned. If I enable this option, slapd fail to start: openldap-cache_1 | 64366b51.0ec4f7d9 0x7f4f046423c0 /usr/local/etc/openldap/slapd.conf: line 45 (cachesize 20) openldap-cache_1 | 64366b51.0ec5f70a 0x7f4f046423c0 /usr/local/etc/openldap/slapd.conf: line 45: unknown directive <cachesize> inside backend database definition. Is the documentation really correct? Andreas

2 2

Argon2-Support or secure hashing
by Lukas Adrian Kron 13 Apr '23

13 Apr '23

Hello, I am trying to use Argon2 or PBKDF2_SHA256 as a secure password hashing function. Since two weeks I am trying to get this to work with reading a lot of information on the internet and I just cannot get it to work. I am using Ubuntu 20.04 LTS, installed with slapd, ldap-utils, argon2 and trying to set it in the cn=config Frontend setting. @(#) $OpenLDAP: slapd (Ubuntu) (May 12 2022 13:11:05) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> This is the version that is installed from Slapd and when I try to set pw-argon2, {ARGON2}, pw-argon2.so... I tried a lot and it tells me no hash found. If I try {MD5} it works without problems. As there is no other secure usable password hashing installed the LDAP Server is right now insecure and I cannot move it to production Please does someone has any idea? Many kind regards, Lukas

2 1

meaning of bind_ssf
by Stefan Kania 13 Apr '23

13 Apr '23

Hi to all, when I connect to openldap, with simple-bind I see: ----------- mech=SIMPLE bind_ssf=0 ssf=256 ----------- When I connect to openldap with GSSAPI I see: ----------- mech=GSSAPI bind_ssf=56 ssf=256 ----------- So I uses strong-bind via GSSAPI there is no place where I can find anything about "bind_ssf". So what ist bind_ssf stands for? I only found: transport_ssf=<n> tls_ssf=<n> sasl_ssf=<n> Another strange thing (to me ;-) ) The openldap admin guide is telling me: ---------------- The server uses Security Strength Factors (SSF) to indicate the relative strength of protection. A SSF of zero (0) indicates no protections are in place. A SSF of one (1) indicates integrity protection are in place. A SSF greater than one (>1) roughly correlates to the effective encryption key length. For example, DES is 56, 3DES is 112, and AES 128, 192, or 256. ---------------- in my kdc.conf I have: --------------- supported_enctypes = aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal --------------- So no DES with a key-length of 56 is defined. Same when I look at the key from my user I'm using to connect. The infos about the user is telling me in kadmin ---------------- Key: vno 1, aes256-cts-hmac-sha1-96 Key: vno 1, aes128-cts-hmac-sha1-96 ---------------- So why is the log telling me ssf=56? Stefan

2 3

Slow Search?
by Bradley T Gill 12 Apr '23

12 Apr '23

I have an ou with 3.2M users. Doing a simple search of 1 attribute with a scope of 1 and a base of that flat ou is taking 6.2 Seconds. In a replica database, I have attempted to remove all other indexes but the attribute I am searching for and it still is taking over 6 seconds. Is that to be expected? Apr 11 10:37:49 slapd[25081]: conn=1000 op=20 SRCH base="ou=FlatOU" scope=1 deref=3 filter="(attr=login102)" Apr 11 10:37:49 slapd[25081]: conn=1000 op=20 SRCH attr=objectClass Apr 11 10:37:55 slapd[25081]: conn=1000 op=20 SEARCH RESULT tag=101 err=0 qtime=0.000025 etime=6.267130 nentries=1 text= Only Idex: olcDbIndex: attr pres,eq After settting the index, I stopped ldap and ran slapindex CPU: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 1 Core(s) per socket: 1 Socket(s): 8 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Gold 6136 CPU @ 3.00GHz Stepping: 0 CPU MHz: 2992.968 BogoMIPS: 5985.93 Hypervisor vendor: VMware Virtualization type: full L1d cache: 32K L1i cache: 32K L2 cache: 1024K L3 cache: 25344K NUMA node0 CPU(s): 0-7 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single ssbd rsb_ctxsw ibrs ibpb stibp fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec arat pku ospke md_clear spec_ctrl intel_stibp flush_l1d arch_capabilities 24 GB of RAM with 10 GB Free Thanks for any suggestions: Bradley Gill

3 5

slapadd: bad configuration directory!
by cxb2000abc＠gmail.com 05 Apr '23

05 Apr '23

Hi all, I am new to OpenLDAP, recently I am following the official quick-start guide and finished the installation part. However when configuring the database which is step 9 in the guide su root -c /usr/local/sbin/slapadd -n 0 -F /usr/local/etc/slapd.d -l /usr/local/etc/openldap/slapd.ldif I got the error: slapadd: bad configuration directory! I look into the folder /usr/local/etc/, I don't see any slapd.d. Even I saw some discussion say that it located at /etc/openldap/. I can't see any either. Please help me out. Thank you very much.

3 2

How to build argon2.so ?
by Scott Classen 05 Apr '23

05 Apr '23

Hello, According to: servers/slapd/pwmods/README.argon2 Building -------- 1) Customize the OPENLDAP variable in Makefile to point to the OpenLDAP source root. For initial testing you might also want to edit DEFS to define SLAPD_ARGON2_DEBUG, which enables logging to stderr (don't leave this on in production, as it prints passwords in cleartext). 2) Run 'make' to produce argon2.so 3) Copy argon2.so somewhere permanent. 4) Edit your slapd.conf (eg. /etc/ldap/slapd.conf), and add: moduleload ...path/to/argon2.so 5) Restart slapd. When I run make from within servers/slapd/pwmods/ I get the following error: [user@machine openldap-2.6.4]# cd servers/slapd/pwmods/ [user@machine pwmods]# make make: *** No rule to make target 'dummyvalue', needed by 'all-common'. Stop. I’m not sure what “dummyvalue” is supposed to be so I commented out line 288 in servers/slapd/pwmods/Makefile # LIBRARY = dummyvalue And get this error: [user@ machine pwmods]# make /bin/sh ../../../libtool --tag=disable-static --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c version.c libtool: compile: cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c version.c -fPIC -DPIC -o .libs/version.o version.c:1:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token usage: mkversion [-c] [-s] [-p package] [-v version] application ^ make: *** [Makefile:310: version.lo] Error 1 Any help in generating argon2.so would be greatly appreciated. If I’m somehow getting deeper in the weeds than I need to with the new OpenLDAP version 2.6.4 in order to support {ARGON2} hashes please let me know. Import of my slapd.ldif file is bonking on: olcPasswordHash: {ARGON2} So as with previous versions of OpenLDAP I assumed I would need to build and load the argon2 module manually. Sincerely, Scott Classen

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical April 2023