4
PowerShell: import-csv scheitert an Dateirechten von einigen Servern
Hallo zusammen,
ich schreibe grade ein PowerShell Skript für unsere PRTG-Überwachung. Dabei stehe ich jetzt vor folgendem Problem, welches sich mir nicht erschließt.
Damit das Skript richtig ausgeführt werden muss, muss ich im PRTG einen Benutzernamen und ein Kennwort mitgeben. Da das Skript nicht auf dem PRTG-Server selbst sondern auf einem anderen Server ausgeführt werden soll, muss ich folglich mit einem Invoke-command arbeiten. Das hat bislang auch gut funktioniert. Jetzt soll ein CSV-Datei eingelesen werden. Das ganze eigentlich recht simpel:
Der erste Teil, also $Cred und $Server ist bei mir mittlerweile standardisiert und funktioniert. Jetzt hat mein Skript mir jedoch kein Ergebnis ausgegeben, obwohl ich mir sicher war, dass alles richtig ist. Also habe ich ein paar Prüfwerte im Skript hinzugefügt und ausgegeben. Dabei musste ich feststellen, dass der oben genannte Befehl nicht durchgeführt werden kann:
Ok. Das ist irritierend, denn die Datei die importiert werden soll ist definitiv vorhanden und für den Benutzer auch sichtbar. Um das ganze noch einmal zu verifizieren, habe ich $Server verändert. Ich habe hier wahllos einige meiner Server genommen. Die DC, den Printserver, den Fileserver, den Management-Server. Ich habe immer den gleichen Benutzer genommen und von manchen Servern geht es, von anderen schlägt es fehl.
Fehlerhaften Benutzernamen/Kennwort kann ich ausschließen, da dies durch $Cred immer identisch ist. Außerdem habe ich das Kennwort einmal verändert (absichtlich falsch). In dem Fall erhalte ich dann als FullyQualifiedErrorID: LogonFailure.
WinRM funktioniert an sich ja auch, denn er meckert ja nicht, dass der Rechner nicht erreicht werden kann, sondern, dass ich keinen Zugriff auf die Datei habe. Auch das habe ich zum testen nun einmal ausprobiert. Selbst als Domain-Admin (Besitzer der Datei) erhalte ich die gleiche Fehlermeldung. OK.. also die Dateirechte überprüft. Die sind korrekt. Und um es ganz sicher zu gehen habe ich an den funktionierenden und nicht funktionierenden Rechnern die Gruppenrichtlinien geprüft (WINRM wird via GPO gesteuert). Sowohl laut gpresult als auch auch rsop.msc sind die entsprechenden Einstellungen identisch.
Damit nicht genug: auch get-executionpolicy -list zeigt keine unterschiedlichen Einstellungen an.
Also habe ich mich nun mit dem Benutzer unter dem ich den FileOpenFailure bekomme, also $Cred an dem $Server angemeldet, die dem Invoke-command befehl mitgegeben werden. Dort habe ich eine PowerShell-Konsole geöffnet (ohne Adminrechte) und in der PowerShell-Konsole den Befehl eingegeben:
wurde dann erfolgreich ausgeführt und ich hab den Inhalt der CSV-Datei gesehen.
Und jetzt sitze ich hier ratlos und verstehe nicht, wieso der Befehl lokal funktioniert, via Invoke-Command unter den gleichen Berechtigungen jedoch nicht und wieso er bei manchen Servern ausgeführt werden kann, wenn doch alle Server die gleichen WINRM-Einstellungen via GPO erhalten.
Die Dateiberechtigungen stimmen auch und funktionieren ja auch von einigen Geräten.
WinRM funktioniert auch. Ich habe jetzt während ich dieses Posting verfasst habe noch etwas mit Test-Path und anderen Dateien herumprobiert, auf die Zugriff besteht. Sofern ich auf den schon identifizierten Servern ein Test-path auf die Datei sende, sagt mir PowerShell true. Führe ich das ganze von unserem Monitor-Server innerhalb eines Invokes mit dem am Server angemeldeten Benutzer aus, scheitert auch der Test-Path.
So.. nun sitze ich hier und kriege immer mehr graue Haare. Vielleicht hat ja der eine oder andere eine Idee was ich vergessen habe oder woran es liegt.
Server sind allesamt Windows Server 2019.
Gruß
Doskias
PS: Sorry für die Wall of text
ich schreibe grade ein PowerShell Skript für unsere PRTG-Überwachung. Dabei stehe ich jetzt vor folgendem Problem, welches sich mir nicht erschließt.
Damit das Skript richtig ausgeführt werden muss, muss ich im PRTG einen Benutzernamen und ein Kennwort mitgeben. Da das Skript nicht auf dem PRTG-Server selbst sondern auf einem anderen Server ausgeführt werden soll, muss ich folglich mit einem Invoke-command arbeiten. Das hat bislang auch gut funktioniert. Jetzt soll ein CSV-Datei eingelesen werden. Das ganze eigentlich recht simpel:
invoke-command -Credential $Cred $Server {Import-Csv \\Fileserver\Datei.csv -Delimiter ";"} Der erste Teil, also $Cred und $Server ist bei mir mittlerweile standardisiert und funktioniert. Jetzt hat mein Skript mir jedoch kein Ergebnis ausgegeben, obwohl ich mir sicher war, dass alles richtig ist. Also habe ich ein paar Prüfwerte im Skript hinzugefügt und ausgegeben. Dabei musste ich feststellen, dass der oben genannte Befehl nicht durchgeführt werden kann:
Der Zugriff auf den Pfad "\\Fileserver\Datei.csv" wurde verweigert.
CategoryInfo : OpenError: (: ) [Import-Csv], UnauthorizedAccessException
FullyQualifiedErrorId : FileOpenFailure,Microsoft.PowerShell.Commands.ImportCsvCommand
PSComputerName :$Server
CategoryInfo : OpenError: (: ) [Import-Csv], UnauthorizedAccessException
FullyQualifiedErrorId : FileOpenFailure,Microsoft.PowerShell.Commands.ImportCsvCommand
PSComputerName :$Server
Ok. Das ist irritierend, denn die Datei die importiert werden soll ist definitiv vorhanden und für den Benutzer auch sichtbar. Um das ganze noch einmal zu verifizieren, habe ich $Server verändert. Ich habe hier wahllos einige meiner Server genommen. Die DC, den Printserver, den Fileserver, den Management-Server. Ich habe immer den gleichen Benutzer genommen und von manchen Servern geht es, von anderen schlägt es fehl.
Fehlerhaften Benutzernamen/Kennwort kann ich ausschließen, da dies durch $Cred immer identisch ist. Außerdem habe ich das Kennwort einmal verändert (absichtlich falsch). In dem Fall erhalte ich dann als FullyQualifiedErrorID: LogonFailure.
WinRM funktioniert an sich ja auch, denn er meckert ja nicht, dass der Rechner nicht erreicht werden kann, sondern, dass ich keinen Zugriff auf die Datei habe. Auch das habe ich zum testen nun einmal ausprobiert. Selbst als Domain-Admin (Besitzer der Datei) erhalte ich die gleiche Fehlermeldung. OK.. also die Dateirechte überprüft. Die sind korrekt. Und um es ganz sicher zu gehen habe ich an den funktionierenden und nicht funktionierenden Rechnern die Gruppenrichtlinien geprüft (WINRM wird via GPO gesteuert). Sowohl laut gpresult als auch auch rsop.msc sind die entsprechenden Einstellungen identisch.
Damit nicht genug: auch get-executionpolicy -list zeigt keine unterschiedlichen Einstellungen an.
Also habe ich mich nun mit dem Benutzer unter dem ich den FileOpenFailure bekomme, also $Cred an dem $Server angemeldet, die dem Invoke-command befehl mitgegeben werden. Dort habe ich eine PowerShell-Konsole geöffnet (ohne Adminrechte) und in der PowerShell-Konsole den Befehl eingegeben:
Import-Csv \\Fileserver\Datei.csv -Delimiter ";" Und jetzt sitze ich hier ratlos und verstehe nicht, wieso der Befehl lokal funktioniert, via Invoke-Command unter den gleichen Berechtigungen jedoch nicht und wieso er bei manchen Servern ausgeführt werden kann, wenn doch alle Server die gleichen WINRM-Einstellungen via GPO erhalten.
Die Dateiberechtigungen stimmen auch und funktionieren ja auch von einigen Geräten.
WinRM funktioniert auch. Ich habe jetzt während ich dieses Posting verfasst habe noch etwas mit Test-Path und anderen Dateien herumprobiert, auf die Zugriff besteht. Sofern ich auf den schon identifizierten Servern ein Test-path auf die Datei sende, sagt mir PowerShell true. Führe ich das ganze von unserem Monitor-Server innerhalb eines Invokes mit dem am Server angemeldeten Benutzer aus, scheitert auch der Test-Path.
So.. nun sitze ich hier und kriege immer mehr graue Haare. Vielleicht hat ja der eine oder andere eine Idee was ich vergessen habe oder woran es liegt.
Server sind allesamt Windows Server 2019.
Gruß
Doskias
PS: Sorry für die Wall of text
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6163444500
Url: https://administrator.de/contentid/6163444500
Ausgedruckt am: 23.11.2024 um 09:11 Uhr
4 Kommentare
Neuester Kommentar
Hi,
altbekanntes Problem, nennt sich double-hop:
Ausführen des zweiten Hops in PowerShell-Remoting
altbekanntes Problem, nennt sich double-hop:
Ausführen des zweiten Hops in PowerShell-Remoting
- Sie sind bei ServerA angemeldet.
- Sie starten von ServerA aus eine PowerShell-Remotesitzung, um eine Verbindung mit ServerB herzustellen.
- Ein auf ServerB über Ihre PowerShell-Remotesitzung ausgeführter Befehl versucht, auf eine Ressource auf ServerC zuzugreifen.
- Der Zugriff auf die Ressource auf ServerC wird verweigert, da die Anmeldeinformationen, die Sie zum Erstellen der PowerShell-Remotingsitzung verwendet haben, nicht von ServerB an ServerC übergeben werden.
Danke. Der Artikel ergibt durchaus Sinn, das erklärt auch warum es manchmal geht und manchmal nicht. Bei
MGMT -> App (mit cred) -> Fileserver (ohne Cred)
habe ich dann einen double-Hop. Den habe ich auch, wenn ich den APP durch einen der DC ersetze. Dann sieht es so aus:
MGMT -> DC (mit cred) -> Fileserver (ohne Cred)
Dann habe ich ja immernoch den double-hop, aber es funktioniert, weil die DC die Anmeldeinformationen nicht weitergeben müssen.
Frage ich hingegen den Fileserver direkt ab, dann sieht es so aus:
MGMT -> Fileserver (mit cred) -> Fileserver (ohne Cred)
In dem Fall habe ich zwar ein \\Fileserver\ bin ja aber schon auf dem Fileserver, also habe ich diesbezüglich offenbar kein double-Hop, so dass es auch funktioniert.
Hab mir jetzt die Server nochmal angeschaut wo es ging und wo es nicht ging. De wo es ging waren entweder die Fileserver auf denen die Datei lag oder DC. Habe es aus Neugier auch nochmal mit anderen Dateien in anderen Freigaben getestet und es liegt wirklich am double-hop, den ich bislang wohl immer umschifft habe. Wenn man mal ehrlich ist, ist es auch keine schöne Programmierung, aber ich wollte meine Struktur in den PRTG-Skripten gerne beibehalten. Naja, dann wohl nicht
Bin ja froh, dass es an sowas banalen liegt und nicht irgendwo ein Konfigurationsfehler in unser Serverlandschaft zu sporadischen und unerklärlichen Dateizugriffsvfehlern führt. Das hätte mir grade noch gefehlt.
MGMT -> App (mit cred) -> Fileserver (ohne Cred)
habe ich dann einen double-Hop. Den habe ich auch, wenn ich den APP durch einen der DC ersetze. Dann sieht es so aus:
MGMT -> DC (mit cred) -> Fileserver (ohne Cred)
Dann habe ich ja immernoch den double-hop, aber es funktioniert, weil die DC die Anmeldeinformationen nicht weitergeben müssen.
Frage ich hingegen den Fileserver direkt ab, dann sieht es so aus:
MGMT -> Fileserver (mit cred) -> Fileserver (ohne Cred)
In dem Fall habe ich zwar ein \\Fileserver\ bin ja aber schon auf dem Fileserver, also habe ich diesbezüglich offenbar kein double-Hop, so dass es auch funktioniert.
Hab mir jetzt die Server nochmal angeschaut wo es ging und wo es nicht ging. De wo es ging waren entweder die Fileserver auf denen die Datei lag oder DC. Habe es aus Neugier auch nochmal mit anderen Dateien in anderen Freigaben getestet und es liegt wirklich am double-hop, den ich bislang wohl immer umschifft habe. Wenn man mal ehrlich ist, ist es auch keine schöne Programmierung, aber ich wollte meine Struktur in den PRTG-Skripten gerne beibehalten. Naja, dann wohl nicht
Bin ja froh, dass es an sowas banalen liegt und nicht irgendwo ein Konfigurationsfehler in unser Serverlandschaft zu sporadischen und unerklärlichen Dateizugriffsvfehlern führt. Das hätte mir grade noch gefehlt.
Zitat von @Doskias:
Danke. Der Artikel ergibt durchaus Sinn, das erklärt auch warum es manchmal geht und manchmal nicht. Bei
MGMT -> App (mit cred) -> Fileserver (ohne Cred)
habe ich dann einen double-Hop. Den habe ich auch, wenn ich den APP durch einen der DC ersetze. Dann sieht es so aus:
MGMT -> DC (mit cred) -> Fileserver (ohne Cred)
Dann habe ich ja immernoch den double-hop, aber es funktioniert, weil die DC die Anmeldeinformationen nicht weitergeben müssen.
Frage ich hingegen den Fileserver direkt ab, dann sieht es so aus:
MGMT -> Fileserver (mit cred) -> Fileserver (ohne Cred)
In dem Fall habe ich zwar ein \\Fileserver\ bin ja aber schon auf dem Fileserver, also habe ich diesbezüglich offenbar kein double-Hop, so dass es auch funktioniert.
Hab mir jetzt die Server nochmal angeschaut wo es ging und wo es nicht ging. De wo es ging waren entweder die Fileserver auf denen die Datei lag oder DC. Habe es aus Neugier auch nochmal mit anderen Dateien in anderen Freigaben getestet und es liegt wirklich am double-hop, den ich bislang wohl immer umschifft habe. Wenn man mal ehrlich ist, ist es auch keine schöne Programmierung, aber ich wollte meine Struktur in den PRTG-Skripten gerne beibehalten. Naja, dann wohl nicht
Du hast ja durchaus die Möglichkeit, dieses Problem zu umgehen, z.B. recht einfach mit Ressourcenbasierter eingeschränkter KerberosdelegierungDanke. Der Artikel ergibt durchaus Sinn, das erklärt auch warum es manchmal geht und manchmal nicht. Bei
MGMT -> App (mit cred) -> Fileserver (ohne Cred)
habe ich dann einen double-Hop. Den habe ich auch, wenn ich den APP durch einen der DC ersetze. Dann sieht es so aus:
MGMT -> DC (mit cred) -> Fileserver (ohne Cred)
Dann habe ich ja immernoch den double-hop, aber es funktioniert, weil die DC die Anmeldeinformationen nicht weitergeben müssen.
Frage ich hingegen den Fileserver direkt ab, dann sieht es so aus:
MGMT -> Fileserver (mit cred) -> Fileserver (ohne Cred)
In dem Fall habe ich zwar ein \\Fileserver\ bin ja aber schon auf dem Fileserver, also habe ich diesbezüglich offenbar kein double-Hop, so dass es auch funktioniert.
Hab mir jetzt die Server nochmal angeschaut wo es ging und wo es nicht ging. De wo es ging waren entweder die Fileserver auf denen die Datei lag oder DC. Habe es aus Neugier auch nochmal mit anderen Dateien in anderen Freigaben getestet und es liegt wirklich am double-hop, den ich bislang wohl immer umschifft habe. Wenn man mal ehrlich ist, ist es auch keine schöne Programmierung, aber ich wollte meine Struktur in den PRTG-Skripten gerne beibehalten. Naja, dann wohl nicht
Bin ja froh, dass es an sowas banalen liegt und nicht irgendwo ein Konfigurationsfehler in unser Serverlandschaft zu sporadischen und unerklärlichen Dateizugriffsvfehlern führt. Das hätte mir grade noch gefehlt.
Zitat von @chaot1coz:
Du hast ja durchaus die Möglichkeit, dieses Problem zu umgehen, z.B. recht einfach mit Ressourcenbasierter eingeschränkter Kerberosdelegierung
Ich weiß nur noch nicht ob ich das will. Muss ich mir nochmal Gedanken machen.Du hast ja durchaus die Möglichkeit, dieses Problem zu umgehen, z.B. recht einfach mit Ressourcenbasierter eingeschränkter Kerberosdelegierung
