mTLS 0- Schannel Not Requesting Client Cert for LDAPS mTLS on Windows Server 2022

Question

Setup:

I have an application running on external machine (machine.test.local) that uses LDAP to authenticate users against a Windows Server 2022 Active Directory Domain Controller (W22Server.test.local) over LDAPS (port 636). I want to secure and authenticate the channel between the app server and AD using mutual TLS (mTLS). The client cert (CN=machine, issued by W22SERVER-CA) is mapped to CN=machine,CN=Computers,DC=test,DC=local in AD.

Expectations:

Per mTLS specs, Schannel should request a client certificate during the handshake and this "cert should be used as a "password" for binding / App should authenticate to AD using this cert without a password, leveraging mTLS for a secure, authenticated channel.

Registry Keys Used:

HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL:

ClientAuth=2 ??? this is one of many failed attempts

ClientAuthTrustMode=0

SendTrustedIssuerList=0

EventLogging=7 # This does not work :( how to enable more logs??

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters:

CertificateMappingMethods=0x1f (all mapping methods).

LDAPServerIntegrity=2 (require signing).

Issues:

mTLS Failure: I assume Schannel does not request the client cert and LDAP bind (ldapsearch -D "CN=machine,...") fails with DSID-0C090C92 ("successful bind must be completed"), despite correct AD mapping, cert mappin Altsec addons etc. Password-based binds work fine.

Logging: Schannel logs don’t appear in Applications and Services Logs >;Microsoft > Windows > Schannel—only generic events in System. How I can enable more logs?

Repro:

openssl s_client -connect W22Server.test.local:636 -cert machine.cer -key machine.key -CAfile CA_CHAIN.pem - confirms certs operational

ldapsearch fails when using certs to auth (It works with standard password)

Is this a bug in Schannel/LDAPS integration on Server 2022, or am I missing a config to enforce mTLS bind?

---

./ldap_certs_machine.sh

ldap_initialize( ldaps://W22Server.test.local:636/??base )

filter: (objectclass=*)

requesting: All userApplication attributes

extended LDIF

LDAPv3

base (default) with scope subtree

filter: (objectclass=*)

requesting: ALL

search result

search: 2

result: 1 Operations error

text: 000004DC: LdapErr: DSID-0C090C92, comment: In order to perform this opera

tion a successful bind must be completed on the connection., data 0, v4f7c

numResponses: 1

./ldap_certs_machine.sh: line 6: -s: command not found

cat ldap.conf

BASE cn=users,dc=test,dc=local

URI ldaps://W22Server.test.local:636

TLS_CACERT /etc/ldap/CA_CHAIN.pem

TLS_CERT /etc/ldap/machine.cer

TLS_KEY /etc/ldap/machine.key

TLS_REQCERT demand #(none fails too)

TLS_CRLCHECK none

cat ldap_certs_machine.sh

#!/bin/bash

ldapsearch -v -H ldaps://W22Server.test.local:636 \

-x \

-D "CN=MACHINE,CN=Computers,DC=test,DC=local" \ # object exists with certificate attribute

-b "CN=Users,DC=test,DC=local" \

-s sub "(objectClass=*)"

---

Please share your thoughts.

Answer 1

Hello ARTUR_777,

Thank you for posting in Microsoft Community forum.

Is your environment related to cloud or Azure?

If you have any question or concern, please feel free to let us know.

Please note：

Windows Client for IT Pros and Windows Server forums are moving to Microsoft Q&A

We’re transitioning to Microsoft Q&A for a more streamlined experience. Starting February 26th, new questions can only be posted on Microsoft Q&A. Existing discussions will remain accessible here. 

Beginning March 3rd customers looking for support on Answers will be automatically redirected to Microsoft Q&A.

Best Regards,
Daisy Zhou

Answer 2

Hi,

Applies to: ON-PREM - Windows Server 2022 / Directory services / Certificates and public key infrastructure (PKI)

Answer 3

Hello

Greetings!

Here is some suggestion for your reference.

mTLS and LDAP Bind
1.Even though Schannel is “mTLS‐capable” and your TLS handshake shows that the client certificate is working (as you verified with openssl), Active Directory’s LDAP service isn’t (by default) “replacing” the password in a simple bind with the TLS client certificate. In other words, even though you expect the certificate to serve as a “password” (or credential) because the TLS channel was mutually authenticated, AD still “expects” the application to perform the correct LDAP binding method.

2.AD supports certificate mapping (and smart‐card logon) but that mapping is used with the SASL “EXTERNAL” mechanism rather than with a simple bind (–D "CN=machine…"). When you try to use a simple bind without a password, AD cannot complete the authentication because the certificate that was presented during the TLS handshake is not automatically “elevated” to a successful bind credential. That’s why you see errors (e.g. DSID-0C090C92 with “successful bind must be completed”).

3.The current behavior isn’t a bug in Schannel or AD on Server 2022. It’s just that Windows AD LDAP does not “swallow” the TLS client-certificate and use it as equivalent to binding with a password unless you use the SASL EXTERNAL mechanism.
What to Do
If you want to leverage mTLS entirely as your “authentication” channel you must change your bind method. In particular, use SASL EXTERNAL instead of a simple (DN) bind. Several LDAP clients support “EXTERNAL” as the authentication mechanism – with that, AD will map the cert (via certificate mapping settings in your domain controller) to a user account (and therefore logon accordingly). Note that the mapping rules must be correct (e.g. using subject name lookups, UPN matching, etc.) so that the certificate you send is associated with CN=machine,... in AD.

Registry Keys and Logging
1.The key ClientAuth=2 and ClientAuthTrustMode=0 (and SendTrustedIssuerList=0) have been suggested in some troubleshooting guides. However, they affect which issuers are sent or how the client-side cert selection works – they do not “force” AD’s LDAP service to use certificate mapping as the bind mechanism.
2.For Schannel logging, in Windows Server 2022 the Operational log for Schannel may not be enabled by default. You need to make sure the Schannel channel is enabled in Event Viewer (for example, using wevtutil set-log Microsoft-Windows-SChannel/Operational /enabled:true). 
3.Also note that many Schannel errors are written to the System log as generic events.

Please note：

Windows Client for IT Pros and Windows Server forums are moving to Microsoft Q&A

We’re transitioning to Microsoft Q&A for a more streamlined experience. Starting February 26th, new questions can only be posted on Microsoft Q&A. Existing discussions will remain accessible here. 

Beginning March 3rd customers looking for support on Answers will be automatically redirected to Microsoft Q&A.

Best Regards,
Daisy Zhou

Answer 4

Daisy,

I would like to thank you for trying to help. However, If you don't know the answers please let others respond, and mainly please don't paraphrase questions, this is not helping IMHO.

I want to know HOW TO enable more logs and HOW TO enable SCHANNEL to send a request for Client Certificate. (If this is possible) The KEY ClientAuth=2 is not documented at all ! - maybe there is another KEY that must be configured. A configuration is what I am looking for ...

My question is "Schannel Not Requesting Client Cert for LDAPS mTLS" - how to enable it / control it. Are there any other settings? (To my vague understanding mTLS is a build-in feature in SSL protocol itself - please do not quote me on this) Example: IIS has dedicated package for Client Authentication maybe I missed something when setting up LDAP or maybe this is simply not supported ...

---

SASL

Active Directory (AD) does support the Simple Authentication and Security Layer (SASL) EXTERNAL mechanism; however, its implementation is limited. Specifically, AD permits the use of SASL EXTERNAL only over LDAP connections that are secured using the STARTTLS operation on port 389. Attempts to use SASL EXTERNAL over LDAPS (LDAP over SSL/TLS) on port 636 are not supported and will result in errors.

This behavior is documented in Microsoft's official documentation, which states that while AD supports the EXTERNAL SASL mechanism, it does not permit the use of SASL-layer encryption or integrity verification mechanisms on SSL/TLS-protected connections. This means that SASL EXTERNAL is intended for use with STARTTLS on port 389, not with LDAPS on port 636. Microsoft Learn

Additionally, community discussions have highlighted this limitation. Users have reported that while SASL EXTERNAL works fine on port 389 with STARTTLS, it fails on port 636 with LDAPS, resulting in errors indicating an invalid authentication method. Microsoft Learn

Therefore, while AD does support SASL EXTERNAL, its use is restricted to non-SSL/TLS connections that utilize STARTTLS on the standard LDAP port (389).

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/989e0748-0953-455d-9d37-d08dfbf3998b?utm_source=chatgpt.com

SASL works on 389: ( THAT IS NOT "FULLY" ENCRYPTED)

cat sldap_SASL.sh

#!/bin/bash

export LDAPTLS_CERT=/etc/ldap/machine.cer

export LDAPTLS_KEY=/etc/ldap/machine.key

export LDAPTLS_CACERT=/etc/ldap/CA_CHAIN.pem

ldapsearch -v -H ldap://W22SERVER.test.local:389 \

-Y EXTERNAL \

-b "" -s base "(objectClass=\*)" -ZZ

./sldap_SASL.sh

ldap_initialize( ldap://W22SERVER.test.local:389/??base )

SASL/EXTERNAL authentication started

SASL username: cn=machine

SASL SSF: 0

filter: (objectClass=*)

requesting: All userApplication attributes

extended LDIF

LDAPv3

base <> with scope baseObject

filter: (objectClass=*)

requesting: ALL

dn:

domainFunctionality: 7

forestFunctionality: 7

domainControllerFunctionality: 7

rootDomainNamingContext: DC=pentest,DC=local

ldapServiceName: test.local:w22server$@TEST.LOCAL

isGlobalCatalogReady: TRUE

supportedSASLMechanisms: GSSAPI

[...]

---

Logs

C:\Users\Administrator>wevtutil set-log Microsoft-Windows-SChannel/Operational /enabled:true

Failed to read configuration for log Microsoft-Windows-SChannel/Operational.

The specified channel could not be found.

wevtutil set-log Microsoft-Windows-SChannel/Operational /enabled:true

wevtutil : Failed to read configuration for log Microsoft-Windows-SChannel/Operational.

At line:1 char:1

+ wevtutil set-log Microsoft-Windows-SChannel/Operational /enabled:true

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (Failed to read ...el/Operational.:String) [], RemoteException

    + FullyQualifiedErrorId : NativeCommandError

The specified channel could not be found.