LDAPS option has been depricated in 10.8

Products Auditor Ideas
, ,
1

What is a one sentence summary of your feature request?

Enable TLS/SSL again!

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

With Nevada’s recent cyber-attack 2025, we are aggressively working on hardening our infrastructure, which one of the options is disabling LDAP, and enabling LDAPS port 636.

It appears to now be deprecated in Auditor 10.8.

AI Query reports:

The Real Behavior in Netwrix Auditor 10.8
In version 10.8, Netwrix made a design change:
There is no longer a UI option to enable LDAPS (port 636) for Active Directory data collection.
Instead:

Netwrix Auditor always uses standard LDAP/GC ports (389/3268) for domain discovery.
When secure communication is supported, Auditor automatically uses Global Catalog SSL (port 3269) — but only under specific internal conditions.
Auditor 10.8 does not support forcing LDAPS (port 636) in the UI.

This is not a bug or misconfiguration — it’s the intended behavior for 10.8.

How do you currently solve the challenges you have by not having this feature?

I can’t solve it. LDAPS has been removed from current version 10.8 15792.

Is there a method for securing this communication, Certificate signing?

2

Thank you for raising this.

Nothing has changed in Netwrix Auditor 10.8 regarding LDAPS support. Netwrix Auditor has not historically relied on LDAPS (port 636) for Active Directory data collection, so it was not removed or deprecated in this version.

Instead, the product uses LDAP with Sign and Seal, which provides encryption and integrity protection for LDAP traffic through the standard Windows security mechanisms (Kerberos/NTLM).

If your environment recently changed security settings (for example enforcing LDAP signing or modifying domain controller policies), it is possible that the communication stopped working due to configuration changes rather than a product behavior change.

If you continue experiencing issues, please open a support case so the team can review your environment configuration in detail.

Thank you

3

We have to keep Netwrix in our Risk Register because it is the only application left that does not support ldaps and this prevents us from requiring LDAP Server Signing on the Domain Controller. This is an audit finding we have to accept the risk on every year. I expect there must be an issue if you have been avoiding it this long but to have to explain to an auditor that one of the tools we use on the Security side of the bank is the reason we haven’t implemented their recommendation is odd to say the least.

4

Hi ebriz,

Thanks for flagging this as part of the annual risk acceptance review. Before we finalize our response for the audit, we’d like to clarify a couple of points.
Could you confirm which Netwrix component(s) are referenced in the original audit finding — e.g., Netwrix Auditor for Active Directory or another module?
Also, could you clarify what is specifically meant by “LDAP Server Signing” in this context? We’d like to confirm whether this refers to LDAP Signing and Sealing (SASL/Kerberos-based integrity protection), which is already implemented in our environment — if so, we’d like to understand whether that would satisfy the requirement, or whether LDAPS (LDAP over SSL/TLS) specifically is needed.

5

I appreciate the response to my post. We use Netwrix Auditor. When we tested the Group Policy change below Netwrix was unable to connect to our domain controllers. We have attempted to migigate this from the client side but ultimately if the DCs do not require the higher level of security the vulnerability remains.

This is the specific finding from our 2025 Internal Pen Test.

Condition: The Lightweight Directory Access Protocol (LDAP) implementation within the Active Directory environment was not secured using channel binding and signing technologies. However, no opportunities to capture and relay the traffic to exploit this configuration were identified.

Root Cause: BANK has attempted to implement channel binding and signing technologies but has identified multiple applications in the environment which do not support the security controls and was forced to revert the stronger LDAP configurations.

Implication: An attacker with network access who captured hashed account credentials could relay the hashed credentials to another computer not enforcing strong LDAP security standards to fully compromise the account.

Recommendation: BANK should secure LDAP connections using channel binding and signing. Once secured, BANK should perform follow up reviews to determine if LDAP secure implementations have been configured. BANK should start by configuring optional LDAP client signing within Active Directory using Group Policy. Once systems have been determined to be negotiating signing, BANK should modify Group Policy to require signing for all communications. Alternatively, LDAP over SSL/TLS (LDAPS) can be configured to meet the LDAP signing requirement such as on non-Windows machines.

More information on enabling required LDAP signing can be found below:

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server

Regarding LDAP channel binding, BANK should configure optional channel binding within Active Directory Group Policy. Once all LDAP clients are using optional channel binding, BANK should configure channel binding to be required. It should be noted that LDAPS does not solve this requirement, and non-Windows implementations will often require working with the vendor. To help identify systems not supporting channel binding,

Microsoft’s article below may assist:

2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for Windows (KB4520412) - Microsoft Support

Mentioned previously, LDAPS can assist with meeting at least the signing requirement through encrypted LDAP traffic using trusted certificates. This method of securing LDAP is often more supported by miscellaneous vendor systems compared to signing itself. Therefore, BANK may need to work with their vendors to understand how current systems could support more secure LDAP connections such as upgrading the system version or requesting a new feature. However, it should be noted that LDAPS would require internal certificate management knowledge and processes which can be quite complex.

Microsoft’s guide on supporting LDAPS using a third-party signed certificate can be found below:• Enable Lightweight Directory Access Protocol (LDAP) over Secure Sockets Layer (SSL) - Windows Server | Microsoft Learn

2 Likes