find the client responsible for the schannel ldap error
Solution 1
Built-in you can't find easily the source of the message.
You need tcpdump, microsoft network monitor or wireshark to find the machine causing the error. (many thread told the same, there, there or there (See in the comment the answer to George about tcpdump))
Solution 2
If you are able to capture the traffic flowing to DC for analysis then you can use Wireshark's packet search to find certificates being presented.
This wireshark filter looks for certificate exchange and filters out anything issued by "LDAP SSL test", this would allow you to find certs not issued by your domain.
(ssl.handshake.type == 11) && !(x509sat.uTF8String == "LDAP SSL test")
I don't have an AD example to work on so that is using a standard LDAP over TLS pcap from the wireshark samples page.
Related videos on Youtube
natxo asenjo
Updated on September 18, 2022Comments
-
natxo asenjo almost 2 years
somewhere in our network an ldap client is querying our AD servers without the proper CA information. This provokes the (in my view useless) system critical (source: schannel) event id 36887 on the domain controllers' event log:
The following fatal alert was received: 46.
How can I locate the misconfigured client?
-
Admin almost 8 yearsDoes this error keeps happening? Or it just happened once?
-
Admin almost 8 yearsit keeps happening to the ldap servers in the default first site, so the client is contained to those ip ranges.
-
-
natxo asenjo almost 8 yearsI tend to agree, and it sucks ;-) (not your comment, the situation). Another solution would be to turn off schannel loggging altogether, but that may have unexpected effects.
-
natxo asenjo almost 8 yearsthat was a nice suggestion, but the webserver role is not installed in these domain controllers (2008r2).
-
natxo asenjo almost 8 yearsthanks for the script. Our infrastructure is a mix of windows and linux clients, so this would only cover a part of it. Nice idea, though.