16.06.2023, aktualisiert um 16:52:17 Uhr

5644

PRTG WMI Sensoren funktionieren teils - teils

Moin Moin an alle,

ich richte bei uns momentan das PRTG Monitoring ein und bin bei der Erstellung von WMI Sensoren auf einige Merkwürdigkeiten gestoßen. Ich habe bereits mehrere Forum-Posts gelesen und befolgt und bin durch diese leider nicht weiter gekommen.
80070005:-access-is-denied
what-are-the-wmi-compatibility-options
what-are-the-most-common-errors-when-monitoring-wmi

Ich habe bereits bestmöglich alle Lösungsansätze aus den Artikeln angewendet, leider aber ohne Erfolg.

Manche Sensoren wie dieser WMI Remote Ping Sensor kann ohne Probleme direkt angelegt werden, aber gerade der WMI Service Sensor den ich zur Dienst-Überwachung benutzen möchte hängt Ewigkeiten im Ladebalken rum ohne Ergebnis.

Beim testen mit dem WMI-Tester, bekomme ich nur den Fehler Error: 80070005: Zugriff verweigert, das würde es ja erklären, aber ich kann bestimmte WMI Sensoren ja bereits benutzen..

Die Einstellungen sollten soweit richtig sein..

Ich bin seit ein paar Stunden am rum probieren und habe nun keine Ideen mehr.

Nachtrag Das ganze funktioniert auf ein paar Servern, aber auf manchen nicht. Da alle Server in der selben OU sind bekommen sie die selben Gruppenrichtlinien. Benutzen die selbe Domäne und selbe Anmeldecredentials über den Domain Admin vom PRTG aus..
Vielen Dank für eure Zeit.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 7548829657

Url: https://administrator.de/contentid/7548829657

Ausgedruckt am: 21.11.2024 um 16:11 Uhr

22 Kommentare

Neuester Kommentar

Hi,
zuerst einmal ist deine Aussage falsch:

Da alle Server in der selben OU sind bekommen sie die selben Gruppenrichtlinien.

Ob ein Server eine GPO bekommt regelt neben der OU auch noch die Sicherheitsfilterung und die Delegation.

Mir fallen da so spontan Dinge die via GPO gesetzt oder auch nicht gesetzt werden und geprüft werden sollten:
- ist wmi in der Firewall erlaubt ?
- ist der Remote WMI dienst aktiviert ?
- ist an den WMI Berechtigungen was geändert worden?

PS:

selbe Anmeldecredentials über den Domain Admin vom PRTG

SO etwas macht man nicht, nie und nimmer.. auch nicht Außnahmsweise zum testen....

Dafür werden einzelne "Serviceuser" angelegt und speziell berechtigt.

Hallo,

ist bei Euch NTLM erlaubt? PRTG hat Probleme mit Kerberos.

Siehe
Hier

Versuche mal, die Geräte im PRTG mittels FQDN und nicht mit der IP zu verwenden.

Grüße

lcer

Kann @icer00 da zustimmen und ebenso @Delta9 , der Servicebenutzer gehört in die "Protected User" Gruppe damit der auf keinen Fall NTLM spricht.

Das gleiche gilt für die internen Firewall, einschalten und via GPO die Regeln setzen damit PRTG funktioniert, mach es lieber wenn nur ein paar hast, wir haben begonnen alles vor 6 Monaten umzustellen, dass ist dann nicht wenig aufwand

.

Mit "winrm qc" schaltet das ganze überhaupt erst ein, muss man vor allem bei älteren Server Versionen ausführen.

Guten Morgen,

ich habe momentan NTLM Auditing am laufen da ich geplant habe es auszuschalten, aber im Moment ist es noch eingeschalten.

Ich habe es mit dem FQDN schon probiert, leider keinen Erfolg gehabt

Grüße

Moin,

@Delta9 da hast Du Recht,.

Für WMI wurde der Weg komplett vorbereitet, Firewall, GPOs, Berechtigung wollte ich eben mit dem Dom. Admin ausschließen.

Aber ja, ich werde einen Service User anlegen, da habt Ihr Recht mit. @Delta9 @clSchak

Grüße

Florian

So Moin nochmal,

der Service User ist erstellt und die Berechtigungen wurden zugeteilt, leider immernoch die selbe Fehlermeldung: Error: 80070005: Zugriff verweigert.

Alle Veränderungen die ich soweit vorgenommen habe:

Der Service User ist in folgender Service Gruppe:

auf der Firewall sieht es so aus wenn man nach Port 135 filtert, mit Destination Exchange Server und Source PRTG Server.

Die WMI Einstellungen auf dem Exchange Server den ich Überwachen möchte.

Und diese CMDs damit die Firewall auch eine Ausnahme hat, laut Microsoft Anleitung.

netsh advfirewall firewall add rule dir=in name="DCOM" program=%systemroot%\system32\svchost.exe service=rpcss action=allow protocol=TCP localport=135  

netsh advfirewall firewall add rule dir=in name ="WMI" program=%systemroot%\system32\svchost.exe service=winmgmt action = allow protocol=TCP localport=any  

netsh advfirewall firewall add rule dir=in name ="UnsecApp" program=%systemroot%\system32\wbem\unsecapp.exe action=allow  

netsh advfirewall firewall add rule dir=out name ="WMI_OUT" program=%systemroot%\system32\svchost.exe service=winmgmt action=allow protocol=TCP localport=any

Ich habe der Service Gruppe auch mal testweise lokale Adminrechte auf dem Exchange gegeben, hat auch nichts gebracht..

Grüße

Florian

Hallo,

Hast Du den Dienst auf dem Zielserver mit winrm -qc bzw. Winrm -qc -transport:https konfiguriert?

Grüße

lcer

Hoi,

ja habe ich gemacht, Firewall Regeln auch entsprechend auf HTTPS Allow von PRTG zu Exchange gestellt und es funktioniert leider immer noch nicht.

Grüße

Florian

Hallo,

dann poste mal die Ausgabe von:
winrm g winrm/config
winrm e winrm/config/listener

Grüße

lcer

winrm g winrm/config

winrm e winrm/config/listener

Grüße

Florian

Hallo,

zunächst musst Du natürlich die Ports 5985/5986 in der Firewall freigeben. Du hattes HTTPS geschrieben und das hatte ich als 443 verstanden.

Dann ist deine TrustedHosts-Liste leer: https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-c ...

Das konfiguriert man am besten als GPO, geht aber auch manuell.

Grüße

lcer

Moin,

und täglich grüßt das Murmeltier

Policy ist eingerichtet und eingeschalten, der Service wurde auch angepasst auf der FW und der PRTG Server ist in den Trusted Hosts eingetragen, geht trotzdem nicht

*Nachträglich* habe gerade nochmal getestet mit allow all services von prtg zu all, geht trotzdem nicht. Wenn ich aber ein anderen WMI Sensor wie "WMI Terminal Services (2008+)" adden möchte funktioniert der sofort ohne irgendwelche mucken..

Grüße

Flo

Hallo,

bleibt noch https://learn.microsoft.com/de-de/windows/win32/winrm/installation-and-c ... die Gruppe WinRMRemoteWMIUsers__ (neustart des Zielservers erforderlich).

Schau Dir auch mal die Protokolle der Firewall zu der Regel an. Wird da überhaupt was gesendet? wenn ja winrm HTTP oder HTTPS?

Du musst wegen der Kerberos-SPNs zwingend des Hostname als Ziel bei PRTG verwenden. IP geht nicht! Dann solltest Du die SPNs prüfen: siehe https://developer.harness.io/docs/first-gen/firstgen-platform/security/s ... Step 1 und https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windo ...

Ausserdem kann man das Zertifikat überprüfen: https://learn.microsoft.com/en-us/troubleshoot/windows-client/system-man ... Wenn mehrer Zertifikate installiert sind, kann man das gewünschte festlegen. siehe https://knowledge.broadcom.com/external/article/177670/how-to-manually-s ...

Insbesondere der HTTPS-Listener hat uns im Zusammenhang mit PRTG Probleme gemacht. Daher habe ich den gelöscht! und verwende den HTTP-Listener. Die Verbindung sichere ich dafür zusätzlich mittels Windows-Firewall Verbindungssicherheitsregeln ab. Da läuft es dann.

Grüße

lcer

Ohje, dass das so ein Trara wird hatte ich nicht geahnt. Da der Server unser Exchange Server ist muss ich aufjedenfall mit dem runterfahren bis zur nächsten Wartung abwarten, da dies gerade erst war wird es ein bisschen länger gehen.

Was uns aufgefallen ist was ich aber vergessen hatte zu erwähnen ist das der Traffic auf den Ports auf 0 Bytes blieb. Ich habe mal einen Wireshark zuhören lassen als ich den Sensor anlegen wollte, da hat er die Ports 135 und 57XXX benutzt..

Zertifikat sollte in Ordnung sein, ansonten werde ich vllt. schauen ob ich auf HTTP ausweichen kann.

Wir hatten die lokale Firewall auch zusätzlich schon abgeschalten gehabt und es half trotzdem nicht

Grüße

Hallo,

Zitat von @DarkZoneSD:
Wir hatten die lokale Firewall auch zusätzlich schon abgeschalten gehabt und es half trotzdem nicht

Das ist nie die Lösung. Alles in allem ist das etwas unbefriedigend.

Noch etwas Literatur:
https://learn.microsoft.com/de-de/powershell/scripting/learn/remoting/wi ...
https://learn.microsoft.com/en-us/windows/win32/winrm/authentication-for ...

Ich denke, PRTG hat das nicht gut umgesetzt. Das Ticket (siehe oben) wurde bisher auch nicht als erledigt markiert. neulich habe ich folgende Nachricht gelesen:

When can we expect Paessler to take this seriously ????

We have HAD a hacker incident, where the PRTG domain admin account was used to infiltrate an entire AD.

This was due to WMI using NTLM !!!!!

Get this fixed - or loose at least one customer.

Grüße

lcer

Das ist nie die Lösung. Alles in allem ist das etwas unbefriedigend.

Bin ich auch der Meinung, sollte aber eine Fehlkonfiguration bei den FW Regeln ausschließen.

Ich glaube das ich mir ein skript schreiben werde per PS und dann manuell einen Sensor anlege..

Vielen Dank für die Hilfe

Grüße

Hallo,

habe noch folgenden Link gefunden: https://kb.vmware.com/s/article/2119025

Vielleicht hilft es.

Grüße

lcer

Moin,

Ohje, dass das so ein Trara wird hatte ich nicht geahnt

ich weiß nicht was ihr da treibt... wir haben das damals innerhalb von 2 Tagen ausprobiert, getestet und in eine GPO verpackt. Zumal man nicht die produktive Umgebungen für sowas hernimmt, sondern eine Testumgebung. Durch die Menge an verschiedenen Test und Konfiguration ist die Chance groß, dass du nicht mehr alles gängig machst und damit ungewollt ein möglicher Angriffsvektor zurück bleibt.

Wichtig ist,

Bei dem Gerät in PRTG den FQDN als Gerätenamen bzw. IP-Adresse verwenden.
Danach einen Sensor wie PING einrichten. Um so herauszufinden, ob deine Infrastruktur zwischen den PRTG Probe und dem zu überwachen denen Sensor in Ordnung ist. So findet man in der Regel grobe Fehlkonfigurationen heraus.
Danach nimmt man den Service Account für PRTG in die Gruppe der lokalen Administratoren auf dem zu überwachenden Server auf. Nein, ich meine nicht das Benutzerkonto Administrator der Domäne! Somit werden bewusst erst einmal Probleme mit den lokalen Berechtigungen ausgeschlossen.
An den zentralen Firewalls müssen je nach Technologie nur Port 135/Tcp für RPC freigegeben werden. Die dynamischen Ports werden bei Bedarf geöffnet. Wenn das Die Firewall nicht kann so ist der Port Range 49152 – 65535/tcp freigegeben werden.
Auf dem Windows Server gibt es für Remote WMI entsprechende Standard Inbound Regeln. Diese müssen evtl. nur noch aktiviert werden.
Nun auf der PRTG Probe mit dem cmdlet Test-Netconnection -Computername "FQDN des zu überwachenden Servers" -Port 135 ausführen. Wenn das nicht klappt, ist noch ein Fehler auf einer Infrastruktur Komponente zu finden.
...

Gruß,
Dani

Was möchtest du überhaupt überwachen das du WMI benötigst? CPU, RAM, LAN, HDD usw. geht auch per SNMP - auch bei Windows Systemen, macht weniger Arbeit und verursacht weniger Last.

Hallo Dani,

Zitat von @Dani:

Moin,

Ohje, dass das so ein Trara wird hatte ich nicht geahnt

ich weiß nicht was ihr da treibt... wir haben das damals innerhalb von 2 Tagen ausprobiert, getestet und in eine GPO verpackt.

Prinzipiell läuft es bei mir auch. Hast Du mal geschaut, ob in Deinem Setup die Sensoren Kerberos zur Authentifizierung verwenden, oder ob ein Fallback auf NTLM passiert?

Grüße

lcer

Guten Morgen,

Zitat von @Dani:

Moin,

Ohje, dass das so ein Trara wird hatte ich nicht geahnt

Stimmt.. Da muss ich mir mal was einfallen lassen um ein Testsystem zu betreiben, das müsste ich aber vorher sorgfältig planen

Wichtig ist,

Bei dem Gerät in PRTG den FQDN als Gerätenamen bzw. IP-Adresse verwenden.

Erledigt.

* Danach einen Sensor wie PING einrichten. Um so herauszufinden, ob deine Infrastruktur zwischen den PRTG Probe und dem zu überwachen denen Sensor in Ordnung ist. So findet man in der Regel grobe Fehlkonfigurationen heraus.

Es bestehen bereits andere Sensoren und die Empfangen Daten, wie gesagt, manche WMI Sensoren funktionieren auch, aber spezifisch der Windows Service Sensor ( und ein paar andere ) funktionieren nicht.

* Danach nimmt man den Service Account für PRTG in die Gruppe der lokalen Administratoren auf dem zu überwachenden Server auf. Nein, ich meine nicht das Benutzerkonto Administrator der Domäne! Somit werden bewusst erst einmal Probleme mit den lokalen Berechtigungen ausgeschlossen.

Ist auch getan der Service Benutzer ist in den Remoteverwaltungsgruppe, etc. und lokalen Admins

* An den zentralen Firewalls müssen je nach Technologie nur Port 135/Tcp für RPC freigegeben werden. Die dynamischen Ports werden bei Bedarf geöffnet. Wenn das Die Firewall nicht kann so ist der Port Range 49152 – 65535/tcp freigegeben werden.

135 ist freigegeben für den Service, das mit der Port Range müsste ich mal ausprobieren.

* Auf dem Windows Server gibt es für Remote WMI entsprechende Standard Inbound Regeln. Diese müssen evtl. nur noch aktiviert werden.

Sind nach der Microsoft Dokumentation bereits angelegt

* Nun auf der PRTG Probe mit dem cmdlet Test-Netconnection -Computername "FQDN des zu überwachenden Servers" -Port 135 ausführen. Wenn das nicht klappt, ist noch ein Fehler auf einer Infrastruktur Komponente zu finden.

TcpTestSucceeded: True

Gruß,
Dani

Grüße