LDAP Synthetic connectivity

Rob_Doce — Wed, 04 Feb 2026 11:29:33 GMT

Good morning,

We are experiencing issues getting the LDAP Synthetic extension to work in Dynatrace. The extension is fully configured, but it always returns an SSL handshake error, as shown in the following ActiveGate log entry:

[912d4363-e154-343e-ade5-629f15259bb5][-5664247153095800450][3658611][err]

2026-02-03 17:04:15,006 [ERROR] (ThreadPoolExecutor-0_0):

DEC:127 Unknown error. Failed to connect to LDAP Server on

ldaps:// XXXXXX.servidores.net:636 - ssl :

("('socket ssl wrapping error: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE]

ssl/tls alert handshake failure (_ssl.c:1017)',)",)

Initially, this pointed to a potential connectivity issue between the ActiveGate and the LDAP server. However, we have verified that network connectivity from ActiveGate is correct, by using the command: openssl s_client -connect XXXXXX.servidores.net:636
We have also verified TLS 1.2 negotiation and the server certificate, confirming that:

The certificate includes valid SAN entries
The cipher suite is compatible
TLS 1.2 is correctly negotiated

After ruling out connectivity and TLS configuration issues, we used ldapsearch from the ActiveGate host to validate the LDAP parameters used in the extension and to confirm that the LDAP connection itself works correctly.

The bind operation succeeds (correct user and password), and the LDAP server returns the expected namingContexts.

We then executed the exact same LDAP query from the ActiveGate using ldapsearch, matching all parameters configured in the LDAP Synthetic extension (Bind DN, Base DN,pass, filter, LDAPS, port 636).
This test returns data successfully.

Summary

From the ActiveGate host, we can confirm:

TLS 1.2 works correctly
The LDAP certificate is valid and trusted
Bind DN and Base DN are correct
LDAP searches return results
No SSL/TLS handshake errors occur

From the LDAP Synthetic extension:

The configuration is exactly the same
The connection fails with SSLV3_ALERT_HANDSHAKE_FAILURE
The error originates from Python SSL (_ssl.c:1017), according to the log

Despite using the same configuration, the extension consistently fails to connect to LDAP, which leads us to believe that the issue is related to how the LDAP Synthetic extension establishes the SSL/TLS connection. It’s possible that the extension’s Python runtime is using different SSL libraries or SSL handling logic than the one used by ldapsearch on the ActiveGate host.

Has anyone encountered a similar issue with the LDAP Synthetic extension, or can you provide guidance on how SSL/TLS is handled internally by this extension?

I’m not really sure how python manage this connections. The problem seems to be due a TLS/SSL compatibility problem in the extension (python), maybe pyOpenSSL is not installed or something like that…

Best regards,
Rob Doce

topic LDAP Synthetic connectivity in Extensions

LDAP Synthetic connectivity