16
SMBv1 deaktivieren führte zur Katastrophe, keine Domänenanmeldung mehr
Servus;
Habe Mist gebaut.
Umgebung:
Server 2012R2 Domäne
2x DC
~10 Memberserver (2012R2 und 2008R2)
~100 Windows 8 Clients
~10 Windows 7 Clients
~20 Windows 10 1703 Clients
Alle am aktuellsten November Patch Stand
Server alle virtuell auf 3x ESXi 6.0
Da derzeit alles so halbwegs lief, dachte ich mir ich sollte endlich mal mehr in die "Sicherheit" investieren.
Habe mehrmals gelesen man sollte SMBv1 deaktivieren.
Ist ja seit Vista bzw Server 2008 eigentlich nicht mehr in Benützung.
So alte Maschinen hab ich nicht mehr.
Hab dann nach dieser Anleitung https://www.gruppenrichtlinien.de/artikel/smbv1-netzwerkweit-deaktiviere ...
eine GPO gebaut, und natürlich vorher auf einem Server und Client getestet.
Es waren keine Probleme ersichtlich. Habe auch kontrolliert ob die GPO gegriffen bzw das SMBv1 deaktiviert ist.
Habs dann auf die komplette Domäne ausgerollt.
Tja, großer Fehler.
Nach und nach fingen die Maschinen beim Anmelden zu meckern dass der Netzwerkanmeldedienst nicht verfügbar sei.
Und die die sich anmelden konnten, konnten nicht auf den Fileserver zugreifen.
Nach ein paar Minuten bin ich dann auch draufgekommen... SMBv1 ist Schuld.
Die Clients konnten nicht mehr auf die Shares zugreifen, darunter auch die der DCs.
Egal ob Windows 8 oder 10. Lustigerweise funktionierts derzeit bei den Windows 7 NOCH.
Hab mir dann gach eine bat erstellt mit:
Mit der geh ich von Client zu Client und führe sie als lokaler Admin aus.
Wie konnte das passieren, was hab ich übersehen?
Warum greifen die Clients nicht per SMBv2 oder 3 zu?
Hab nach etwas Google Recherche mehrere Leute gefunden mit dem gleichen Problem,
nur ist es bei denen schon beim Testen aufgefallen.
Bitte erspart euch jedwede Beleidigung, bin schon gestraft genug...
PS: Interessant ist vielleicht noch dass ab Windows 10 1709 SMBv1 nicht installiert ist.
Habe Mist gebaut.
Umgebung:
Server 2012R2 Domäne
2x DC
~10 Memberserver (2012R2 und 2008R2)
~100 Windows 8 Clients
~10 Windows 7 Clients
~20 Windows 10 1703 Clients
Alle am aktuellsten November Patch Stand
Server alle virtuell auf 3x ESXi 6.0
Da derzeit alles so halbwegs lief, dachte ich mir ich sollte endlich mal mehr in die "Sicherheit" investieren.
Habe mehrmals gelesen man sollte SMBv1 deaktivieren.
Ist ja seit Vista bzw Server 2008 eigentlich nicht mehr in Benützung.
So alte Maschinen hab ich nicht mehr.
Hab dann nach dieser Anleitung https://www.gruppenrichtlinien.de/artikel/smbv1-netzwerkweit-deaktiviere ...
eine GPO gebaut, und natürlich vorher auf einem Server und Client getestet.
Es waren keine Probleme ersichtlich. Habe auch kontrolliert ob die GPO gegriffen bzw das SMBv1 deaktiviert ist.
Habs dann auf die komplette Domäne ausgerollt.
Tja, großer Fehler.
Nach und nach fingen die Maschinen beim Anmelden zu meckern dass der Netzwerkanmeldedienst nicht verfügbar sei.
Und die die sich anmelden konnten, konnten nicht auf den Fileserver zugreifen.
Nach ein paar Minuten bin ich dann auch draufgekommen... SMBv1 ist Schuld.
Die Clients konnten nicht mehr auf die Shares zugreifen, darunter auch die der DCs.
Egal ob Windows 8 oder 10. Lustigerweise funktionierts derzeit bei den Windows 7 NOCH.
Hab mir dann gach eine bat erstellt mit:
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb10 start= autoWie konnte das passieren, was hab ich übersehen?
Warum greifen die Clients nicht per SMBv2 oder 3 zu?
Hab nach etwas Google Recherche mehrere Leute gefunden mit dem gleichen Problem,
nur ist es bei denen schon beim Testen aufgefallen.
Bitte erspart euch jedwede Beleidigung, bin schon gestraft genug...
PS: Interessant ist vielleicht noch dass ab Windows 10 1709 SMBv1 nicht installiert ist.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 357920
Url: https://administrator.de/contentid/357920
Printed on: April 20, 2024 at 03:04 o'clock
16 Comments
Latest comment
Hi,
Tja, großer Fehler.
Nach und nach fingen die Maschinen beim Anmelden zu meckern dass der Netzwerkanmeldedienst nicht verfügbar sei.
Und die die sich anmelden konnten, konnten nicht auf den Fileserver zugreifen.
Nach ein paar Minuten bin ich dann auch draufgekommen... SMBv1 ist Schuld.
Die Clients konnten nicht mehr auf die Shares zugreifen, darunter auch die der DCs.
Egal ob Windows 8 oder 10. Lustigerweise funktionierts derzeit bei den Windows 7 NOCH.
Also scheint SMBv2 zu laufen, v3 aber nicht, worüber 8 und 10 kommunizieren wollen.
Das Microsoft-Tutorial eignet sich hierfür eigentlich hervorragend https://support.microsoft.com/de-de/help/2696547/how-to-detect-enable-an ...
Habe Mist gebaut.
Umgebung:
Server 2012R2 Domäne
2x DC
~10 Memberserver (2012R2 und 2008R2)
~100 Windows 8 Clients
~10 Windows 7 Clients
~20 Windows 10 1703 Clients
Alle am aktuellsten November Patch Stand
Soweit so gutUmgebung:
Server 2012R2 Domäne
2x DC
~10 Memberserver (2012R2 und 2008R2)
~100 Windows 8 Clients
~10 Windows 7 Clients
~20 Windows 10 1703 Clients
Alle am aktuellsten November Patch Stand
Server alle virtuell auf 3x ESXi 6.0
OkDa derzeit alles so halbwegs lief, dachte ich mir ich sollte endlich mal mehr in die "Sicherheit" investieren.
Halbwegs reicht nicht ;)Habe mehrmals gelesen man sollte SMBv1 deaktivieren.
Sollte man, ja.Ist ja seit Vista bzw Server 2008 eigentlich nicht mehr in Benützung.
Das ist falsch, wie du am eigenen Leib erfahren hast.So alte Maschinen hab ich nicht mehr.
Irrelevant. Du hast mindestens ein paar Durcker oder Kopiergeräte, die ScanToSMB machen. Und rate mal welche SMB-Version die benutzen Hab dann nach dieser Anleitung https://www.gruppenrichtlinien.de/artikel/smbv1-netzwerkweit-deaktiviere ...
Auf der Seite ist leider nichtmal zu 50% erklärt, was man alles beachten musseine GPO gebaut, und natürlich vorher auf einem Server und Client getestet.
Es waren keine Probleme ersichtlich. Habe auch kontrolliert ob die GPO gegriffen bzw das SMBv1 deaktiviert ist.
Inkl. Prüfung, ob SMBv2 und v3 korrekt funktionstüchtig sind, um SMBv1 auch ablösen zu können?Es waren keine Probleme ersichtlich. Habe auch kontrolliert ob die GPO gegriffen bzw das SMBv1 deaktiviert ist.
Habs dann auf die komplette Domäne ausgerollt.
Zwischenschritte wären gut gewesen :/Tja, großer Fehler.
Nach und nach fingen die Maschinen beim Anmelden zu meckern dass der Netzwerkanmeldedienst nicht verfügbar sei.
Und die die sich anmelden konnten, konnten nicht auf den Fileserver zugreifen.
Nach ein paar Minuten bin ich dann auch draufgekommen... SMBv1 ist Schuld.
Die Clients konnten nicht mehr auf die Shares zugreifen, darunter auch die der DCs.
Egal ob Windows 8 oder 10. Lustigerweise funktionierts derzeit bei den Windows 7 NOCH.
Hab mir dann gach eine bat erstellt mit:
Mit der geh ich von Client zu Client und führe sie als lokaler Admin aus.
Computerstartskript per GPO verteilen.sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
> sc.exe config mrxsmb10 start= autoWie konnte das passieren, was hab ich übersehen?
Wie oben erwähnt, Vorabcheck, ob v2 und v3 richtig laufen.Bitte erspart euch jedwede Beleidigung, bin schon gestraft genug...
Hab mich bemüht PS: Interessant ist vielleicht noch dass ab Windows 10 1709 SMBv1 nicht installiert ist.
Nicht ganz richtig, die ersten 15 oder 30 Tage ist es aktiv und deaktiviert sich dann.Das Microsoft-Tutorial eignet sich hierfür eigentlich hervorragend https://support.microsoft.com/de-de/help/2696547/how-to-detect-enable-an ...
1
Hi.
Dein Problem: die Anbhängigkeit des Anmeldedienstes scheint bestehen geblieben zu sein. Das musst Du überprüfen, denn wenn der Anmeldedienst nicht läuft, ist eine Domänenanmeldung nicht möglich. Also zurück hzur Testumgebung.
@chgorges
Dein Problem: die Anbhängigkeit des Anmeldedienstes scheint bestehen geblieben zu sein. Das musst Du überprüfen, denn wenn der Anmeldedienst nicht läuft, ist eine Domänenanmeldung nicht möglich. Also zurück hzur Testumgebung.
@chgorges
Computerstartskript per GPO verteilen.
Nicht möglich, da der Anmeldedienst nicht läuft.1
Ich hab eben wirklich keine Geräte mehr die SMBv1 benutzen.
Ich hab zumindest getestet ob SMB allgemein noch funktioniert.
Zugriff auf verschiedenste Shares, und auch Domänenanmeldung, alle "Testgeräte" (alle virtuell) wurden auch mehrmals neugestartet.
Ja, Zwischenschritte wären wirklich ratsam gewesen^^
Da is nix mit GPO, ohne Zugriff auf die DCs
Das mit 1709 ist interessant.
Dieses Microsoft Tutorial hab ich mehrmals durch, in englisch wie auch in deutsch.
Von da hab ich auch meine bat abgeleitet.
Danke mal
Ich hab zumindest getestet ob SMB allgemein noch funktioniert.
Zugriff auf verschiedenste Shares, und auch Domänenanmeldung, alle "Testgeräte" (alle virtuell) wurden auch mehrmals neugestartet.
Ja, Zwischenschritte wären wirklich ratsam gewesen^^
Da is nix mit GPO, ohne Zugriff auf die DCs
Das mit 1709 ist interessant.
Dieses Microsoft Tutorial hab ich mehrmals durch, in englisch wie auch in deutsch.
Von da hab ich auch meine bat abgeleitet.
Danke mal
Ja das ist es ja, in der Testumgebung läuft alles.
SMBv1 ist dort definitv deaktiviert, und die Clients können sich anmelden.
Irgendwas bewegt anscheinend meine Produktiv DCs (bzw auch zumindest den Fileserver) dazu SMBv1 zu verwenden.
Jetzt ist nur mehr die Frage, was
Derweil lauf ich von einem PC zum anderen und führe das Skript aus.
Bisl Sport schadet eh nicht ^^
Leider hatte ich noch immer keine Zeit mich mit Wireshark genauer zu beschäftigen, denn da könnt ich ja schaun wer SMBv1 benutzt.
SMBv1 ist dort definitv deaktiviert, und die Clients können sich anmelden.
Irgendwas bewegt anscheinend meine Produktiv DCs (bzw auch zumindest den Fileserver) dazu SMBv1 zu verwenden.
Jetzt ist nur mehr die Frage, was
Derweil lauf ich von einem PC zum anderen und führe das Skript aus.
Bisl Sport schadet eh nicht ^^
Leider hatte ich noch immer keine Zeit mich mit Wireshark genauer zu beschäftigen, denn da könnt ich ja schaun wer SMBv1 benutzt.
Irgendwas bewegt anscheinend meine Produktiv DCs (bzw auch zumindest den Fileserver) dazu SMBv1 zu verwenden.
Wie kommst Du nur darauf... das hat einzig und allein mit dem Anmeldedienst zu tun.
Na weil ich ja sonst auf die zugreifen könnte?
Ich musste auch beim Fileserver bzw bei beiden DCs SMBv1 wieder aktivieren und dann natürlich neustarten.
Dass die Shares wieder funktionierten.
Deswegen dachte ich mir dass die DCs für zb SYSVOL und NETLOGON SMBv1 benutzen.
Ich musste auch beim Fileserver bzw bei beiden DCs SMBv1 wieder aktivieren und dann natürlich neustarten.
Dass die Shares wieder funktionierten.
Deswegen dachte ich mir dass die DCs für zb SYSVOL und NETLOGON SMBv1 benutzen.
Das Anmelden hat nichts und gar nichts mit SMB zu tun. Der Zugriff auf Sysvol (GPOs), ja, dafür brauchst Du SMB.
Dein Link Gruppenrichtlinien.de spricht doch eine Warnung aus bezüglich des Anmeldedienstes. Das musst Du prüfen. Wenn der jetzt nicht läuft, dann weißt Du, woran es liegt. Mit Sicherheit nicht an SMBv1.
Dein Link Gruppenrichtlinien.de spricht doch eine Warnung aus bezüglich des Anmeldedienstes. Das musst Du prüfen. Wenn der jetzt nicht läuft, dann weißt Du, woran es liegt. Mit Sicherheit nicht an SMBv1.
1
Naja, ich führe
aus und dann gehts wieder alles.
Ich hab wie bei Gruppenrichtlinien.de beschrieben extra eben auf den Anmeldedienst geachtet.
Aber das werde ich mir nochmal bei den betroffenen Geräten näher anschauen.
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb10 start= autoaus und dann gehts wieder alles.
Ich hab wie bei Gruppenrichtlinien.de beschrieben extra eben auf den Anmeldedienst geachtet.
Aber das werde ich mir nochmal bei den betroffenen Geräten näher anschauen.
http://winxperts4all.at/index.php/betriebssysteme/windows-10/1323-unc-h ...
Evtl. trifft das bei dir noch zu.
Evtl. trifft das bei dir noch zu.
Auch das hat rein gar nichts mit der Anmeldung zu tun.
Ok, habs schon verstanden.
Wieso funktioniert die Anmeldung nach diesen Befehlen dann?
Wieso funktioniert die Anmeldung nach diesen Befehlen dann?
Glaub nicht, da es bei 7, 8 und 10 vorkommt.
Sag mal, was ist denn nun so schwer daran, zu prüfen, ob bei einem der Rechner der Anmeldedienst läuft oder nicht?
Dein Befehl stellt die Abhängigkeiten der Dienste wieder her und deshalb startet er wieder.
Dein Befehl stellt die Abhängigkeiten der Dienste wieder her und deshalb startet er wieder.
Weil ich erst morgen wieder dort bin.
Da werde ich das gleich prüfen.
Da werde ich das gleich prüfen.
Also der Anmeldedienst ist wie zu erwarten NICHT gestartet.
Allerdings steht er auf "Automatisch".
Wurscht, ich werde das im Frühjahr nochmal genauer durchtesten, und gegebenenfalls hier berichten.
Hab keine Zeit mehr für den Schaß.
Allerdings steht er auf "Automatisch".
Wurscht, ich werde das im Frühjahr nochmal genauer durchtesten, und gegebenenfalls hier berichten.
Hab keine Zeit mehr für den Schaß.
"Allerdings steht er auf "Automatisch" - es_geht_um_die_Abhängigkeiten.
Wenn der Dienst von SMBv1 abhängig ist und Du smbv1 tötest, ja, dann startet er nicht, auch wenn er auf automatisch steht.
Wenn der Dienst von SMBv1 abhängig ist und Du smbv1 tötest, ja, dann startet er nicht, auch wenn er auf automatisch steht.
1
