systemwatcher
Goto Top

Nach Windowsupdate kein Zugriff auf Netzwerkfreigabe mehr möglich

Gegrüsst,

nach dem heutigen Update gelingt der Zugriff auf ein Windows 7 Rechner über die Freigabe nicht mehr.
Bis vor diesem Update hat es tadellos funktioniert. Die Einstellungen sind korrekt und alle notwendigen Dienste vorhanden.
Hat jemand ähnliche Erfahrungen mit dem Update heute?

Gruß

Content-ID: 397581

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

Ausgedruckt am: 15.12.2024 um 23:12 Uhr

sabines
sabines 09.01.2019 um 07:57:30 Uhr
Goto Top
Moin,

kannst Du mal genauer schreiben, wer auf was zugreiffen will und welche Updates du meinst?
Ggfs. mal die SMB Protokolle prüfen, wenn W10/W2012/W2016 beteiligt sein sollte.

Gruss
itisnapanto
itisnapanto 09.01.2019 um 08:03:27 Uhr
Goto Top
Moin ,

jap die SMB Protokolle.
Hatte ich letztens auch noch und mir nen Wolf gesucht .

Gruss
Spirit-of-Eli
Spirit-of-Eli 09.01.2019 um 08:06:40 Uhr
Goto Top
Genauer sollte der W7 Rechner kein SMB1 mehr nutzen da das durch die letzten updates auf neueren Systemen deaktiviert wurde.
systemwatcher
systemwatcher 09.01.2019 um 08:09:37 Uhr
Goto Top
Zugriff von Windows 7 PCs auf Windows 7 PC mit Freigabe (der das Update hatte).
Heute / Gestern wurden Updates eingespielt, (leider stehen Updates auf Automatisch).
Standard Windows Freigabe. Windows > 7 nicht beteiligt.
SlainteMhath
SlainteMhath 09.01.2019 um 08:13:49 Uhr
Goto Top
Moin,

lass dir doch bitte nicht alles aus der Nase ziehen...
Domäne? Arbeitsgruppe? Eventlog? Fehlermeldung? Welche Updates wurden installiert?

lg,
Slainte
Spirit-of-Eli
Spirit-of-Eli 09.01.2019 aktualisiert um 08:30:29 Uhr
Goto Top
Zitat von @systemwatcher:

Zugriff von Windows 7 PCs auf Windows 7 PC mit Freigabe (der das Update hatte).
Heute / Gestern wurden Updates eingespielt, (leider stehen Updates auf Automatisch).
Standard Windows Freigabe. Windows > 7 nicht beteiligt.

Welche SMB Version wird denn nun verwendet?

Kannst dir einfach in der Shell die Freigaben anzeigen lassen. Dann siehst du es.

//in einer PS: get-smbconnection
systemwatcher
systemwatcher 09.01.2019 um 08:33:50 Uhr
Goto Top
Keine Domäne
Fehlermeldung 0x80004005 (unbekannter Fehler) beim Versuch zu verbinden

Bei den Standard Logs sehe ich nichts auffälliges, ggf. weißt Du wo ich genau nachsehen sollte.

Folgende Updates zuletzt
KB4481480 09.01. (Sicherheitsqualitätsrollup für .NET Framework)
KB4480970 09.01. (Monatliches Sicherheitsqualitätsrollup für x64 basierte Systeme)
KB915597 (Windows Defender Definitionen) 08.01

Wie gesagt, sonst keine Änderungen, keine Installationen oder sonstiges, bis dahin keine Probleme.
systemwatcher
systemwatcher 09.01.2019 um 08:47:06 Uhr
Goto Top
net share? zeigt nichts an, PS Befehl führt zur Feldermeldung kein cmdlet, Funktion oder Skript erkannt
sabines
sabines 09.01.2019 aktualisiert um 08:54:06 Uhr
Goto Top
Zitat von @Spirit-of-Eli:
//in einer PS: get-smbconnection

Gibt es in der W7 PS nicht face-wink
Die ist Version 2, wenn sie nicht aktiv aktualisiert wird.
sabines
sabines 09.01.2019 aktualisiert um 08:53:24 Uhr
Goto Top
Aktualisiere mal Deine PS oder schau in den Diensten nach, und lass' Dir nicht alles aus der Nase ziehen.
Das ist nun wirklich kein Hexenwerk nach den SMB Versionen zu schauen/google zu nutzen oder die Suche hier im Forum.
Ggfs. deinstalliere das Update und prüfe dann die Verbindung.

Ist überhaupt ein Ping auf den PC möglich, oder scheiter es schon daran?
Spirit-of-Eli
Spirit-of-Eli 09.01.2019 um 09:01:26 Uhr
Goto Top
Zitat von @sabines:

Zitat von @Spirit-of-Eli:
//in einer PS: get-smbconnection

Gibt es in der W7 PS nicht face-wink
Die ist Version 2, wenn sie nicht aktiv aktualisiert wird.

Oh, ich habe leider keine W7 Systeme mehr da ;).
Dazu gibt es aber ein cmd pedant, welches ich auch wieder ergooglen müsste..
systemwatcher
systemwatcher 09.01.2019 um 09:40:31 Uhr
Goto Top
Servus,

erst einmal Danke für die Bemühungen.
Aus der Nase ziehen lasse ich mir nicht, ich tappe nur selbst im Dunkeln (bin auch nicht direkt an diesem PC, leiste gerade selbst Ferndiagnose).
Das SMB Protokoll wird SMB 1 sein, da bis vor einiger/kurzer Zeit auch XP PC darauf zugegriffen haben und es nie umgestellt wurde.
Ich wüsste auch nicht, dass ein Update das abgeschaltet hat, zumindest bei Windows 7, kann ja nun passiert sein, aber dann sollte doch trotzdem ein Zugriff von Windows 7 PC möglich sein.
Die Aktualisierung ist im Gange wo kann das in den Diensten nachgesehen werden. Soweit ich es gesehen habe ist das unter Windows 7 nicht so direkt möglich. Bei Windows 10 kann das ja in den Features eingestellt werden. Für gewöhnlich wird ja immer das höchstmögliche Protokoll genutzt und nur bei Bedarf runtergestuft (wenn möglich).

Ein Ping funktioniert. Die Verbindung steht also.
Spirit-of-Eli
Spirit-of-Eli 09.01.2019 um 09:47:15 Uhr
Goto Top
Und hier nochmals Google bemüht.

https://support.microsoft.com/de-de/help/2696547/how-to-detect-enable-an ...

Sorry, aber das war nun wirklich nicht schwer auf den Link zu kommen.
afuafu
afuafu 09.01.2019 um 09:53:01 Uhr
Goto Top
Hallo,

wir suchen aktuell auch bei unseren Kunden.
Fall1:

Windows 7 Clients mit Server 2008R2 Workgroup.
Kein Zugriff auf die Netzwerkfreigabe am Server.
ODBC connect funktioniert tadellos

Lösung: Erstmal Updates am Server deinstallieren - ich weiß nicht korrekt aber erstmal schafft das Abhilfe.

Den zweiten Fall schaue ich mir gleich an. Ist auf jeden Fall eine Domäne mit teilweise Windows 10 Clients.
Melde mich gleich wieder.
systemwatcher
systemwatcher 09.01.2019 aktualisiert um 10:14:16 Uhr
Goto Top
Sorry, aber das habe ich auch schon gefunden.
Es wurde an dem PC nichts aktiv deaktiviert oder aktiviert.
D.h. Windows 7 PC mit SMB 2.1 und 1.0.
Lediglich bei den Erweiterten Netzwerkeinstellungen wurde die Verschlüsselung auf 56 Bit statt 128 Bit gesetzt.
Aber selbst ein Zurücksetzen auf 128 Bit Verschlüsselung ändert nichts an dem Zustand.
Nochmals Zugriff von einem Windows 7 PC auf einen Windows 7 PC.

NACHTRAG:
Selbst mit neuer Powershell 5.1 kein get-smbconnection...

NACHTRAG2:
Definitiv beide Protokolle aktiv, wenn man der Registry Methode folgt, aber wie gesagt, es wurde nichts deaktiviert.
Spirit-of-Eli
Spirit-of-Eli 09.01.2019 um 10:16:41 Uhr
Goto Top
Zitat von @systemwatcher:

Sorry, aber das habe ich auch schon gefunden.
Es wurde an dem PC nichts aktiv deaktiviert oder aktiviert.
D.h. Windows 7 PC mit SMB 2.1 und 1.0.
Lediglich bei den Erweiterten Netzwerkeinstellungen wurde die Verschlüsselung auf 56 Bit statt 128 Bit gesetzt.
Aber selbst ein Zurücksetzen auf 128 Bit Verschlüsselung ändert nichts an dem Zustand.
Nochmals Zugriff von einem Windows 7 PC auf einen Windows 7 PC.

NACHTRAG:
Selbst mit neuer Powershell 5.1 kein get-smbconnection...

Wird denn nun SMB1 genutzt oder nicht?
Darum geht es doch die ganze Zeit. Im Artikel steht beschrieben wie man dies am Client in Erfahrung bringt.

Die PS Variante wird auch beschrieben.
systemwatcher
systemwatcher 09.01.2019 um 10:29:54 Uhr
Goto Top
Aktuell will der PC das Update KB4480970 erneut installieren, obwohl es bereits installiert ist.
Vermutlich hat MS mal wieder ein Bock geschossen.
systemwatcher
systemwatcher 09.01.2019 um 10:31:38 Uhr
Goto Top
Wird denn nun SMB1 genutzt oder nicht?
Darum geht es doch die ganze Zeit. Im Artikel steht beschrieben wie man dies am Client in Erfahrung bringt.

Die PS Variante wird auch beschrieben.

Es zeigt nur an, was aktiviert ist und was nicht. Es wurde aber keines der Protokolle deaktiviert.
So wie es der Befehl Get-SMBConnection anzeigen würde, das gibt es nicht auf Windows 7.
Es sind aber beide SMB Protokolle aktiviert. Welches aktiv genutzt wird (oder würde, wenn es geht) kann ich nicht prüfen!
sabines
sabines 09.01.2019 um 10:37:53 Uhr
Goto Top
Moin,

als erstes deaktivierst du mal auf beiden W7 Clients SMB V1 und prüfst zur Sicherheit nochmal ob auf beiden(!) SMB V2 aktiviert ist.

Dann sehen wir weiter.

PS: Durchgepatcher W7 Client kann ohne Probleme auf W7 oder W2008 (beide noch Updatestand 12/2018) Freigaben zugreifen.

Gruss
sabines
sabines 09.01.2019 um 10:39:52 Uhr
Goto Top
Zitat von @systemwatcher:

NACHTRAG2:
Definitiv beide Protokolle aktiv, wenn man der Registry Methode folgt, aber wie gesagt, es wurde nichts deaktiviert.

Vielleicht nutzt W7 wenn SMB v1 und v2 aktiv sind, per default v1 und vielleicht hat ein Update nun dafür gesorgt, dass v1 geblockt wird. Da nutzt es nichts, dass Du aktiv nichts geändert hast.
quotum
quotum 09.01.2019 um 11:03:44 Uhr
Goto Top
Hat jemand schon eine Lösung gefunden? Ich habe testweise auf einem Win10 PC SMB1 wieder aktiviert, kann aber trotzdem den Win7 Share nicht benutzen. Der Win7 PC kann auch trotzdem den Win7 Share nicht nutzen....
137846
Lösung 137846 09.01.2019, aktualisiert am 11.01.2019 um 00:15:31 Uhr
Goto Top
Zitat von @sabines:
PS: Durchgepatcher W7 Client kann ohne Probleme auf W7 oder W2008 (beide noch Updatestand 12/2018) Freigaben zugreifen.
Das Problem ist wenn die Freigabe auf einem Windows 7 mit Update 01/2019 (KB4480970 oder KB4480960) liegt, kann das hier definitiv nachvollziehen, nach Update 01/2019 kommt keine SMB2 Verbindung auf eine W7 Share mehr zustande, hier der Wireshark Trace vom Client der auf den W7 Share zugreifen möchte:

screenshot

Führt immer zur Fehlermeldung Invalid Handle!

Werde mal einige Tests durchführen ...

Nach dem Deinstallieren von (KB4480970 oder KB4480960) funktioniert alles wieder einwandfrei! Es liegt also definitiv an KB4480970/KB4480960.

Windows 7 SP1 and Windows Server 2008 R2 SP1

KB4480970 Monthly Rollup

    Protection against Speculative Story Bypass CVE-2018-3639 for AMD-based computers
    Security updates to Windows Kernel, Windows Storage and Filesystems, Windows Wireless Networking, and the Microsoft JET Database Engine.

-edit-

Wenn der User der auf das W7 zugreift zufällig ein Administrator auf dem Remote-System ist sollte das hier auf dem W7 welches das Share hostet Abhilfe schaffen (elevated cmd):
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Danach zwingend ein Reboot durchführen!

Es tritt also nur auf wenn der User Administrator auf dem System ist welches das Share hostet, solange er normaler User ist alles OK, also hat MS hier das was für die Administrative Shares gilt, nun auf andere Shares ausgeweitet.

Hier die komplette Lösung: Zugriff auf Shares die auf Windows 7 gehostet werden nach Update 01-2019 (KB4480970 oder KB4480960) nicht mehr möglich
1Werner1
1Werner1 09.01.2019, aktualisiert am 11.01.2019 um 00:14:47 Uhr
Goto Top
Moin,

erst mal wünsche ich dir ein frohes neues Jahr !

Vielleicht hilft dir mein Beitrag weiter, djoin funktioniert auch bei Windows 7 PC.

Windows 10 Version 1803 (17134) Bug ? lässt sich evtl. nicht mehr an die Domäne anmelden


Sorry hatte die Lösung nicht gesehen. ( Rollup KB4480970)


Schöne Grüsse aus dem schönen Emsland.

Werner
certifiedit.net
certifiedit.net 09.01.2019 um 11:21:49 Uhr
Goto Top
AMD-based computers

AMD wie AMD CPUs oder AMD wie AMD64 == alle x64 betriebene Systeme?
quotum
quotum 09.01.2019 um 11:32:54 Uhr
Goto Top
Ich habe das Update KB4480970 auf dem betreffendem System deinstalliert, was erstmal Abhilfe geschaffen hat. Ich hoffe da kommt noch eine permanente Lösung.
Was Microsoft sich da manchmal leistet geht mir mehr und mehr auf den Sack.
137846
137846 09.01.2019 aktualisiert um 11:37:04 Uhr
Goto Top
Zitat von @quotum:

Ich habe das Update KB4480970 auf dem betreffendem System deinstalliert, was erstmal Abhilfe geschaffen hat. Ich hoffe da kommt noch eine permanente Lösung.
Was Microsoft sich da manchmal leistet geht mir mehr und mehr auf den Sack.

Ist dein User der auf das W7 zugreift zufällig Administrator auf dem Remote-System ?

Dann sollte das hier auf dem W7 welches das Share hostet Abhilfe schaffen:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Danach zwingend ein Reboot durchführen.
certifiedit.net
certifiedit.net 09.01.2019 um 11:35:58 Uhr
Goto Top
Zitat von @quotum:

Ich habe das Update KB4480970 auf dem betreffendem System deinstalliert, was erstmal Abhilfe geschaffen hat. Ich hoffe da kommt noch eine permanente Lösung.
Was Microsoft sich da manchmal leistet geht mir mehr und mehr auf den Sack.

Updates auf Auto-Installation gelassen? Naja...ist auch nicht das Wahre.
sabines
sabines 09.01.2019 um 11:39:54 Uhr
Goto Top
Zitat von @certifiedit.net:
Updates auf Auto-Installation gelassen? Naja...ist auch nicht das Wahre.

Wieso das denn?
Wie soll ich denn sonst wissen, was ich mir erspart habe, wenn andere nicht für mich testen face-wink
quotum
quotum 09.01.2019 um 11:42:02 Uhr
Goto Top
Nein, natürlich umgestellt.
sabines
sabines 09.01.2019 um 11:42:14 Uhr
Goto Top
Sehr gute Arbeit. Danke.
Ich kann von einem ungepatchen Client auf die Freigabe eines gepatchen Clients zugreifen.
Kann das jemand nachvollziehen?
137846
137846 09.01.2019 aktualisiert um 11:50:24 Uhr
Goto Top
Zitat von @sabines:

Sehr gute Arbeit. Danke.
Ich kann von einem ungepatchen Client auf die Freigabe eines gepatchen Clients zugreifen.
Kann das jemand nachvollziehen?
S. Ergänzung zum Thema in meinem Kommentar oben.

MS hat offensichtlich das was bisher nur für die Administrative-Shares gegolten nun auf alle anderen Shares ausgeweitet. Ist der User Admin auf System was das Share hostet tritt das Verhalten auf, wenn er normaler User ist nicht.
Das OS und Patchstand des Clients spielt dabei keine Rolle, der Host der das Share hostet ist es.
davidshoes
davidshoes 09.01.2019 um 11:54:36 Uhr
Goto Top
Hallo Zusammen, habe selbiges Problem.

LAN mit Win 7 pro und Win 10 PC's mit normaler Netzwerkfreigabe.
Nach Deinstallation des Updates läuft es wieder. Habe diese geblockt.

Kann man das SMB1 deaktivieren und die Netzlaufe neu verbinden, damit es läuft oder geht das nicht so einfach?
Win 10 kann ich aufgrund vorn einigen Programmen leider nicht überall installieren.

Besten Dank

Gruß
quotum
quotum 09.01.2019 aktualisiert um 11:58:30 Uhr
Goto Top
Das Problem hat ja nichts spezifisch mit SMB1 shares zu tun, sondern tritt bei SMB2 ebenso auf.
Das gleiche wird dann ja auch auf 2008 R2 Servern sein... Gut das die noch nicht geupdated wurden..
137846
Lösung 137846 09.01.2019 aktualisiert um 11:59:38 Uhr
Goto Top
Habe hier alles dazu in einem Tipp zusammengefasst:
Zugriff auf Shares die auf Windows 7 gehostet werden nach Update 01-2019 (KB4480970 oder KB4480960) nicht mehr möglich

Es ist also im weiteren Sinne kein Problem sondern nur eine reine Sicherheitsausweitung die sich aber mit Registry-Eintrag aufheben lässt!
Norasia
Norasia 06.02.2019 um 11:02:56 Uhr
Goto Top
Hallo Systemwatcher, ja nun hat es mich auch erwischt. Nach diversen Updates, ist es nicht mehr möglich unsere zwei Win 2008 und Win 2012 zuzugreifen. Auch 6x Win7 Pro Rechner sind davon betroffen. Den Netzwerkzugriff auf die Freigaben auf dem Win 2008 Server konnte ich nun wieder bewerkstelligen, in dem ich alle neu eingespielten Updates wieder deinstalliert habe. Eigentlich fummle ich nicht so gern an laufende Server herum. Ich werde einmal auf einem Server-Klon überprüfen welches Update da faul war. Erst vermutete ich das es ein Viren / Firewall Tool sein könnte. Doch es waren definitive die Updates von Microsoft.
Gruss Norasia
138721
138721 06.02.2019 aktualisiert um 11:08:21 Uhr
Goto Top
@Norasia
Ließ doch bitte hier, dann braucht man nicht blind alle Updates deinstallieren!
Zugriff auf Shares die auf Windows 7 gehostet werden nach Update 01-2019 (KB4480970 oder KB4480960) nicht mehr möglich

Btw. steht oben bereits x mal verlinkt, wenn man die Kommentare zumindest mal lesen würde.