17
Windows 10 Verbindung zu Server funktioniert nicht
Hallo an alle, dies ist mein erster Beitrag hier. Ich bitte um Nachsicht 
Ich sitze nun seit mehreren Tagen an einem sehr seltsamen Problem. Wir haben im Netzwerk einen Server, der, um von Clients erreichbar zu sein, eine Firewallfreigabe benötigt. Das funktioniert alles so, wie es soll. Mit Ausnahme eines Clients, der urplötzlich den Zugriff verlor - ohne, dass an den FW-Einstellungen etwas geändert wurde.
Die Clients, die auf den Server zugreifen, laufen unter Windows 10 bzw. 11 Pro. Der Client, der nicht mehr will, unter Windows 10 Education. Soweit erstmal grob das Setting.
Was ist das seltsame daran? Vom störrischen Client aus kann ich den Server problemlos anpingen. Ich kann mich per SSH damit verbinden. Ich kann drauf RDPen. Aber im Windows-Explorer krieg ich ihn ums Verrecken nicht eingebunden oder auch nur angezeigt (weder mit Hostname noch mit IP). Die Windows-Netzwerkdiagnose sagt, es liege kein Problem vor,der Zugriff würde aufgrund eines unbekannten Fehlers nicht funktionieren. Net use meint: Fehler 53, Netzwerkpfad nicht gefunden. Ich habe daraufhin ein bisschen mit den NTLMSSP-Leveln rumgespielt, aber auch das brachte keine Besserung. Netzwerkadapter zurückgesetzt, deinstalliert, neu installiert, die Firewall-"Hosen" am Client runter gelassen, hat alles nichts gebracht.
In Wireshark sieht man, dass die Verbindung aufgebaut wird. Wenn sie aber fertig ist, sendet der Client ein RST,ACK und setzt sie wieder zurück.
Ich vermute nun, dass es vielleicht am (User-)Profil liegt. Der störrische Client ist, wie alle anderen auch, in eine Domäne eingebunden. Der Server nicht.
Hat hier jemand eine zündende Idee? Wenn noch Infos benötigt werden, gerne.
Vielen Dank schon mal!
Pyry
Ich sitze nun seit mehreren Tagen an einem sehr seltsamen Problem. Wir haben im Netzwerk einen Server, der, um von Clients erreichbar zu sein, eine Firewallfreigabe benötigt. Das funktioniert alles so, wie es soll. Mit Ausnahme eines Clients, der urplötzlich den Zugriff verlor - ohne, dass an den FW-Einstellungen etwas geändert wurde.
Die Clients, die auf den Server zugreifen, laufen unter Windows 10 bzw. 11 Pro. Der Client, der nicht mehr will, unter Windows 10 Education. Soweit erstmal grob das Setting.
Was ist das seltsame daran? Vom störrischen Client aus kann ich den Server problemlos anpingen. Ich kann mich per SSH damit verbinden. Ich kann drauf RDPen. Aber im Windows-Explorer krieg ich ihn ums Verrecken nicht eingebunden oder auch nur angezeigt (weder mit Hostname noch mit IP). Die Windows-Netzwerkdiagnose sagt, es liege kein Problem vor,der Zugriff würde aufgrund eines unbekannten Fehlers nicht funktionieren. Net use meint: Fehler 53, Netzwerkpfad nicht gefunden. Ich habe daraufhin ein bisschen mit den NTLMSSP-Leveln rumgespielt, aber auch das brachte keine Besserung. Netzwerkadapter zurückgesetzt, deinstalliert, neu installiert, die Firewall-"Hosen" am Client runter gelassen, hat alles nichts gebracht.
In Wireshark sieht man, dass die Verbindung aufgebaut wird. Wenn sie aber fertig ist, sendet der Client ein RST,ACK und setzt sie wieder zurück.
Ich vermute nun, dass es vielleicht am (User-)Profil liegt. Der störrische Client ist, wie alle anderen auch, in eine Domäne eingebunden. Der Server nicht.
Hat hier jemand eine zündende Idee? Wenn noch Infos benötigt werden, gerne.
Vielen Dank schon mal!
Pyry
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: 64167308935
Url: https://administrator.de/contentid/64167308935
Ausgedruckt am: 19.11.2024 um 00:11 Uhr
17 Kommentare
Neuester Kommentar
Hallo,
| Der Client, der nicht mehr will, unter Windows 10 Education.
Warum läuft dieser mit Windows 10 Education? Vielleicht isst das die Ursache.
Habt ihr keine weitere Wondows 10/ 11 pro Lizenz?
Und gibt es weitere Informationen, welche Du uns bisher nicht genannt hast?
Gruss Penny.
Die Clients, die auf den Server zugreifen, laufen unter Windows 10 bzw. 11 Pro.
ok.| Der Client, der nicht mehr will, unter Windows 10 Education.
Warum läuft dieser mit Windows 10 Education? Vielleicht isst das die Ursache.
Habt ihr keine weitere Wondows 10/ 11 pro Lizenz?
Und gibt es weitere Informationen, welche Du uns bisher nicht genannt hast?
Gruss Penny.
Hallo.
Schon mal mit einem anderen User versucht? Der hat ja ein anderes Profil.
Jürgen
Ich vermute nun, dass es vielleicht
am (User-)Profil liegt.
am (User-)Profil liegt.
Schon mal mit einem anderen User versucht? Der hat ja ein anderes Profil.
Jürgen
Stimmt, hab ich doch glatt vergessen. Andere Profile haben auch keinen Zugriff, dafür aber das Userprofil vom störrischen Rechner auf einem anderen Client. Also liegts schon mal nicht am Profil, diese Erkenntnis hatte mich bereits getroffen, danke für die Erinnerung!
Ansonsten, Geld für eine Pro wäre da, ich könnte den Client auch plattmachen (darauf wird es wohl hinauslaufen) oder einen anderen hinstellen. Aber mich interessiert schon die Ursache des ganzen. Warum der eine Client unter Edu läuft, kann ich nicht sagen (weil ich's nicht weiß) - das konnte mir hier keiner sagen, wie der Client zu dieser Lizenz kommt
Danke für die Antworten!
Ansonsten, Geld für eine Pro wäre da, ich könnte den Client auch plattmachen (darauf wird es wohl hinauslaufen) oder einen anderen hinstellen. Aber mich interessiert schon die Ursache des ganzen. Warum der eine Client unter Edu läuft, kann ich nicht sagen (weil ich's nicht weiß) - das konnte mir hier keiner sagen, wie der Client zu dieser Lizenz kommt
Danke für die Antworten!
Hallo.
... schonmal die Firewall des störrischen Rechners testweise abgeschaltet, resp. die lokalen Regeln dafür gecheckt? 🤔
... schonmal die Firewall des störrischen Rechners testweise abgeschaltet, resp. die lokalen Regeln dafür gecheckt? 🤔
Das habe ich getan, auch die komplette Deaktivierung aller Profile mit Ausnahme des öffentlichen - der Rechner ist im Domänennetzwerk - brachte keine Änderung.
Moin,
Logs auf der Firewall, Eventlogs am Client und Server checken und mal am Client den Kabelhai anwerfen und schauen, was sich im Netzwerk tut, während versucht wird die Verbindung aufzubauen.
Gruß
Logs auf der Firewall, Eventlogs am Client und Server checken und mal am Client den Kabelhai anwerfen und schauen, was sich im Netzwerk tut, während versucht wird die Verbindung aufzubauen.
Gruß
Moin,
Du siehst also den SYN vom Client, den SYN, ACK vom Server und den ACK vom Client und danach passiert erst einmal nichts. Dann kommt der RST, ACK vom Client. Richtig?
Liebe Grüße
Erik
Zitat von @PyryWodka:
In Wireshark sieht man, dass die Verbindung aufgebaut wird. Wenn sie aber fertig ist, sendet der Client ein RST,ACK und setzt sie wieder zurück.
In Wireshark sieht man, dass die Verbindung aufgebaut wird. Wenn sie aber fertig ist, sendet der Client ein RST,ACK und setzt sie wieder zurück.
Du siehst also den SYN vom Client, den SYN, ACK vom Server und den ACK vom Client und danach passiert erst einmal nichts. Dann kommt der RST, ACK vom Client. Richtig?
Liebe Grüße
Erik
Hallo Erik, fast so ist es, allerdings kommt nach SYN, ACK und dem Client-ACK kommt Negotiate Protocol Response, Session Setup Request usw. siehe Screenshot. Das war auch der Grund für mich, mit den NTLMSSP-Leveln zu spielen.
Ich sehe gerade, dass ich den Sachverhalt wohl im Ausgangspunkt ein wenig .. naja, nicht aussagekräftig genug dargestellt habe. Sorry dafür und danke für alle Antworten.
Ich sehe gerade, dass ich den Sachverhalt wohl im Ausgangspunkt ein wenig .. naja, nicht aussagekräftig genug dargestellt habe. Sorry dafür und danke für alle Antworten.
Das ist jetzt die Sicht vom Client oder vom Server?
Vom Client, die 75 ist der Client, die 69 der Server.
Zitat von @PyryWodka:
Ich sehe gerade, dass ich den Sachverhalt wohl im Ausgangspunkt ein wenig .. naja, nicht aussagekräftig genug dargestellt habe. Sorry dafür und danke für alle Antworten.
Ich sehe gerade, dass ich den Sachverhalt wohl im Ausgangspunkt ein wenig .. naja, nicht aussagekräftig genug dargestellt habe. Sorry dafür und danke für alle Antworten.
Och, da sind wir schlimmeres gewohnt.
So wie das aussieht, bricht der Client die Verbindung ab, nachdem er die Bestätigung des Aufbaus der SMB-Sitzung bekommen hat. Die Frage ist, warum. Der nächste Anlaufpunkt ist jetzt das Ereignisprotokoll des Clients. Was läuft da schief, dass er den Verbindungsabbruch erzwingt (RST)? Findest Du irgendwas in der Ereignisanzeige?
1
Ja, ich habe tatsächlich was in der Ereignisanzeige gefunden. Danke, dass du mich nochmal mit der Nase drauf gestoßen hast, man muss halt manchmal auch abseits der "üblichen" Reiter gucken. Der Client hat eine "unsichere Gastanmeldung" erkannt und deswegen die Verbindung zurück gesetzt. Jetzt habe ich wenigstens was, womit ich arbeiten kann. Als Workaround könnte ich nun in den Computerrichtlinien/Administrative Vorlagen/Netzwerk/LanMan-Arbeitsstation die "unsicheren Gastanmeldungen" erlauben. Ein kurzer Test hat ergeben, dass das tatsächlich funktioniert.
Bleibt eigentlich nur noch zu prüfen, warum die Anmeldung plötzlich als unsichere Gastanmeldung eingestuft wird. Dank allen für die Hilfe, besonders Erik!
Grüße,
Pyry
Bleibt eigentlich nur noch zu prüfen, warum die Anmeldung plötzlich als unsichere Gastanmeldung eingestuft wird. Dank allen für die Hilfe, besonders Erik!
Grüße,
Pyry
Ja, ich habe tatsächlich was in der Ereignisanzeige gefunden.
Hm, Ereignisanzeige, sowohl beim Client als auch beim Server zu prüfen, ist eigentlich immer die erste Anlaufstelle.
Bzw. Log-Dateien.
Das hab ich auch getan, aber nicht ausführlich genug ganz offensichtlich. Also der Hinweis müsste modifiziert lauten: die komplette Ereignisanzeige prüfen
Das hab ich auch getan, aber nicht ausführlich genug ganz offensichtlich. Also der Hinweis müsste modifiziert lauten: die komplette Ereignisanzeige prüfen
Ich hätte die Ereignisanzeige gefiltert. Sprich aktuelles Protokoll filtern, indem die Haken
- Kritisch
- Warnung
- Ausführlich
- Fehler
Und das bei allen Windows Protokollen der Ereignisanzeige.
Kann passieren, im Eifer des Gefechts.
1
Moin,
Schonmal auf die Uhren geguckt. Ich wollte es schon sagen ... Sollten die Zeiten voneinander abweichen, dann ist das die nächste Baustelle.
Gerne.
Liebe Grüße
Erik
Zitat von @PyryWodka:
Bleibt eigentlich nur noch zu prüfen, warum die Anmeldung plötzlich als unsichere Gastanmeldung eingestuft wird.
Bleibt eigentlich nur noch zu prüfen, warum die Anmeldung plötzlich als unsichere Gastanmeldung eingestuft wird.
Schonmal auf die Uhren geguckt. Ich wollte es schon sagen ... Sollten die Zeiten voneinander abweichen, dann ist das die nächste Baustelle.
Dank allen für die Hilfe, besonders Erik!
Gerne.
Liebe Grüße
Erik
Vielleicht hilft das: Wir haben hier noch einen alten (virtuellen) Server 2012 - der sollte eigentlich schon abgeschaltet sein, aber da läuft noch so ein altes Programm für Sensoren für ein Gerät, welches ebenfalls demnächst ausgetauscht wird. Macht also keinen Sinn, neue Sensoren zu kaufen, oder da überhaupt noch etwas reinzuinvestieren.
Wenn der neu gestartet wird kann man den auch nicht mehr erreichen.
Hab den Fehler gefunden bzw. den Workaround: Der NLA-Dienst muss neu gestartet werden - danach geht es.
Obwohl alles normal aussieht - Domänen-Netzwerk wird erkannt, NLA läuft auch, keine verdächtigen Einträge in den LOGs ... kein Fehler zu sehen. Nach jedem Neustart muss per Hyper-V auf den Server gegangen und der NLA einmal manuell neu gestartet werden. Danach läuft alles einwandfrei. Vorher geht kein RDP, keine Netzlaufwerke ... nix - als wäre der Server gar nicht eingeschaltet.
Wenn der neu gestartet wird kann man den auch nicht mehr erreichen.
Hab den Fehler gefunden bzw. den Workaround: Der NLA-Dienst muss neu gestartet werden - danach geht es.
Obwohl alles normal aussieht - Domänen-Netzwerk wird erkannt, NLA läuft auch, keine verdächtigen Einträge in den LOGs ... kein Fehler zu sehen. Nach jedem Neustart muss per Hyper-V auf den Server gegangen und der NLA einmal manuell neu gestartet werden. Danach läuft alles einwandfrei. Vorher geht kein RDP, keine Netzlaufwerke ... nix - als wäre der Server gar nicht eingeschaltet.
