Verständnisfrage: xmlexesensoren und Credentials

Guten Tag,

beim Ausführen von Skript Sensoren kann das Skript entweder im Kontext des Probe Dienstes ausgeführt werden, was in der Regel "Lokales System" wäre oder Sie stellen im Sensor ein, dass er im Kontext der Windows Zugangsdaten des übergeordneten Gerätes ausgeführt werden soll, also "Zugangsdaten für Windows", welche im Register "Einstellungen" des Gerätes konfiguriert sind.

Beim Powershell Skript kann es evtl. auch an etwas anderem liegen, ich würde hierzu diesen Artikel zunächst empfehlen, was es zu beachten gibt, damit Powershell Skripte als Sensor ausgeführt werden können.

Freundliche Grüße,

Erhard Mikulik

Hallo Herr Mikulik,

das skript funktioniert in der Powershell auf dem Probe Server ohne Probleme. D.h. das Skript wurde vorher ausgiebig getestet und die Credentials wurden als paramater übergeben, so dass das Skript auf den zu abfragenden Server ordnungsgemäß zugreifen kann. Alles funktioniert zu 100%.

Wenn ich das Powershell Skript als Sensor auf dem Server, auf dem der Sensor hingehört, einrichte, dann muss ich die Option "Zugangsdaten für Windows des übergeordneten Geräts verwenden" aktivieren, weil es mit der Option "Sicherheitskontext des Probe-Dienstes verwenden" nicht funktioniert. In diesem Fall bekomme ich die Fehlermeldung "Inhaltsfehler: Access denied (Code: PE024)".

Verwende ich aber den ScheduledTask2XML.exe als Sensor, dann funktioniert das mit der Option "Sicherheitskontext des Probe-Dienstes verwenden".

Warum geht das ein, aber das andere nicht? Obwohl beide als "Programm/Skript (Erweitert)"-Sensor angelegt sind?

Freundliche Grüße, Patrick

Hallo Patrick,

der Sensor ist ja nur "das Vehikel" und nur weil das mit einer Exe-Datei so funktioniert (welche nichts mit Powershell macht, meines Wissens), heißt das nicht, dass es bei jedem x-beliebigen Skript dann auch so funktionieren muss.

Wenn es manuell in Powershell funktioniert, dann ist auch der Benutzerkontext ein anderer, weil das Skript ja im Kontext des angemeldeten Benutzers ausgeführt wird und eben das scheint nicht zu funktionieren, wenn PRTG dies versucht als "Lokales System" auszuführen.

Warum das nun bei der Exe "einfach so" funktioniert und bei dem Powershell Skript nur unter Verwendung der Windows Zugangsdaten, kann ich so einfach leider nicht beantworten, das kann letztlich an irgendwelchen Systemrichtlinien liegen, die das unterbinden, dass das Powershell Skript unter "Lokales System" ausgeführt wird.

Freundliche Grüße,

Erhard

Hallo Erhard,

ich habe nun mit "Lokales System" getestet. Meine Erkenntnis ist, das "Lokales System" nicht in der Lage ist Pfade vernünftig zu interpretieren/folgen, wie auch immer man es nennen mag. Es gehen warhscheinlich nur freigaben im Netzwerk, aber keine lokalen Pfade.

Mein eigentliches Skript ist wahrscheinlich nicht mal das Problem, sondern die credentials xml-Datei, welche aus dem Skript heraus aufgerufen wird. Denn "Lokales System" kann diese nicht öffnen, weil schlicht der Pfad nicht gefunden wird, was dann in PRTG mit Access Denied übersetzt wird.

Schade, denn so wäre PRTG noch viel felxibler einsetzbar und man könnte manche Sensoren auch den Geräten zuordnen, für die der/die Sensor(en) gedacht sind.

Hallo Patrick,

wie verhält es sich denn wenn im Sensor eingestellt wird, dass das Skript im Sicherheitskontext der Windows Zugangsdaten des übergeordneten Gerätes ausgeführt werden soll? Evtl. kann es auch helfen die besagte xml-Datei in dem Ordner mit abzulegen, wo auch das Skript liegt.

Viele Grüße,

Erhard

Hallo Erhard,

wie ich am Anfang mal geschrieben hatte, lief das Skript bereits im Sicherheitskontext mit Windows Zugangsdaten. Allerdings nur mit dem berechtigten User der Probe. Das wollen wir aber nicht. Es soll wie bei allen Geräten der Berechtigte User aus der Domäne sein. Mit diesem funktioniert das Skript aber nicht, weil die Probe nicht Teil der Domäne ist. Ebenfalls teil des Sicherheitskonzepts.

Wir hatten es dennoch mit dem Probe User versucht und das lief mit den meisten Sensoren ohne Probleme. Einzig das es unser Sicherheitskonzept "pervertierte" was wir nicht wollen. Außerdem existierte doch ein Sensor, der mit dem Probe User nicht funktionierte.

Aus diesem Grund haben wir jetzt diese Sensoren, welche das Skript ausführen auf die Probe umgezogen.