#IdFriday | LDAP Signing Changes in Windows Server 2025 - Part 1

And
Sep 27
4 min read

Updated: Nov 1

Windows Server 2025 Group Policy showing LDAP server signing requirements enforcement

IAM Guides for IT and Security Teams

Identity Risks in Focus: LDAP Signing and Channel Binding

LDAP has been the quiet workhorse of identity systems for decades, but Microsoft is about to change the rules. From Windows Server 2025, unsigned LDAP traffic will no longer be allowed, which will break things if you’re not ready.

This three-part blog explains what’s changing, why it matters, and how to prepare before your upgrade projects.

A Real World Question

One of our customers inquired about the changes to the LDAP protocol this week, as they are about to start a major Windows Server 2025 upgrade project. We were pleased to help.

In this particular scenario, the customer wanted to know what the changes actually meant for them in terms of applications currently using LDAP Binds on port 389, and what the impact would be during the migration.

Microsoft introduced this change with the release of Windows Server 2025 on November 1, 2024, to close a common vulnerability and reduce the attack surface for applications integrated into hybrid Active Directory environments.

In busy technical worlds, the term 'just make it work' is all too common, and when you're working across teams, platforms, countries and whatever other boundaries you face, it's all too easy to forget that 'just make it work' has implications on security.

The Problem with unsigned LDAP Binds

This has certainly been true over the past twenty years or so, as businesses have integrated their business-critical apps and interfaces using unsigned LDAP binds over TCP port 389 & 3268 which means that:

Passwords
Payloads
Confidential attributes

...are all passed in clear text (assuming the LDAP application is using a non-TLS connection here). If you are using TLS, that's covered later in this blog series.

We also need to consider here any applications that use SASL-based authentication mechanisms that do not request signing.

Which means, all LDAP traffic, including your domain administrator's LDAP bind, is passed in clear text. Okay, the password is BER64 encoded, so you'll see this on the wire.

A couple of minutes with Wireshark and you'll see the problem all too clear!

For more information, see Microsoft Article

Haven’t we already fixed this?

Okay - you've been using Certificate Services, and our AD servers are enrolled for LDAP server signing.

Great, but LDAP signing hasn't been enforced prior to Windows Server 2025, so all earlier versions will still allow unsigned LDAP traffic, which can result in the BIND or SASL mechanism being negotiated unsigned.

You may be unaware of any certificate issues; however, the app or client may have downgraded to using an unsigned session due to any of the following:

Human errors
Temporary app BIND configurations
SASL apps that do not request signing

...and you've got a long list of potential weak spots

What's new in Windows Server 2025 for LDAP Signing?

In Windows Server 2025, Microsoft has made the policy settings:

Adopted LDAP signing Enforcement by default
Enabled LDAP Channel Binding support to 'when supported ' by default

This change now helps to prevent LDAP man-in-the-middle attacks, covered below:

Channel Binding Tokens (CBTs) Explained

CBT (aka Extended Protection for Authentication, LDAP RFC 5056) are a mechanism that prevents other protocols from hijacking an originating protocol's request and relaying the request to be used for some other purpose:

Here's an example:

A Domain Admin connects to a Windows File share over SMB
That request is then forwarded (unbeknownst to the user) to an LDAP request to add a user account to the Domain Admins group

CBTs use an NTLM challenge-response request to bind the protocol and the originating authentication request, thereby preventing authentication relaying and protecting against this style of attack.

What's affected?

Apps using unsigned LDAP Binds will fail to connect to the directory. This also includes Simple Authentication and Security Layer (SASL) mechanisms, which utilise NTLM, Digest, Kerberos, and the Negotiate protocol, that don't request signing, also known as integrity validation.

Just in case you still have it hanging around... It's worth noting that Windows XP clients do not support either LDAP signing or Channel Binding Token; all versions of Windows following XP will work. Either way, you shouldn't be using unsupported/unpatched versions of Windows. If you do, consider how you can isolate these as part of the upgrade project, as they're no longer supported.

What about non-Microsoft Platforms?

We've never seen any non-Windows platform which don't support LDAP signing (not to say there aren't any, but they are rare)

For CBT:

Some support outside of the Windows domain, e.g. RED HAT Link (link below),
Always check with your vendor to understand their position and factor in any necessary upgrades or actions in the upgrade programme.

See, Impact of Microsoft Security Advisory ADV190023 | LDAP Channel Binding and LDAP Signing on RHEL and AD integration. - Red Hat Customer Portal

Policy Setting changes in Windows Server 2025

With Windows Server 2025, Microsoft has updated LDAP-related policies. It’s important to distinguish what’s new, what’s changed, and what’s just a reference.

New policies introduced in Windows Server 2025

Local Computer Policy\Security Settings\Local Policies\Security Options

Domain controller: LDAP server signing requirements Enforcement (default setting | Enabled)

Network security: LDAP client encryption requirements - (default setting | Negotiate Sealing)

The Policy that has been changed in Windows Server 2025

Domain controller: LDAP server channel binding token requirements  (default setting | when supported)

Previously: Not defined (in Windows Server 2022 and earlier)

For comparison — Windows Server 2022 and earlier defaults (reference only):

Local Computer Policy\Security Settings\Local Policies\Security Options

Domain controller: LDAP server channel binding token requirements  (default setting | not defined)

Domain controller: LDAP server signing requirements (default setting | none)

Network security: LDAP client signing requirements (default setting | not defined)

Domain Controller: LDAP Server Signing Requirements - has been superseded by Domain Controller: LDAP Server Signing Requirements Enforcement. This can be confusing, as the names are similar, just in case you were wondering.