netzwerkdude
Goto Top

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?

Content-ID: 375758

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

Printed on: October 16, 2024 at 02:10 o'clock

DerWoWusste
DerWoWusste Jun 01, 2018 at 11:15:25 (UTC)
Goto Top
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.

Zugriff auf \\domain.local\sysvol nicht erlaubt ist
Beschreibe mal genauer, wie sich das feststellen lässt und was da steht.
NetzwerkDude
NetzwerkDude Jun 01, 2018 at 11:28:49 (UTC)
Goto Top
Bei W10 Kisten ist es so das die Group Policies nicht gezogen werden, mit folgendem fehler:
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
DerWoWusste
DerWoWusste Jun 01, 2018 at 11:51:21 (UTC)
Goto Top
Wie war denn diese Einstellung, bevor Du sie geändert hast?

Zu Empfehlen, ist wie folgt zu härten:
Hardened UNC Paths:   
\\*\NETLOGON RequireMutualAuthentication=1, RequireIntegrity=1 
\\*\SYSVOL RequireMutualAuthentication=1, RequireIntegrity=1 
RequirePrivacy=0 sollte man nur setzen, wenn alle Beteiligten SMBv3 sprechen können, was für Win7 ja nicht zutrifft.
NetzwerkDude
NetzwerkDude Jun 01, 2018 at 13:37:07 (UTC)
Goto Top
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?
DerWoWusste
DerWoWusste Jun 01, 2018 at 13:44:43 (UTC)
Goto Top
Das war vor Jahren... frag mich nicht, aber ziemlich sicher von Microsoft selbst. Teste das mal, bitte.
NetzwerkDude
NetzwerkDude Jun 01, 2018 at 14:07:04 (UTC)
Goto Top
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 face-smile
DerWoWusste
DerWoWusste Jun 01, 2018 at 14:15:57 (UTC)
Goto Top
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?
NetzwerkDude
NetzwerkDude Jun 01, 2018 at 14:29:34 (UTC)
Goto Top
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.
NetzwerkDude
NetzwerkDude Jun 01, 2018 at 16:26:26 (UTC)
Goto Top
hm, habe hier eine Theorie, werde wohl aber erst nächste Woche dazu kommen Sie zu testen - mal abwarten was da rauskommt
NetzwerkDude
NetzwerkDude Jun 04, 2018 at 08:24:02 (UTC)
Goto Top
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.
MemphisF
MemphisF Aug 07, 2023 at 15:10:55 (UTC)
Goto Top
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.