11
Win10: UNC Hardening und Sicherheit
Mahlzeit,
bin hier immer noch am vorbereiten von W10 Clients für die Domain - heute mal ein neuen Problem:
Manchmal(!?) werden keine GPOs gezogen, da Zugriff auf \\domain.local\sysvol nicht erlaubt ist
Dann stolperte ich über diesen Artikel:
https://blogs.technet.microsoft.com/leesteve/2017/08/09/demystifying-the ...
Und sowohl die Reg als auch der GPO Ansatz funktionieren - schonmal schön.
Die Frage: Da ich das Artikel nur überflog, und die Lösung Quick & Dirty reingehackt habe um weiterzumachen - hat die Einstellung von:
"RequireMutualAuthentication=0, RequireIntegrity=0, RequirePrivacy=0" für \\domain.local\sysvol und \\domain.local\netlogon irgendwelche schwerwiegenden Security Nachteile?
bin hier immer noch am vorbereiten von W10 Clients für die Domain - heute mal ein neuen Problem:
Manchmal(!?) werden keine GPOs gezogen, da Zugriff auf \\domain.local\sysvol nicht erlaubt ist
Dann stolperte ich über diesen Artikel:
https://blogs.technet.microsoft.com/leesteve/2017/08/09/demystifying-the ...
Und sowohl die Reg als auch der GPO Ansatz funktionieren - schonmal schön.
Die Frage: Da ich das Artikel nur überflog, und die Lösung Quick & Dirty reingehackt habe um weiterzumachen - hat die Einstellung von:
"RequireMutualAuthentication=0, RequireIntegrity=0, RequirePrivacy=0" für \\domain.local\sysvol und \\domain.local\netlogon irgendwelche schwerwiegenden Security Nachteile?
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: 375758
Url: https://administrator.de/forum/win10-unc-hardening-und-sicherheit-375758.html
Ausgedruckt am: 21.12.2024 um 11:12 Uhr
11 Kommentare
Neuester Kommentar
Hi.
Was diese Einstellung nun mit deinem Problem zu tun haben soll, ist nicht erkennbar. Ja, sie hat schwerwiegende Nachteile und sollte auf gar keinen Fall verwendet werden, wenn dir die Sicherheit lieb und wert ist.
Was diese Einstellung nun mit deinem Problem zu tun haben soll, ist nicht erkennbar. Ja, sie hat schwerwiegende Nachteile und sollte auf gar keinen Fall verwendet werden, wenn dir die Sicherheit lieb und wert ist.
Zugriff auf \\domain.local\sysvol nicht erlaubt ist
Beschreibe mal genauer, wie sich das feststellen lässt und was da steht.
Bei W10 Kisten ist es so das die Group Policies nicht gezogen werden, mit folgendem fehler:
Die DFS / Replication funktioniert, auf den DCs keine Fehler, auch alle Win7 Clients haben nie diesen Fehler
Problem ist das der W10 Client auf \\domain.local\sysvol\ nicht zugreifen kann, sehr wohl aber auf \\DC1\sysvol, \\DC2\sysvol etc.
Wenn man auf
\\domain.local\sysvol\
drauf will, kommt zugriff nicht erlaubt - auch mit einem anderen user der adminprivilegien hat, gehts nicht.
Wenn man den Client aus der Domäne entfern und neu hinzufügt, geht es bei der ersten anmeldung, ab der zweiten Anmeldung klemmts wieder.
Auch ist es so, wenn man ~ 15 minuten nach der Anmeldung wartet, hat man zugriff (?!) auf Filebene und auch Gpupdate funktioniert wieder
Die DCs sind Win Server 2012 R2
gpupdate
Die Richtlinie wird aktualisiert...
Die Computerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Probleme sind aufgetreten:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\domain.local\sysvol\domain.local\Policies\{GUID}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.
Die Benutzerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Probleme sind aufgetreten:Die DFS / Replication funktioniert, auf den DCs keine Fehler, auch alle Win7 Clients haben nie diesen Fehler
Problem ist das der W10 Client auf \\domain.local\sysvol\ nicht zugreifen kann, sehr wohl aber auf \\DC1\sysvol, \\DC2\sysvol etc.
Wenn man auf
\\domain.local\sysvol\
drauf will, kommt zugriff nicht erlaubt - auch mit einem anderen user der adminprivilegien hat, gehts nicht.
Wenn man den Client aus der Domäne entfern und neu hinzufügt, geht es bei der ersten anmeldung, ab der zweiten Anmeldung klemmts wieder.
Auch ist es so, wenn man ~ 15 minuten nach der Anmeldung wartet, hat man zugriff (?!) auf Filebene und auch Gpupdate funktioniert wieder
Die DCs sind Win Server 2012 R2
Wie war denn diese Einstellung, bevor Du sie geändert hast?
RequirePrivacy=0 sollte man nur setzen, wenn alle Beteiligten SMBv3 sprechen können, was für Win7 ja nicht zutrifft.
Zu Empfehlen, ist wie folgt zu härten:
Hardened UNC Paths:
\\*\NETLOGON RequireMutualAuthentication=1, RequireIntegrity=1
\\*\SYSVOL RequireMutualAuthentication=1, RequireIntegrity=1
Die GPO war bisher gar nicht konfiguriert - und an der haben sich die W7 Clients bisher auch nicht beschwert
Woher hast du das Zitat mit der Empfehlung?
Woher hast du das Zitat mit der Empfehlung?
Das war vor Jahren... frag mich nicht, aber ziemlich sicher von Microsoft selbst. Teste das mal, bitte.
hm - ergebnis mti den von dir vorgeschlagenen settings ist ~ 50:50 - einige Kisten haben zugriff, andere nicht
Hier MS dazu mit der Empfehlung: (ergo das selbe was du vorschlägst)
https://support.microsoft.com/de-de/help/3000483/ms15-011-vulnerability- ...
Hier der Technet Thread dazu: (das Thema ist wohl noch aktuell / ungefixt?)
https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831 ...
Gut das Freitag ist und ich am Wochenende zum Baden fahre
Hier MS dazu mit der Empfehlung: (ergo das selbe was du vorschlägst)
https://support.microsoft.com/de-de/help/3000483/ms15-011-vulnerability- ...
Hier der Technet Thread dazu: (das Thema ist wohl noch aktuell / ungefixt?)
https://social.technet.microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831 ...
Gut das Freitag ist und ich am Wochenende zum Baden fahre
das Thema ist wohl noch aktuell / ungefixt?
Wir setzen es so seit mehreren Jahren ein und haben mit Win10 keine Zugriffsprobleme (seit Jahren haben wir nur Win10).Wenn es bei Dir bei der Hälfte der Workstations nict geht, ist irgendetwas faul und ich schätze mal, es hat damit nur bedingt etwas zu tun. Kannst Du mit Sicherheit sagen, dass es ohne den Schutz überall funktioniert, oder hast Du nur einzelne Stichproben genommen?
Also es sind 4 Testrechner mit W10 1709 (wobei unter 1803 selbes verhalten)
Bei RequireMutualAuthentication=0 können alle GPOs lesen
Bei RequireMutualAuthentication=1 gehts bei 2 nicht
die vier Rechner sind alle von der Hardware komplett unterschiedlich - das Internet sagt das manchmal es hilft die Netzwerkkarten treiber zu aktualisieren.
Bei RequireMutualAuthentication=0 können alle GPOs lesen
Bei RequireMutualAuthentication=1 gehts bei 2 nicht
die vier Rechner sind alle von der Hardware komplett unterschiedlich - das Internet sagt das manchmal es hilft die Netzwerkkarten treiber zu aktualisieren.
hm, habe hier eine Theorie, werde wohl aber erst nächste Woche dazu kommen Sie zu testen - mal abwarten was da rauskommt
Interessante Sache, aber habe die Ursache gefunden, es ist eine Nebenwirkung einer anderen GPO:
Administrative Vorlagen \ Systemsteuerung/Anpassung \ Ein bestimmtes Standardbild für den Sperr- und Anmeldebildschirm erzwingen
und das lustige bildchen lag auf \\domain.local\NETLOGON\W10\sperrbildschirm.jpg
Habe es nun umgeändert das ein lokal abgelegtes Bild benutzt wird - und schwupps, ist auch das UNC Hardning Problem weg?!
Meine Theorie ist jetzt folgende: Wenn diese GPO aktiviert wurde, haben die PCs auf den \\domain.local Pfad gleich nach dem booten zugegriffen (also sobald der Sperrbildschirm angezeigt wurde) - falls aber der NIC noch nicht soweit war, haben die einen zugriffsfehler bekommen und haben nun \\domain.local "nicht mehr gemocht" und konnten nur über das aufgeweichte UNC Hardening dazu gebracht werden wieder darauf zuzugreifen.
Klingt absurd, habe es aber nun hin- und hergewechselt, und es ist reporoduzierbar.
Administrative Vorlagen \ Systemsteuerung/Anpassung \ Ein bestimmtes Standardbild für den Sperr- und Anmeldebildschirm erzwingen
und das lustige bildchen lag auf \\domain.local\NETLOGON\W10\sperrbildschirm.jpg
Habe es nun umgeändert das ein lokal abgelegtes Bild benutzt wird - und schwupps, ist auch das UNC Hardning Problem weg?!
Meine Theorie ist jetzt folgende: Wenn diese GPO aktiviert wurde, haben die PCs auf den \\domain.local Pfad gleich nach dem booten zugegriffen (also sobald der Sperrbildschirm angezeigt wurde) - falls aber der NIC noch nicht soweit war, haben die einen zugriffsfehler bekommen und haben nun \\domain.local "nicht mehr gemocht" und konnten nur über das aufgeweichte UNC Hardening dazu gebracht werden wieder darauf zuzugreifen.
Klingt absurd, habe es aber nun hin- und hergewechselt, und es ist reporoduzierbar.
Hallo zusammen,
wirklich schön, 2023 und das Problem ist wieder da.
Betroffen bei uns sind die neuen Dell Precision Tower.
Von 6000 Rechnern sind 20 Betroffen (Nur das neue Dell Modell)
-> Warum zur Hölle...
Erst das setzen von "RequireMutualAuthentication=0," auf Sysvol ist ein zugriff auf Sysvol möglich.
Vorher musste man 15 Min warten.
Ich werde nun aber weiter Forschen ob da was bei Kerberos quer liegt oder wie man das Problem noch lösen kann, ohne eine Sicherheitslücke zu kreieren.
wirklich schön, 2023 und das Problem ist wieder da.
Betroffen bei uns sind die neuen Dell Precision Tower.
Von 6000 Rechnern sind 20 Betroffen (Nur das neue Dell Modell)
-> Warum zur Hölle...
Erst das setzen von "RequireMutualAuthentication=0," auf Sysvol ist ein zugriff auf Sysvol möglich.
Vorher musste man 15 Min warten.
Ich werde nun aber weiter Forschen ob da was bei Kerberos quer liegt oder wie man das Problem noch lösen kann, ohne eine Sicherheitslücke zu kreieren.
