Secure LDAP monitoring with PRTG

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

Jul, 2018 - Permalink

Please vote here: https://helpdesk.paessler.com/en/support/solutions/articles/81588-feature-request:-implement-ldaps-sensor

Sep, 2018 - Permalink

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

Jan, 2019 - Permalink

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

Jan, 2019 - Permalink

---

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/

Feb, 2019 - Permalink

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

Feb, 2019 - Permalink

Much appreciated, as always :)

---

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

Kind regards,
Stephan Linke, Tech Support Team

Feb, 2019 - Permalink