Active Directory Security and certificates
LDAP signing, TLS, and channel binding
Identify the bind and transport, interpret Server 2025 policy precedence, and test the protection the application actually negotiates.
Identify the session before the setting
Start with the target server, port, transport, authentication method and client library. The same application can make several kinds of LDAP connection. A bind succeeding tells you that one path worked, but not how it was protected.
| Session | Integrity and confidentiality | Relevant server control |
|---|---|---|
| Simple bind without TLS | Credentials and LDAP data lack transport protection | Signing requirement rejects this bind |
| SASL without TLS, signed | Integrity; signing alone does not encrypt the data | Server signing requirement |
| SASL without TLS, sealed | Integrity and encryption supplied by SASL | Server signing requirement is satisfied |
| Simple bind over TLS | TLS protects the transport; client certificate validation matters | CBT policy does not apply |
| SASL over TLS | TLS transport plus the chosen authentication package | CBT policy applies |
| Client certificate authentication over TLS | TLS and certificate authentication | No LDAP CBT exchange |
This distinction is documented in Microsoft’s LDAP session security matrix. LDAP on 389 can negotiate StartTLS. LDAPS starts TLS on connection to 636; GC equivalents are 3268 and 3269. AD replication uses separate interfaces, so enabling LDAPS does not move replication to 636.
Signing and sealing are different
Signing gives integrity and authenticity to applicable non-TLS SASL LDAP traffic. Sealing adds confidentiality. TLS also supplies integrity, encryption and server authentication, provided the client validates the certificate. Requiring LDAP signing rejects unprotected simple binds as well as SASL binds that do not request the required protection. It does not require every LDAP session to use TLS. LDAP signing overview.
A capture showing unreadable LDAP data might therefore indicate SASL sealing on 389. A capture showing TCP 636 establishes neither the bind identity nor successful certificate validation. Record the negotiated behavior instead of inferring security from a port or a GUI checkbox.
Server 2025 has an additional enforcement policy
Windows Server 2025 introduces Domain controller: LDAP server signing requirements enforcement. It takes precedence over Domain controller: LDAP server signing requirements. With enforcement enabled, a value of None in the older setting does not make the DC permissive. New AD deployments require signing by default; upgrades preserve an existing signing policy, and require signing if no prior server policy exists. Policy precedence and upgrade behavior.
Check the resulting computer policy on each affected DC, including the winning GPO and any explicit compatibility setting. Note its OS build and patch date too. In a mixed estate, the result can depend on which DC the application selects.
The older registry settings remain useful evidence. Run this on the DC being investigated, with rights to read its configuration:
$parameters = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
Get-ItemProperty -Path $parameters |
Select-Object LDAPServerIntegrity,LdapEnforceChannelBinding
gpresult /scope computer /h C:\Temp\dc-computer-policy.html
The report writes a local file; create a suitable restricted output directory first. LDAPServerIntegrity=2 corresponds to Require signing. A missing value doesn’t settle the effective policy, and LDAPServerIntegrity alone isn’t enough on Server 2025. The signing/channel-binding registry mappings are in KB4520412.
Channel binding binds authentication to TLS
CBT ties SASL authentication to the TLS channel so authentication relayed through a different TLS connection fails validation. It applies to SASL over TLS, including Kerberos; it is particularly relevant to NTLM relay. It does not add a CBT to simple bind or certificate bind. Microsoft documents these CBT applicability rules.
LdapEnforceChannelBinding |
Meaning |
|---|---|
0, Never |
No CBT validation |
1, When supported |
CBT-capable clients must send a valid token; unsupported clients can still connect |
2, Always |
Every applicable TLS/SASL bind must supply a valid token |
New Server 2025 AD deployments default to When supported. That permits a compatibility class of clients; it is not equivalent to Always. A TLS inspection or termination component also changes the path that must be tested. A direct connection and a connection through a proxy can have different CBT results.
Separate TCP, TLS, bind and search
Work through the failure in order:
- Confirm DNS resolves the intended DC and that the target listener is reachable.
- Establish TLS using the FQDN the application actually requests.
- Perform the intended bind, with the intended identity and authentication method.
- Run a small search the identity is authorized to perform.
For an interactive TLS test, open ldp.exe, choose Connection → Connect, specify the DC FQDN and port 636, and select SSL. Then use Connection → Bind to test the intended authentication. RootDSE output after connection is not proof that a privileged bind succeeded.
For a DC certificate, check Server Authentication EKU, matching DNS name, validity, trusted chain and access to its private key. AD DS prefers a suitable certificate in the NTDS service’s Personal store over the Local Computer store. Multiple eligible certificates make it necessary to verify what the server actually presents. The current LDAPS certificate guide explains store selection and certificate renewal. Use the chain and revocation procedure when transport fails before LDAP authentication.
Enforce against measured compatibility
Find the clients, fix their library/configuration and test the corrected connection before staging signing or CBT enforcement on a controlled set of DCs. Know which policy to reverse if a particular application fails. Test authenticated requests against every reachable DC; one successful DC behind a discovery name can hide differences.
Use LDAP client auditing to distinguish accepted unsafe binds, rejected binds and missing-token clients. A quiet log means little if logging was disabled, collection missed a DC, or the scheduled application did not run. Test an expected success and an expected rejection after a change. For an unsigned-simple-bind rejection test, use an isolated lab and disposable nonprivileged credentials: the test itself transmits a password without TLS.