find the client responsible for the schannel ldap error

Question

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?

it keeps happening to the ldap servers in the default first site, so the client is contained to those ip ranges. — natxo asenjo, Sep 19 '16 at 17:16

score 8 · Answer 1 · answered Sep 12 '16 at 18:36

8

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))

answered Sep 12 '16 at 18:36

yagmoth555

16,300
4
26
48

2

I 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 Sep 13 '16 at 12:17
@natxoasenjo another thing I seen is for ldap I see reference that the logging is done via iis, maybe to check the iis log directory to find the ip/request's done to be able to find the ip faster. (it will allow to compare the time stamp of both log) – yagmoth555 Sep 19 '16 at 17:39
that was a nice suggestion, but the webserver role is not installed in these domain controllers (2008r2). – natxo asenjo Sep 20 '16 at 07:02

score 3 · Answer 2 · answered Sep 18 '16 at 16:01

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.

score 0 · Answer 3 · edited Apr 13 '17 at 12:14

I have very little experience with Windows/AD administration, however I am comfy with Linux. I thought I'd do a trace and/or packet capture, run the program in debug mode, etc... in a similar Linux situation... so I found this:

How do you trace/debug LDAP connections against Active Directory?

And this:

https://technet.microsoft.com/en-us/library/cc961809.aspx

Increasing the level increases the detail of the messages and the number of messages emitted. Setting the value of entries in the Diagnostics subkey to greater then 3 can degrade server performance and is not recommended. The application event log fills up quickly when the logging level is increased.

And this maybe:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd815339(v=vs.85).aspx

Tracing uses Event Tracing for Windows (ETW). To take advantage of the tracing tools available with Windows Server 2008 R2, install the Microsoft Windows SDK from the MSDN Downloads site.

A google search also turns up results on performing traces and such on Windows services, but again, I'm not familiar with any of it. I would imagine watching network traffic alone could be very difficult, because you're only seeing traffic and probably don't know what to look for and you're not really seeing what's happening within the service.

I have no idea what kind of output to expect from performing a trace on ldap or using any of the tools/methods mentioned, but it seems like it's worth a try.

Good luck

score 0 · Answer 4 · edited May 26 '17 at 15:49

If you don't want packet sniffing, I would recommend a powershell script in all the computers testing a secure ldap connection and logging who fails. You could connect remotely to the clients from the Domain Controller or you could make a client side script who logs failures on a fileserver.

The ideia of the script is to simulated a secure ldap connection. It uses .net framework that comes natively on windows 7 sp1 or higher.

In case you want to run remotely from the DC, the script would look like this (requires permission for remote powershell which can be achieved following this article https://www.briantist.com/how-to/powershell-remoting-group-policy/):

Import-Module ActiveDirectory
$domain = "contoso.com"
$user = "Administrator"
$password = "P@ssw0rd"
$IPFilter = "192.168.1.*"

$scriptblock = {
   write-host "$(hostname) - " -NoNewLine
   try {
      $LDAPS = New-Object adsi ("LDAP://$($args[0]):636",$args[1],$args[2],'SecureSocketsLayer')
      Write-Host "Secure LDAP Connection succeeded."
   } Catch {
      Write-Host "Secure LDAP Connection failed." -foregroundcolor red
   }
}

$Computers = Get-ADComputer -filter * -Properties IPv4Address | Where{ $_.IPv4Address -like $IPFilter}

foreach($Computer in $Computers)
{
   try {
      $session = New-PSSession $Computer.Name -ErrorAction Stop
      Invoke-Command -Session $session -ScriptBlock $scriptblock -ArgumentList $domain,$user,$password
   }catch{
      Write-Host "Connection to $($Computer.Name) failed." -foregroundcolor red
   }
}

Or if you want a local script which logs into a remote server:

$domain = "contoso.com"
$user = "Administrator"
$password = "P@ssw0rd"
$LogFile = "\\fileserver\logs\ldapconnection.log"

try {
   $LDAPS = New-Object adsi ("LDAP://$domain:636",$user,$password,'SecureSocketsLayer')
   "$(hostname) - Secure LDAP Connection succeeded."  | Out-File $LogFile -Append
} Catch {
   "$(hostname) - Secure LDAP Connection failed."  | Out-File $LogFile -Append
}

Output of a remote version execution (red ones are offline clients):

thanks 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. — natxo asenjo, Sep 20 '16 at 07:04

find the client responsible for the schannel ldap error

4 Answers4