LDAP encryption error

[Gexproof]

Hello.

I'm trying to set up my PwReset application via WebADM GUI, but have some troubles with encryption in LDAP connector.

In server.xml single variant when LDAP connection is OK is

 

<LdapServername="LDAP Server"

        host="dc.domain.com"

        port="389"

        encryption="NONE"

        ca_file=""

        sasl=""/>

Any other port or encryption values return next string in output after service restart.

"Connected LDAP server: ERROR (no server available)",

 

Haven't found any info in guides or troubleshooting about making encryption works this way.

Telnet to DC port 389 - OK

Telnet to DC port 636 - OK

on DC:

netstat -na | Select-String "636" - LISTENING

netstat -na | Select-String "389" - LISTENING

In GUI in "Trusted Certificate Authorities" i've added my DC's cert and added webadm's cert to trusted root on DC - useless.

well now, with none encryption value, when i'm trying to reset user password via PwReset - i'm getting error:

[2024-03-21 16:27:45] [10.13.177.109:14158] [PwReset:XCV40315] Could not modify LDAP object 'CN=webadmtest,OU=Tech,OU=ActiveUsers,DC=domain,DC=com' (0000001F: SvcErr: DSID-031A12E8, problem 5003 (WILL_NOT_PERFORM), data 0)

 

In the same time:

- i can change attributes of accounts in my doman through webadm GUI (so i'm already got write access without encryption)

- i can recieve otp token on email

In troubleshooting guide it sais that problem is in encryption.

So how to set it properly?

Please help!

[Yoann Traut (RCDevs)]

Hello, 

You have the 2 following possibilities:

<LdapServername="LDAP Server"

        host="dc.domain.com"

        port="389"

        encryption="TLS"

        ca_file="" />

or 

<LdapServername="LDAP Server"

        host="dc.domain.com"

        port="636"

        encryption="SSL"

        ca_file="" />

Regards

[Gexproof]

Yes, and both these possibilities rerturns "Connected LDAP server: ERROR (no server available)"

пятница, 22 марта 2024 г. в 11:57:02 UTC+3, Yoann Traut (RCDevs):

[Gexproof]

With

        port="389"

        encryption="TLS"

Found some errors on DC

1) An TLS 1.2 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed.

2) A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205.

пятница, 22 марта 2024 г. в 11:57:02 UTC+3, Yoann Traut (RCDevs):

Hello, 

[Yoann Traut (RCDevs)]

Hello, 

Thank you for your feedback. 

Which version of WebADM are you running? 

cat /opt/webadm/VERSION 

And which version of AD are you running? 

 

Regards

[Gexproof]

RCDevs WebADM Server v2.3.13-1 for Linux 64bit
Built February 5 2024

Including component versions:
- curl 8.5.0
- gmp 6.3.0
- apache 2.4.58
- libxml 2.12.3
- libpng 1.6.37
- openldap 2.6.6
- openssl 3.1.5
- php 8.1.27
- redis 7.2.4
- unixodbc 2.3.12
- zlib 1.3
- libqrencode 4.1.1
- libcouchbase 3.3.10
- libmaxmind 1.8.0
- libaudit 2.4.5
- libnghttp2 1.52.0

- libhiredis 1.2.0

msDS-Behavior-Version =6 (WIN2012R2)

пятница, 22 марта 2024 г. в 17:19:27 UTC+3, Yoann Traut (RCDevs):

[Yoann Traut (RCDevs)]

Ok, can you update WebADM to 2.3.14-5 available on our stable repos? 

f I remember correctly, that issue has been fixed on that version. 

Regards

[Gexproof]

Thx for advice!

Done

webadm-all-in-one/base,now 1.0.1-0 all [installed]
webadm/base,now 2.3.14-5 amd64 [installed]

But still same errors in both variants ( TLS: 389 and SSL: 636 ). DC log still the same.

пятница, 22 марта 2024 г. в 17:36:42 UTC+3, Yoann Traut (RCDevs):

[Yoann Traut (RCDevs)]

Ok, thank you sorry I tell you something wrong. It is because OpenSSL3 implemented in last versions of WebADM is not supporting anymore SHA1 signature.  
Found below, the workaround we sent to another customer: 

The Windows LDAP server supports RSA+SHA1 and RSA+SHA256 (also supported by WebADM 2.3.14), but the choice of algorithm depends on the signature algorithm of the certificate used to secure the LDAP port.

You need to renew the LDAP certificate to one with SHA-256 signature in the following manner:

On your domain controller, in PowerShell, execute the following command to generate certificates with SHA-256 signature algorithm:

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

Restart the Certificate service with:

net stop certsvc
net start certsvc

Then, in the computer certificate store of Windows, under Personal -> Certificates, you can renew the certificate corresponding to the LDAP connection.

Regards

[Gexproof]

Done.

Also it needs to do renew

certutil -renewCert ReuseKeys

net stop certsvc
net start certsvc

I've uploded new cert in trusted certs via WebadmGUI

But... still same errors with TLS and SSL =(

пятница, 22 марта 2024 г. в 18:40:10 UTC+3, Yoann Traut (RCDevs):

[Yoann Traut (RCDevs)]

Are you sure the new certificate is currently in use? 
I'm not sure if AD services needs to be restarted. 
You can verify it from WebADM server over SSH with the following command (adapt the IP), port can be 636 or 389:

openssl s_client -connect 192.168.4.2:636

Connecting to 192.168.4.2

CONNECTED(00000003)

Can't use SSL_get_servername

depth=1 DC=com, DC=rcdevs, DC=support, CN=SUPCAAD2

verify return:1

depth=0 CN=AD22-1.support.rcdevs.com

verify return:1

---

Certificate chain

 0 s:CN=AD22-1.support.rcdevs.com

   i:DC=com, DC=rcdevs, DC=support, CN=SUPCAAD2

   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256

   v:NotBefore: Nov 29 09:45:26 2023 GMT; NotAfter: Nov 28 09:45:26 2024 GMT

---

Server certificate

-----BEGIN CERTIFICATE-----

MIIGjTCCBXWgAwIBAgITHAAAALo6avTg+FFoTQAAAAAAujANBgkqhkiG9w0BAQsF

ADBZMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGcmNkZXZz

MRcwFQYKCZImiZPyLGQBGRYHc3VwcG9ydDERMA8GA1UEAxMIU1VQQ0FBRDIwHhcN

MjMxMTI5MDk0NTI2WhcNMjQxMTI4MDk0NTI2WjAkMSIwIAYDVQQDExlBRDIyLTEu

c3VwcG9ydC5yY2RldnMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC

AQEAt4VN7XzqUBYj5JQrQMlTx0vsrCatLosQbdRiQzh5YwiyVpqKXL2q0WLLRVxZ

/N36iIaGFq+9HjlvHdLJOSn9b0UhgrDZGHPYPcll5q+DGhk7MSZZNBSC8DU51drl

kCRwHCV18fCV+94VnWNEfcZBpPglLbXrMbM3FSGgDv8CgHm0rFOo4MVC9MMZuTPQ

s+3FQPDQqRooUvLBRkgD1pwaKvFOBv8pOMKOPwjhfRC4GEy8Sv2ZTVjIVBuj2T7Q

oS8W5O3Qz5F8HwLR+RVbzrxsX9S1dZCRuTbK6204g/YqMRgn4wI0BXEd0+4kl+Zd

aXHD6EzVi9h5F2DxTLDGg9sRHQIDAQABo4IDgTCCA30wLwYJKwYBBAGCNxQCBCIe

IABEAG8AbQBhAGkAbgBDAG8AbgB0AHIAbwBsAGwAZQByMB0GA1UdJQQWMBQGCCsG

AQUFBwMCBggrBgEFBQcDATAOBgNVHQ8BAf8EBAMCBaAweAYJKoZIhvcNAQkPBGsw

aTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjAL

BglghkgBZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAK

BggqhkiG9w0DBzAdBgNVHQ4EFgQUv7DRpx6gbUdaRiHBWFABeHY6m/QwHwYDVR0j

BBgwFoAU2vCNPJTo59rA87s0RIotTU4axd8wgc8GA1UdHwSBxzCBxDCBwaCBvqCB

u4aBuGxkYXA6Ly8vQ049U1VQQ0FBRDIsQ049QUQxOS0yLENOPUNEUCxDTj1QdWJs

aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u

LERDPXN1cHBvcnQsREM9cmNkZXZzLERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRp

b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfcG

CCsGAQUFBwEBBIHqMIHnMIGxBggrBgEFBQcwAoaBpGxkYXA6Ly8vQ049U1VQQ0FB

RDIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz

LENOPUNvbmZpZ3VyYXRpb24sREM9c3VwcG9ydCxEQz1yY2RldnMsREM9Y29tP2NB

Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y

aXR5MDEGCCsGAQUFBzABhiVodHRwOi8vQUQxOS0yLnN1cHBvcnQucmNkZXZzLmNv

bS9vY3NwMEUGA1UdEQQ+MDygHwYJKwYBBAGCNxkBoBIEEPt33dwit8VIpkoX8x4R

/mqCGUFEMjItMS5zdXBwb3J0LnJjZGV2cy5jb20wTgYJKwYBBAGCNxkCBEEwP6A9

BgorBgEEAYI3GQIBoC8ELVMtMS01LTIxLTI1NTY3ODgxNDgtMjY1MDY4NjczMi01

MDYyMDUwNDktMjE5NTANBgkqhkiG9w0BAQsFAAOCAQEAL4Iuoe+M/zyp54T9Ictn

+QiWaQNbWfq5o/z4xS0kFpS8BBvGcsopxvPQQsLrnsaFDh6p2swYjE59mbXNS2PR

wUDdToNO1xGnM4PjNNMHoIDggsST/+T+TWKiiQuF35q3MaCq3kN5Gr9Nq4UwukQS

2Q8FBkHaDLqTtYGiTo8+LvmSrVgGJUtC6CFAGv+ZIulXC5kWphThmqEiz36RTxvv

BoT+MjLXlW2Bfr4TnxIt+VFd8fpisaBI5GZQ9UkotA2+mM9iAONw8RRp+hcRCPYt

lnSfRR95HCYZ/3dShoXAjchlBUP/xBGeVxWmiEeHuWlXCu9PEJslEVdSU5UOQfCs

2A==

-----END CERTIFICATE-----

subject=CN=AD22-1.support.rcdevs.com

issuer=DC=com, DC=rcdevs, DC=support, CN=SUPCAAD2

---

No client certificate CA names sent

Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512

Shared Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512

Peer signing digest: SHA256

Peer signature type: RSA-PSS

Server Temp Key: X25519, 253 bits

---

SSL handshake has read 2208 bytes and written 409 bytes

Verification: OK

---

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

Server public key is 2048 bit

This TLS version forbids renegotiation.

Compression: NONE

Expansion: NONE

No ALPN negotiated

Early data was not sent

Verify return code: 0 (ok)

---

---

Post-Handshake New Session Ticket arrived:

SSL-Session:

    Protocol  : TLSv1.3

    Cipher    : TLS_AES_256_GCM_SHA384

    Session-ID: 3D73314789721BC1A51ED8C64A9B3D5F54A59EB8D003F8CCA3E72F330A957DAA

    Session-ID-ctx: 

    Resumption PSK: 27066A3E97A6A88B6824D8658D5C00486B521E31CE493FEDA792583A2025048851233EE7592BF47FA8528EA6CD4F9EEA

    PSK identity: None

    PSK identity hint: None

    SRP username: None

    TLS session ticket lifetime hint: 36000 (seconds)

    TLS session ticket:

    0000 - a4 06 00 00 26 7c 93 16-3e 20 de 69 0a 3b d6 a7   ....&|..> .i.;..

    0010 - 04 9e 1a 67 fc 82 58 02-44 5a f8 c5 8e e0 7a c7   ...g..X.DZ....z.

    Start Time: 1711124602

    Timeout   : 7200 (sec)

    Verify return code: 0 (ok)

    Extended master secret: no

    Max Early Data: 0

---

read R BLOCK

Regards

[Gexproof]

openssl s_client -connect dc.domain.com:389

Returns this:

CONNECTED(00000003)
write:errno=104
---
no peer certificate available

---
No client certificate CA names sent

---
SSL handshake has read 0 bytes and written 293 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported

Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

---

errno=104 means "Connection reset by peer"

maybe some domain policy issue ?

пятница, 22 марта 2024 г. в 19:27:05 UTC+3, Yoann Traut (RCDevs):

[Benoît Jager (RCDevs)]

Hello,

Can you share your version of openssl using following command:

openssl version

[Gexproof]

OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)

вторник, 26 марта 2024 г. в 18:01:57 UTC+3, Benoît Jager (RCDevs):

[Benoît Jager (RCDevs)]

Hello,

Did you renew LDAP certificate from Computer certificate store?

Can you check if it is well signed with sha 256? You can see this by:

1. opening certlm.msc
2. In Personal⇾Certificates, double-click on LDAP certificate and check on Details tab that signature is well sha256

If not, you can renew the certificate with right-button of mouse on certificate entry, then "select All Tasks"⇾"Renew Certificate with New Key..."

[Gexproof]

Yeeah! It works now.

Just "Domain controller" cert should to be requested after CA cert was updated with sha256.

Thank you very much for your help!

P.S. Maybe you should mention sha256 issue in your manuals )

среда, 27 марта 2024 г. в 10:44:40 UTC+3, Benoît Jager (RCDevs):

[Gexproof]

works only with

port="636"

encryption="SSL"

389 port still can't request cert via openssl s_client -connect 10.13.177.60:389

but it is not critical already )

четверг, 28 марта 2024 г. в 17:28:39 UTC+3, Gexproof:

[Benoît Jager (RCDevs)]

Hello,

Can you try openssl command with starttls

openssl s_client -starttls ldap -connect 10.13.177.60:389

In servers.xml TLS must be configured instead of SSL, when port 389 is configured.

[Gexproof]

openssl s_client -starttls ldap -connect 10.13.177.60:389 

works fine

Thanks again!

четверг, 28 марта 2024 г. в 18:17:43 UTC+3, Benoît Jager (RCDevs):