Unfortunately i don't have anything newer than 2018SP3 available. "diagpwd" works just fine on this platform and your syntax is definitely ok. So to rule out code issues i'd quickly spawn an OES2018SP3 VM in a dedicated tree and try from there.

Hi Seb

I am having a similar issue today (without the core dump) not got to the bottom of it yet.

I did however note that you are using a PEM and not a DER

diagpwd usage: <ldap ip addr> <ssl port> <der file> <searchBase> <searchScope> <bind DN> [<bind Pwd>] [<-t>]

HTH

Tim

(See you in Amberg?)

Hi Tim

timscotland said:

I did however note that you are using a PEM and not a DER

Ha, interesting, completely missed that in documentation (obviously getting old - and I thought I will become wiser, not more careless... ).

Anyway, I need to check if that removes segmentation fault.

Regarding universal password problem, colleague reminded me of very nice universal password features of Console2 (I can only say kudos to alekz , a "must" tool for any IDM developer), so I have not spent any more time on troubleshooting diagpwd.

Kind regards

Sebastijan

timscotland said:

(See you in Amberg?)

Unfortunately not this year, Amberg this year overlaps with some of my other responsibilities that I cannot ditch (although I'd like to...). But sending two of my colleagues there.

Thank you for the reference for Console2, grabbing it now!

I'm hitting this same issue, and troubleshooting so far is showing that it is NOT initiating a TLS negotiation at all, unlike JXplorer.  
Just does the basic TCP handshake up and down (Hi, Bye) 
  So we may be hitting a bug here that is still on OES 24.3 (eDirectory 9.2.8 v40209.00)  Fun the many threads one initiating problem spawns.

Hi Andy, off the top of my brain, can you please do a DSTRACE with +NMAS, +LDAP +TAGS. Universal Password uses LDAP NMAS extentions if I still have it in my head. If the server you are measuring is missing, this could be the problem. If this is the case, you should be able to see the extension error in the trace.

George

Like I saw in the packet trace

358610688 LDAP: [2024/09/29 16:42:34.687] TLS accept failure 5 on connection 0x2f6d940, setting err = -5875. Error stack:
358610688 LDAP: [2024/09/29 16:42:34.687] TLS handshake failed on connection 0x2f6d940, err = -5875

TLS is needed, and diagpwd doesn't even start it. 

Other LDAP activity shows NMAS active, so that shouldn't be an issue once diagpwd is fixed.

Hello Andy,

diagpwd ip 636   o=myou sub cn=myadmin,o=myou  -t

anyone who wants to use diagpwd in version 5 will immediately fall flat on their face.

what is behind it when you take the spade (simple strace )to help you

ERROR -1 ldap_simple_bind_s
Segmentation fault (core dumped)

# strace diagpwd  ip 636 var/opt/novell/eDirectory/data/dib/certserv/kmocache/UwBTAEwAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUARABOAFMA.pem o=myou sub cn=myadmin,o=myou  -t
execve("/opt/novell/eDirectory/bin/diagpwd", ["diagpwd", "ip", "636", "/var/opt/novell/eDirectory/data/"..., "o=myou", "sub", "cn=myadmin,o=myou", "-t"], 0x7ffd63b811a8 /* 64 vars */) = 0
brk(NULL)                               = 0x21a3000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb0c7252000
readlink("/proc/self/exe", "/opt/novell/eDirectory/bin/diagp"..., 4096) = 34
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/opt/novell/eDirectory/bin/tls/haswell/avx512_1/x86_64/libnmasext.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/opt/novell/eDirectory/bin/tls/haswell/avx512_1/x86_64", 0x7ffe3457ea70) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/opt/novell/eDirectory/bin/tls/haswell/avx512_1/libnmasext.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/opt/novell/eDirectory/bin/tls/haswell/avx512_1", 0x7ffe3457ea70) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/opt/novell/eDirectory/bin/tls/haswell/x86_64/libnmasext.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/opt/novell/eDirectory/bin/tls/haswell/x86_64", 0x7ffe3457ea70) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/opt/novell/eDirectory/bin/tls/haswell/libnmasext.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)


the strace has even more lines. You can see that a lot of 64 bit libaries (nmas, ldap, sasl, crypt etc) are not found and also the corresponding .so files. They are present in the file system. So once again it can be assumed that the environment variables do not match and symlinks are missing.

During the execution of diagpwd, the certificat is read out and confirmed with “correct” as far as I can judge quickly

openat(AT_FDCWD, "/var/opt/novell/eDirectory/data/dib/certserv/kmocache/UwBTAEwAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUARABOAFMA.pem", O_RDONLY) = 3
close(3)                                = 0
openat(AT_FDCWD, "/var/opt/novell/eDirectory/data/dib/certserv/kmocache/UwBTAEwAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUARABOAFMA.pem", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0600, st_size=6387, ...}) = 0
read(3, "-----BEGIN CERTIFICATE-----\nMIIG"..., 4096) = 4096
close(3)         


Later, the openldap.conf is read again to check the system's certifcates. On the socket of the IP is then waiting for something (FUTEX_WAIT_PRIVATE) I think it is the password input and the whole thing then closes with

openat(AT_FDCWD, "/var/opt/novell/eDirectory/data/dib/certserv/kmocache/UwBTAEwAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUARABOAFMA.pem", O_RDONLY) = 3
close(3)                                = 0
openat(AT_FDCWD, "/var/opt/novell/eDirectory/data/dib/certserv/kmocache/UwBTAEwAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUARABOAFMA.pem", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0600, st_size=6387, ...}) = 0
read(3, "-----BEGIN CERTIFICATE-----\nMIIG"..., 4096) = 4096
close(3)         

then at some point the sigsegv that sends everything to nirvana

write(1, “ERROR -1 ldap_simple_bind_s\n”, 28ERROR -1 ldap_simple_bind_s
) = 28
shutdown(3, SHUT_RDWR) = 0
close(3) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x18} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x18} ---

If I see it correctly, the diagpwd is a 32 bit application and there is a bug here. Who opens the call? I have a lot on my plate right now

George

Georg H. Weber said:

If I see it correctly, the diagpwd is a 32 bit application and there is a bug here. Who opens the call? I have a lot on my plate right now

That was my suspicion, and that you've reproduced it, shows it is time for a case, and I do have the time right now to do so. And will point back here in the case for your contributions.

portal.microfocus.com/.../KM000033499

The issue is diagpwd uses dynamic libraries.  If libraries other than the eDirectory versions are loaded, diagpwd will core.  Please follow the instructions in this TID:  portal.microfocus.com/.../KM000033499