PsExec - Netzwerkpfad wurde nicht gefunden / Couldnt access Target

[-byTe-]

Hallo zusammen,

vielleicht kann mich ja war aufklären.
Wir hatten hier im Betrieb vor einigen Jahren das Tool PsExec genutzt, um Software, Dienste, Konfigurationen und vieles mehr auf den Clients zu verteilen/upzudaten.
Leider ist das Tool etwas in Vergangenheit geraten, möchte es aber jetzt wieder verstärkt für meine Aufgaben nutzen - habe aber nun feststellen müssen, dass sich offensichtlich was geändert hat (Firewall?, Windows-updates?, ...), sodass das Tool nun beim Aufruf eines Ziels folgende Fehlermeldung bringt:

In der Firewall habe ich schon gegengeprüft:

Datei- und Druckerfreigabe (SMB eingehend/ausgehend) ist aktiviert - und es funktioniert auch mit einem Rechner, der nicht im Domänennetzwerk ist.

Bei allen anderen Rechnern im Domänennetzwerk greift offenbar eine Richtlinie, die dafür sorgt, dass "SMB über TCP" blockiert ist - ich vermute, dass hier der Hund begraben ist. Nur welche GPO steuert diesen Eintrag? Ich habe nichts auf dem Server gefunden, bin hier aber noch etwas grün hinter den Ohren....
Womöglich liegt es aber auch an etwas ganz anderem, hat wer noch einen Rat?

PS: Zuletzt funktioniert hatte es noch mit Windows10 (Clients), ist vielleicht gar Windows11 schuld?

Gruß
-byte-

 

[kartoffelpü]

Nur welche GPO steuert diesen Eintrag?

Dann setz dich mal mit gpresult auseinander, um die entsprechende Policy zu finden (sofern es von einer Policy kommt). Könnte man häufiger benötigen.

Kannst du dich denn mit dem entsprechenden User über den Explorer auf \\192.168.1.59\c$ verbinden, oder geht das auch nicht?

 

[Korben2206]

soweit ich weiß braucht psexec port 135 und 445.
Kannst ja mal testen:

Test-NetConnection 192.168.x.y -Port 135
Test-NetConnection 192.168.x.y -Port 445

Möglich das Windows 11 da per default sich anders verhält. Oder das dir da eine GPO entgangen ist.

Edit: 135, nicht 137, sorry

 

[just_f]

SMB alleine reicht da denke ich nicht - die Prerequisites alle erfüllt?

 

[Korben2206]

Na sowas.. da steht 139... irgendwie sind sich die Webseiten da aber nicht einig....

Ergänzung (13. Januar 2025)

Hm.. also ich denke 135 ist der richtige (RPC). 137-139 sind Netbios-Dienste... aber so gut kenne ich mich da auch nicht aus...

 

[-byTe-]

Hoppla, so schnell schon Rückmeldung. Top, danke euch.

Zuerst:

Kannst du dich denn mit dem entsprechenden User über den Explorer auf \\192.168.1.59\c$ verbinden

Nein, das geht ebenfalls nicht. Es funktioniert nur bei dem PC, der nicth in der Domäne ist und damit auch die GPO nicht erhält.

Mit gpresult habe ich mich schon oberflächlich auseinandergesetzt und die ganzen GPOs (in Summe 12 Stück) exportiert und durchgeforstet. Nur den Eintrag nicht gefunden, aber ich verstehe das vermutlich noch nicht richtig...

Kannst ja mal testen

Der Test mit 135 ist erfolgreich, mit 445 (und auch 139) allerdings nicht:

die Prerequisites alle erfüllt

Das muss ich nochmal im Detail prüfen. Zumindest sind Einträge in der Firewall (eingehend + ausgehend) mit dem entsprechendem Port hinterlegt.

Ich berichte weiter, sobald ich mehr Details gesammelt und mich eingelesen habe.

Vielen Dank euch!

Gruß
-byte-

 

[kartoffelpü]

Ok, also erstmal musst du erreichen, dass TCP445 erreichbar ist. Ohne das dürfte in der Richtung gar nichts gehen.
Ist auf den DomainPCs evtl. weitere Software installiert, die es unterbinden könnte?

Kannst auch mal im Resourcenmonitor schauen, ob der Port überhaupt offen ist:

Wenn du das hast, kannst du weiter testen. Existiert denn der lokale Benutzer "admin" auch auf den Domain-PCs?

 

[-byTe-]

Kannst auch mal im Resourcenmonitor schauen, ob der Port überhaupt offen ist:
Anhang anzeigen 1569389

Port 445 ist offensichtlich nicht offen:

Da muss ich also explizit nochmal in den GPOs prüfen, welcher Eintrag dafür sorgt, dass dieser Port geschlossen wird.

Wenn du das hast, kannst du weiter testen. Existiert denn der lokale Benutzer "admin" auch auf den Domain-PCs?

Das ist von meinem obigen Screenshot vmtl etwas irreführend; es sind auf dem Rechner mehrere Admin-Profile hinterlegt; genau einen dieser Profile habe ich über PsExec genutzt (da steht noch was vor dem "Admin" :-) ). Profil ist auch funktionabel; das habe ich schon lokal am Client getestet.

Danke euch nochmal, ich meld mich sobald ich fündig geworden bin (oder auch nicht )...

Grüße

 

[-byTe-]

So, neue Erkenntnisse. Dazu zwei Fragen:

1. In der Gruppenrichtlinien-GUI des ADs sind (wie oben angesprochen) ca. 12 GPOs definiert:

gpresult an den Client-PCs (mehrere probiert) zeigt mir allerdings "nur" zwei an:

Ist das so korrekt? Ich wäre jetzt laienhaft der Meinung, dass offensichtlich nicht alle Regeln abgerufen/ausgeführt wurden. Mit "gpupdate /force" habe ich schon nachgeholfen, jedoch gleiches Ergebnis.

Nachtrag: Selbst blöd, wenn man nur die Hälfte des Reports im CMD liest. Das waren nur die Richtlinien der Benutzereinstellungen. Die Richtlinien der Computereinstellungen sind weiter oben vollständig abgebildet. Dort sind auch einige Richtlinien aufgrund der Filterung nicht aktiv ("WMI" und "Sicherheit"). Es bleibt spannend...

2. Ich habe in der Regel zu "Windows 10" den Eintrag "SMB über TCP" gefunden. Im Export-File der Regel wird folgendes angezeigt:

Wenn ich jetzt aber auf dem Server in der entpsrechenden GPO nachschauen will, ist dort der Eintrag zu eingehenden Regeln komplett leer:

Kann es sein, dass diese Regel früher mal Bestand hatte und jetzt (Serverupdate/upgrade?) nicht mehr greift? Mir ist aufgefallen, dass die Regel unter "Windows-Firewall mit erweitereter Sicherheit" liegt und in der Server-GPO aber "Windows Defender Firewall mit erweiterter Sicherheit" lautet.
Könnte das auch der Grund sein, dass dann bei den Clients genau dieser Eintrag ("SMB über TCP") geschlossen wird?

So langsam habe ich das Gefühl, dass hier etwas ganz gewaltig nicht stimmt.

Vielen Dank im Voraus

LG

 

[-byTe-]

Der Vollständigkeit halber: ich habe die entsprechende Regel gefunden. Es handelt sich um "Windows SBS Client Policy". Wenn die dortige "Computerkonfigurationseinstellung" deaktiviert wird, verschwindet der blockierte Port 445 und der Weg für PsExec wäre frei:

In "eingehenden Regeln" für die Firewall war nichts definiert.

Ich habe allerdings folgenden Eintrag gefunden:

Wer genau hinsieht, bemerkt 2 Punkte. In der nächsten Einstellung findet sich die gleiche IP mit einem Punkt wieder; daher ging ich davon aus, dass eine Einstellung verkehrt ist. Habe es entsprechend abgeändert; nun scheint PsExec wieder zu funktionieren!
Dass eine "fehlerhafte" IP an dieser Stelle für einen blockierten Port sorgt hätte ich tatsächlich nicht gedacht. Wieder was gelernt👍

Danke an alle Beteiligten!

 

[kartoffelpü]

Danke für die Auflösung