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-Key: 375758

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

Ausgedruckt am: 02.10.2022 um 06:10 Uhr

Mitglied: DerWoWusste
DerWoWusste 01.06.2018 um 13:15:25 Uhr
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.
Mitglied: NetzwerkDude
NetzwerkDude 01.06.2018 um 13:28:49 Uhr
Goto Top
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
Mitglied: DerWoWusste
DerWoWusste 01.06.2018 um 13:51:21 Uhr
Goto Top
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.
Mitglied: NetzwerkDude
NetzwerkDude 01.06.2018 um 15:37:07 Uhr
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?
Mitglied: DerWoWusste
DerWoWusste 01.06.2018 um 15:44:43 Uhr
Goto Top
Das war vor Jahren... frag mich nicht, aber ziemlich sicher von Microsoft selbst. Teste das mal, bitte.
Mitglied: NetzwerkDude
NetzwerkDude 01.06.2018 um 16:07:04 Uhr
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
Mitglied: DerWoWusste
DerWoWusste 01.06.2018 um 16:15:57 Uhr
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?
Mitglied: NetzwerkDude
NetzwerkDude 01.06.2018 um 16:29:34 Uhr
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.
Mitglied: NetzwerkDude
NetzwerkDude 01.06.2018 um 18:26:26 Uhr
Goto Top
hm, habe hier eine Theorie, werde wohl aber erst nächste Woche dazu kommen Sie zu testen - mal abwarten was da rauskommt
Mitglied: NetzwerkDude
NetzwerkDude 04.06.2018 um 10:24:02 Uhr
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.