What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Secure LDAP monitoring with PRTG

Votes:

1

Edit by support:


Hello. We need to monitor the state of LDAPS on our domain controllers. At the moment I found only the LDAP sensor, in which you can change the standard port 389 to another one. Can there be any other sensors to test encrypted connections on port 636?


Здравствуйте. Нам требуется сделать мониторинг состояния LDAPS на наших доменных контроллерах. На данный момент я нашел только датчик LDAP, в котором можно изменить стандартный порт 389 на другой. Может есть какоие-то другие датчики для проверки шифрованных соединений по 636 порту?

active-directory domain-controller ldap ldaps secure-ldap

Created on Jul 2, 2018 3:01:30 PM

Last change on Jul 3, 2018 3:41:43 PM by  Felix Saure [Paessler Support]



7 Replies

Votes:

0

Hi there,

Please refer to the manual, the LDAP Sensor does not support LDAP over SSL I'm afraid.

To check if port 636 is open, you can use the Port Sensor.

Best regards, Felix

Created on Jul 3, 2018 3:40:22 PM by  Felix Saure [Paessler Support]




Votes:

1

XML-Sensor using Powershell:

# ___ ___ _____ ___
#| _ \ _ \_   _/ __|
#|  _/   / | || (_ |
#|_| |_|_\ |_| \___|
#    NETWORK MONITOR
#-------------------
# Description: This sensor will check LDAP Availability 
# Parameters:
# -Port:    The Port you want to connect - 389 Unsecure, 636(defualt) TSL etc...

# Parameters
param(  
    [int]$Port      = 636     
)
clear

$dc = [System.DirectoryServices.ActiveDirectory.Domain]::getCurrentDomain().DomainControllers | Select -First 1
$LDAPS = [ADSI]"LDAP://$($dc.name):$($Port)"
try {
   $Connection = [adsi]($LDAPS)
} Catch {
}

# channels per volume
$resultTemplate = @"
            <result>
               <channel>{0}</channel>
               <value>{1}</value>
               <unit>success</unit>               
               <float>0</float>
            </result>
            
"@

$template_tmp = ""

function This-GetResult(){

    If ($Connection.Path) {

        $placeholders = @($($LDAPS.Path,'1'))
	    $template_tmp = $template_tmp + ([string]::Format($resultTemplate, ($placeholders -replace ",","."))) 
    
    } Else {
        $placeholders = @($($LDAPS.Path,'0'))
	    $template_tmp = $template_tmp + ([string]::Format($resultTemplate, ($placeholders -replace ",","."))) 
    }

    Write-Host "<?xml version='1.0' encoding='UTF-8' ?><prtg>"
    Write-Host $template_tmp
    Write-Host "</prtg>"
}

This-GetResult

Created on Jan 31, 2019 3:03:20 PM

Last change on Jan 31, 2019 7:48:16 PM by  Stephan Linke [Paessler Support]



Votes:

0

Hi Georg,

Thanks for sharing that one! :) Could you elaborate some details about it? When running it on my local machine (which is part of an AD), I get the following:

Ausnahme beim Aufrufen von "GetCurrentDomain" mit 0 Argument(en):  "Der aktuelle Sicherheitskontext ist keiner Active Directory-Domäne oder 
-Gesamtstruktur zugeordnet."
In Zeile:1 Zeichen:1
+ [System.DirectoryServices.ActiveDirectory.Domain]::getCurrentDomain()

It basically complains about the security context not being assigned to any Active Directory-Domain...


PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Created on Jan 31, 2019 7:44:19 PM by  Stephan Linke [Paessler Support]

Last change on Jan 31, 2019 7:48:01 PM by  Stephan Linke [Paessler Support]



Votes:

0


edit by moderator english version of the post below

https://support.microsoft.com/de-de/help/2859144/current-security-context-is-not-associated-with-an-active-directory-do

This is due to the user account or the lack of Powershell authorization. Enabling and using Remote PowerShell and fixing connection problems. To remotely manage a domain controller in PowerShell, the function must first be enabled. To do this, administrators in a PowerShell session on the target server enter the Enable-PSRemoting -Force command. To undo the operation, use Disable-PSRemoting Force (see Figure 3).

https://www.ip-insider.de/diese-active-directory-einstellungen-muessen-admins-kennen-a-494331/


https://support.microsoft.com/de-de/help/2859144/current-security-context-is-not-associated-with-an-active-directory-do

Es liegt am Benutzerkonto oder am Fehlen der Berechtigung der Powershell:

Remote-PowerShell aktivieren, nutzen und Verbindungsprobleme beheben

Damit sich ein Domänencontroller in der PowerShell remote verwalten lässt, muss die Funktion zunächst aktiviert werden. Dazu geben Administratoren in einer PowerShell-Sitzung auf dem Ziel-Server den Befehl "Enable-PSRemoting -Force" ein. Rückgängig machen lässt sich der Vorgang mit "Disable-PSRemoting -Force" (siehe Abbildung 3).

https://www.ip-insider.de/diese-active-directory-einstellungen-muessen-admins-kennen-a-494331/

Created on Feb 1, 2019 6:08:46 AM

Last change on Feb 1, 2019 9:07:37 AM by  Stephan Linke [Paessler Support]



Votes:

1

Great idea... I modified the script a bit - since I saw similar issues as Stephan did... and came up with this - should be easier to read as well..

param(  
    [string]$DCName = "", #will be set to the current logonserver if not set
    [int]$Port      = 636 #636 is default for LDAPS / 389 is default for regular LDAP    
)
#this script will target a single DC and show if the connection was successful

If ($DCName.Length -gt 0) {
    $TargetDC = $DCName;
} Else {
    #$TempDC = [System.DirectoryServices.ActiveDirectory.Domain]::getCurrentDomain().DomainControllers | Select -First 1;
    #$TargetDC = $TempDC.Name
    #you could also use environment variables and grab the logon server - what would be closer then the first DC - depending on the size of your network the above attempt might be an issue
    $TargetDC = [string]($env:LOGONSERVER).Replace("\\","")
}

#we build our connection string...
$LDAPS = [adsi]"LDAP://$($TargetDC):$($Port)";

#let's try to connect to LDAP via the specified port..
$Connection = "";
Try {
    $Connection = [adsi]($LDAPS) 
} Catch {}

If ($Connection.Path.Length -gt 0) {
    $ResultText = $Connection.Path + " " + $Connection.distinguishedName;
    $Success = 1;
} Else {
    $Success = 0;
}

$XML = "
<prtg>
    <result>
        <channel>" + $TargetDC + ":" + $Port + "</channel>
        <value>$Success</value>
    </result>
    <text>$ResultText</text>
</prtg>"


Function WriteXmlToScreen ([xml]$xml) #just to make it clean XML code...
{
    $StringWriter = New-Object System.IO.StringWriter;
    $XmlWriter = New-Object System.Xml.XmlTextWriter $StringWriter;
    $XmlWriter.Formatting = "indented";
    $xml.WriteTo($XmlWriter);
    $XmlWriter.Flush();
    $StringWriter.Flush();
    Write-Output $StringWriter.ToString();
}
WriteXmlToScreen "$XML"

The TRY/CATCH seems to hick up a bit - I never so the CATCH but I didn't care to much since there was an easy way to bypass this and move forward with the script while still getting the results I was looking for...

Note that I change especially the way the DC was detected - I didn't want to go 20 thousand miles around to globe cause my first DC listed was there..

Regards

Florian Rossmark

www.it-admins.com

Created on Feb 1, 2019 4:00:37 PM



Votes:

0

Much appreciated, as always :)


PRTG Scheduler | PRTGapi | Feature Requests | WMI Issues | SNMP Issues

Kind regards,
Stephan Linke, Tech Support Team

Created on Feb 1, 2019 7:32:38 PM by  Stephan Linke [Paessler Support]




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.