Am 08.03.23 um 14:11 schrieb Ulrich Windl:

Maybe examine the compiler flags, compiler version and CPU running the binary.

I use the symas-packeages from repository. I did not compile it on my own ;-)

Another strange thing about passwords on the same machine. As I told you before, we switch to ssha as paswordhash. The server works. But now we start to create new passwords with "slappasswd", we are getting a {SSHA}<hash>. But when change the password via ldif. The password is never valid. We did it several times, and it's always the same. But when changing passwords via LDAP account manager, the password works, them when creating the SSHA-password with: https://projects.marsching.org/weave4j/util/genpassword.php

The OpenLDAP-Server runs on a vmWare vm with the following CPU ------------- processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz stepping : 7 microcode : 0x713 cpu MHz : 2294.250 cache size : 15360 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm pti ibrs ibpb stibp tsc_adjust arat arch_capabilities bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_unknown retbleed bogomips : 4588.50 clflush size : 64 cache_alignment : 64 address sizes : 43 bits physical, 48 bits virtual power management: ------------- Any idea? A log time ago I read something about problems with Entropy in vmWare but I can't remember what it was. Could this be my problem with argon2 and slappasswd?

Am 08.03.23 um 15:38 schrieb Stefan Kania:

I think I found the problem:

The host has a 12 year old CPU Intel Xeon E5-2630 . Together with argon2 as passwordhash there is a problem. As soon as I switrch to SSHA everything is working fine.

Can someone confirm it?

Thank's to Ulrich for pushing me in the right direction ;-)

Am 08.03.23 um 14:30 schrieb Stefan Kania:

...

Am 08.03.23 um 14:11 schrieb Ulrich Windl:

...

Maybe examine the compiler flags, compiler version and CPU running the binary.

I use the symas-packeages from repository. I did not compile it on my own ;-)

Am 09.03.23 um 20:49 schrieb Quanah Gibson-Mount:

--On Thursday, March 9, 2023 7:51 PM +0100 Stefan Kania stefan@kania-online.de wrote:

...

Another strange thing about passwords on the same machine. As I told you before, we switch to ssha as paswordhash.

SSHA is rather insecure.  The Symas OpenLDAP builds ship with ARGON2 support which is advised to use.  I've no idea how you are "changing the password via LDIF".  Generally one should be using an LDAP v3 password modify operation for user accounts so that the server generates it automatically if it's been properly configured.

I know, starting with OpenLDAP2.5 I (normaly) only use argon2, but as I have written before argon2 let the OpenLDAP crash as soon as I try to authenticate with an argon2 password. I can only switch to argon2 as soon as I know why and how to handel the problem

--Quanah

Am 10.03.23 um 19:24 schrieb Quanah Gibson-Mount:

Ok.  I still don't know what 'changing the password via LDIF' means though.

Generate a password with for example slappasswd or argon2 and replace the attribute userPassword via a ldif-files

Am 10.03.23 um 20:36 schrieb Quanah Gibson-Mount:

--On Friday, March 10, 2023 7:37 PM +0100 Stefan Kania stefan@kania-online.de wrote:

...

Am 10.03.23 um 19:24 schrieb Quanah Gibson-Mount:

...

Ok.  I still don't know what 'changing the password via LDIF' means though.

Generate a password with for example slappasswd or argon2 and replace the attribute userPassword via a ldif-files

I think you mean, you're generating a hash for a password with slappasswd in either SSHA or ARGON2 format, and then updating an entry using LDIF files in some way (ldapmodify -f?).

Please provide an example LDIF file of such a change, using a stupid password for the hash (i.e., secret)

Regards, Quanah

For a rootdn ------------------- dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$ZGJmZ2lrbmpiZHZzZ3NhdmRzZw$J6eXYSxY4tDs4l8SdBkIwcAU0OqEEdR0gpFNJ5MSqQs -------------------

and a posix or simpleSecurityObject: ------------------- dn: uid=repl-user,ou=users,dc=example,dc=net changetype: modify replace: userPassword userPassword: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$c2FsdHNsYXQ5ODc2NTQzMg$Td51W49s0X74om++/EnMRsP4La3x46KufcGGY01T8+M ------------------- To reset several userpasswords I can use a script to reset passwords for many users.

On Thu, Mar 9, 2023 at 1:52 PM Stefan Kania stefan@kania-online.de wrote:

Another strange thing about passwords on the same machine. As I told you before, we switch to ssha as paswordhash. The server works. But now we start to create new passwords with "slappasswd", we are getting a {SSHA}<hash>. But when change the password via ldif. The password is never valid. We did it several times, and it's always the same. But when changing passwords via LDAP account manager, the password works, them when creating the SSHA-password with: https://projects.marsching.org/weave4j/util/genpassword.php

The OpenLDAP-Server runs on a vmWare vm with the following CPU

processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz stepping : 7 microcode : 0x713 cpu MHz : 2294.250 cache size : 15360 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm pti ibrs ibpb stibp tsc_adjust arat arch_capabilities bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit mmio_unknown retbleed bogomips : 4588.50 clflush size : 64 cache_alignment : 64 address sizes : 43 bits physical, 48 bits virtual power management:

---

Any idea? A log time ago I read something about problems with Entropy in vmWare but I can't remember what it was. Could this be my problem with argon2 and slappasswd?

This is interesting (in a morbid sort of way)...

Intel Ark says your CPU has AVX2 (https://ark.intel.com/content/www/us/en/ark/products/83356/intel-xeon-proces...), but the avx2 flag is missing in:

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc cpuid pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx hypervisor lahf_lm pti ibrs ibpb stibp tsc_adjust arat arch_capabilities

I'm guessing (and it is just a guess), you are getting into the AVX2 code paths at https://git.symas.net/symas-public/libargon2/-/blob/master/src/opt.c .

I would rebuild libargon, and set OPTTARGET=x86_64.

Jeff

On Wed, Mar 8, 2023 at 8:30 AM Stefan Kania stefan@kania-online.de wrote:

Am 08.03.23 um 14:11 schrieb Ulrich Windl:

...

Maybe examine the compiler flags, compiler version and CPU running the binary.

I use the symas-packages from repository. I did not compile it on my

This could be the problem: https://git.symas.net/symas-public/libargon2/-/blob/master/Makefile#L59 :

# Detect compatible platform ifneq ($(OPTTEST), 0) $(info Building without optimizations) SRC += src/ref.c else $(info Building with optimizations for $(OPTTARGET)) CFLAGS += -march=$(OPTTARGET) SRC += src/opt.c endif

What is $(OPTTARGET)? I would be inclined to believe it is _not_ x86_64, which is the amd64 base machine. Instead, $(OPTTARGET) is using an ISA that is higher than what your XEON provides.

But this is just a guess. A disassembly around ip:7febaf26a415 would confirm it.

kernel: traps: slapd[18020] trap invalid opcode ip:7febaf26a415 sp:7fc3ad4b69e0 error:0 in libargon2.so.1[7febaf266000+5000]

Jeff

On Fri, Mar 10, 2023 at 4:36 AM Jeffrey Walton noloader@gmail.com wrote:

On Wed, Mar 8, 2023 at 7:48 AM Stefan Kania stefan@kania-online.de wrote:

...

I just installed a fresh 2.5 server with the symas-packages and debian 11. I can start the service, but as soon as I try to authenticate for example with:

ldapsearch -x -D cn=admin,dc=example,dc=net -W

the server crashes, I put the loglevel to "any" and I saw

kernel: traps: slapd[18020] trap invalid opcode ip:7febaf26a415 sp:7fc3ad4b69e0 error:0 in libargon2.so.1[7febaf266000+5000]

Everytime I try to authenitcate. All packages are up to date.

any idea

Here's the problem. I'm not sure how I missed it. https://git.symas.net/symas-public/libargon2/-/blob/master/Makefile#L51

OPTTARGET ?= native OPTTEST := $(shell $(CC) -Iinclude -Isrc -march=$(OPTTARGET) src/opt.c -c \ -o /dev/null 2>/dev/null; echo $$?)

'OPTTARGET ?= native' says to set OPTTARGET to native if it is not set in the environment. Eventually it shows up on the GCC command line as '-march=native'.

-march=native enables ISA's on the build machine. Those ISAs may not be present on the host the program is running on, like your Xeon's.

You have to rebuild the library. If you build on the server with the Xeon's, then _you_ can use -march=native. However, if the library is being built on another machine, then you have to use -march=x86-64 if you want to distribute the binary.

-march=x86-64 targets the base amd64 machine. You can build it and it will run on all amd64 machines.

You should probably file a bug report against symas-libargon for doing that to you :)

Stefan, Quahan,

This message was forwarded to Syma's Support. Stefan and Quahan were included in the email.

Support fixed the makefile flag and built a new package for you to test:

I have built a Debian 11 package with OPTTARGET x86-64 and put it on our testing repo for evaluation before building the other distros. Its version is 20190702-3bullseye1. Can you try and see if it works? Our testing repo can be used in the same way as our release repo, just with a different settings file: When following the instructions on: https://repo.symas.com/soldap2.5/debian11/ replace step 1 with wget -q https://repo.symas.com/configs/SOLDAP/d11/testing25.list -O /etc/apt/sources.list.d/soldap-testing25.list

Could you provide feedback to Syma's Support, please?

(If you don't see the email, then check your spam folder).

Jeff