trouver le client responsable de l'erreur ldap schannel

quelque part dans notre réseau, un client LDAP interroge nos serveurs AD sans les informations d'autorité de certification appropriées. Cela provoque l'ID d'événement critique système (source: schannel) (à mon avis inutile) 36887 dans le journal des événements des contrôleurs de domaine:

L'alerte fatale suivante a été reçue: 46.

Comment localiser le client mal configuré?

Intégré, vous ne pouvez pas trouver facilement la source du message.

Vous avez besoin de tcpdump, Microsoft Network Monitor ou Wireshark pour trouver la machine à l'origine de l'erreur. (plusieurs threads ont dit la même chose, là , là ou là (voir dans le commentaire la réponse à George à propos de tcpdump))

Si vous êtes en mesure de capturer le trafic circulant vers DC pour analyse, vous pouvez utiliser la recherche de paquets de Wireshark pour trouver les certificats présentés.

Ce filtre Wirehark recherche l'échange de certificats et filtre tout ce qui est émis par le "test LDAP SSL", cela vous permettrait de trouver des certificats non émis par votre domaine.

(ssl.handshake.type == 11) && !(x509sat.uTF8String == "LDAP SSL test")

Je n'ai pas d'exemple AD sur lequel travailler, c'est-à-dire en utilisant un pcap LDAP sur TLS standard à partir de la page d'exemples de lightshark.

J'ai très peu d'expérience avec l'administration Windows / AD, mais je suis à l'aise avec Linux. Je pensais que je ferais une capture de trace et / ou de paquets, exécuterais le programme en mode débogage, etc ... dans une situation Linux similaire ... alors j'ai trouvé ceci:

Comment tracer / déboguer des connexions LDAP par rapport à Active Directory?

Et ça:

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

L'augmentation du niveau augmente le détail des messages et le nombre de messages émis. La définition d'une valeur supérieure à 3 pour les entrées de la sous-clé Diagnostics peut dégrader les performances du serveur et n'est pas recommandée. Le journal des événements d'application se remplit rapidement lorsque le niveau de journalisation est augmenté.

Et cela peut-être:

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

Le suivi utilise le suivi des événements pour Windows (ETW). Pour tirer parti des outils de suivi disponibles avec Windows Server 2008 R2, installez le SDK Microsoft Windows à partir du site de téléchargement MSDN.

Une recherche Google révèle également des résultats sur l'exécution de traces et autres sur les services Windows, mais encore une fois, je ne connais rien de tout cela. J'imagine que regarder le trafic réseau seul pourrait être très difficile, car vous ne voyez que du trafic et vous ne savez probablement pas quoi chercher et vous ne voyez pas vraiment ce qui se passe dans le service.

Je n'ai aucune idée du type de sortie à attendre de l'exécution d'une trace sur ldap ou de l'utilisation des outils / méthodes mentionnés, mais il semble que cela vaille la peine d'essayer.

Bonne chance

Si vous ne voulez pas renifler de paquets, je recommanderais un script PowerShell sur tous les ordinateurs testant une connexion LDAP sécurisée et enregistrant les échecs. Vous pouvez vous connecter à distance aux clients à partir du contrôleur de domaine ou créer un script côté client qui enregistre les échecs sur un serveur de fichiers.

L'idée du script est de simuler une connexion LDAP sécurisée. Il utilise le framework .net qui est natif sur Windows 7 SP1 ou supérieur.

Dans le cas où vous souhaitez exécuter à distance à partir du contrôleur de domaine, le script ressemblerait à ceci (nécessite une autorisation pour le PowerShell distant qui peut être obtenue à la suite de cet article https://www.briantist.com/how-to/powershell-remoting-group- politique / ):

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

Ou si vous voulez un script local qui se connecte à un serveur distant:

$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
}

Sortie d'une exécution de version à distance (les rouges sont des clients hors ligne):