wznutzer

Das liegt an meiner Unwissenheit. Ich dachte die Vertrauensstellung geht nur verloren, wenn die Kennwörter des Computerkontos nicht übereinstimmen. Nein, leider nicht. Test-ComputerSecureChannel hat nach mehreren Neustarts (nachdem die Kommunikation wieder uneingeschränkt möglich war) noch immer FALSE gemeldet und auch die Anmeldung mit einem Domänenkonto war weiterhin nicht möglich. Test-ComputerSecureChannel mit Repair oder auch Reset-ComputerMachinePassword habe ich nicht probiert, sondern das Computerkonto gelöscht und den Client neu hinzugefügt.

Guten Tag, es gibt kein konkretes Problem zu lösen, aber verstehen würde ich es gerne. Windows 11 Enterprise mit Credential Guard, alles Updates, Domänenmitglied. Im Zuge von Tests habe ich eine Lokale Sicherheitsrichtlinie erstellt (Firewall-Richtlinie) um Verbindungen zu einem bestimmten PC zu verbieten. Durch den unten beschriebenen Sachverhalt wurde dadurch der komplette ausgehende TCP-Traffic verboten (UDP war noch erlaubt). Nach dem erstellen dieser Regel wurde der PC gesperrt, nach ca. 1 Stunde war keine Anmeldung mehr möglich, weil die Vertrauensstellung verloren war. Lt. Eventlog wurde das Event 3210 wenige Sekunden nach dem Erstellen der Regel und ziemlich zeitgleich mit dem Sperren des PCs protokolliert. Wie kann ein PC die Vertrauensstellung verlieren, wenn keine ausgehenden Verbindungen möglich sind? Lt. AD wurde das Computerpasswort vor ca. 1 Woche geändert. Besonderheit in diesem Fall wohl, dass TCP blockiert war, nicht aber alles andere. Erklärung warum der ausgehende Traffic komplett gesperrt war Wenn man in den Lokalen Sicherheitsrichtlinien eine Richtlinie erfasst (Block ausgehend) kann man z. B. keine Remote-IPs angeben. Nach dem Speichern geht man dann in die Regel und trägt die IPs ein. Beim Anlegen der Regel erscheint die Regel sofort in der Windows-Firewall (ohne Beschränkung auf IPs). Aber das nachfolgende Update aktualisiert die Regel in der Firewall *nicht*. Das wird erst beim nächsten Neustart aktualisiert. So lange gilt die ursprüngliche Regel, die dann alles blockt. Das geht sogar so weit, dass wenn man so eine Regel in den Lokalen Sicherheitsrichtlinien anlegt, ändert und dann ohne Neustart sofort wieder löscht, sieht man in den Lokalen Sicherheitsrichtlinien keine Regel, aber die Firewall-Regel der ersten Speicherung bleibt erhalten, ist voll funktionsfähig und kann nur noch über die Registry gelöscht werden. Da gehe ich mal von einem Fehler aus.

Ich glaube ich habe es verstanden. Ich frage mich aber immer, wie kommt man an solche Informationen ? Ich kann da zwei Nullen wegmachen und habe noch immer weniger . ==> andere Welten

Ich musste erstmal den Begriff googeln . Den Vorschlag von @daabm verwende ich derzeit nicht. Ich habe zwar immer die Registerkarten gesehen, aber nie verwendet. Weiß zufällig jemand, ob das auf die Performance geht (die Authentifizierung ohne Verschlüsselung). Ich das einigermaßen gängig oder baue ich da was, was kaum jemand kennt und/oder nutzt?

Ach jetzt wirds Tag, oberhalb meint die Verknüpfung an von der Zahl her niedrigerer Stelle . Aber die GPOs der OUs können dann ja noch immer das "überschreiben". Organisatorische oder technische Besonderheiten. Ist die DDP nicht den anderen gleichgestellt? Passwortrichtlinie ist separat und steht an Stelle 1 .

Extensiv, ausgedehnt / umfassend, ob ich es auch exzessiv (maßlos) mache, weiß ich nicht. Aber lt. @testperson ist es noch ausbaubar .

Guten Tag, evtl. habe ich den Begriff falsch gewählt. Während es üblich ist ganze Netzwerke voneinander zu treffen (VLANs), lese ich kaum etwas darüber die Windows-Firewall zu nutzen. Macht Ihr das auch? Ich mache das ziemlich extensiv mit RDP, WinRM, sogar die VeeamDienste schränke ich auf die nötigen Endpunkte ein. Ist das über das Ziel hinaus? Ich meine, man versucht sich ja so vor jemandem zu schützen der ohnehin schon im Netzwerk ist, andererseits gibt es ja die Sache mit lateral movement. Der kürzlich veröffentlichte Fall, bei dem über die Veeam-Dienste ein Konto angelegt worden war, wäre ja dadurch verhindert worden. Oder ist das in großen Netzwerken einfach nicht zu handeln? Grüße und einen schönen Tag

Zufällig habe ich das sogar gemacht. Die Stufe 3 aus der DDP raus und 5 in eine eigene GPO. Die spezielle GPO für DCs die ich hatte, ist dann auch überflüssig. Allerdings verstehe ich die Aussage nicht komplett. Warum oberhalb und warum meinst du Settings zu Accounts und Kerberos kommen in die DDP oder gerade nicht? Ich habe tatsächlich mal angefangen alles in eigene GPOs zu packen mit eindeutiger Benennung. Aber, wie gesagt, das war Zufall, das hätte ich auch ohne Bedenken in die DDP gemacht, Stufe 3 war ja auch drin. 1) Warum sollte man nichts in die DDP packen? Organisatorisch verstehe ich das, wenn man einen Fehler sucht und GPOs in Verdacht hat, ist es ja b***d in einer Richtlinie, die man deaktivieren will, ganz viele Sachen zu haben. Gibt es auch technische Gründe? 2) Gibt es ein Limit oder "best practice", dass man nicht mehr als X GPOs haben sollte? 3) Was für Settings zu Accounts und Kerberos meinst Du? Danke und Grüße Scheint tatsächlich kein Problem zu sein :-).

Guten Morgen, NTLMv1 sollte man idealerweise deaktiviert haben. Nun ist es so, dass es wahrscheinlich hier und da (wie bei mir) noch Überbleibsel aus vergangenen Zeiten gibt, in denen man die Clients per GPO auf 3 gesetzt hat. Bei allen Windows-Systemen die Support haben ist das der Defaultwert. Könnte ich nicht einfach in der "Default Domain Policy" das auf 5 setzen und die alte Client-GPO löschen? Bei den DCs sollte das sowieso gemacht werden und bei den Clients schadet es nicht. Irre ich mich? Danke und Grüße https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level

Der User in der Firewall der verwendet wird um die Passwörter zu checken (LDAP Bind wie ich gelernt habe) und mit dem auch die Gruppen ausgelesen werden (z. B. darf VPN). Vermutlich wurde doch mal ein Recht vergeben und leider vergessen / nicht dokumentiert. Verstehe ich das richtig? Nicht zu müssen heißt aber zu können. Aber dann geht das Passwort beim LDAP Bind unverschlüsselt über die Leitung und das will man nicht. Richtig?

In meinen Fall ist der User nicht Mitglied, geht aber trotzdem. Das meinte ich damit.

Nein, die Erkenntnis hatte ich schon vor längerer Zeit. Deswegen ist das Computerkonto des RD-Gateway auch da drin. Jetzt muss ich aber noch rausfinden, warum die Abfrage der Gruppenmitgliedschaften geht, obwohl ich mich an keine spezielle Rechtevergabe erinnern kann. Danke für den Hinweis mit LDAP Bind. Das die Mitglieschaft der Authentifizierten User in der Prä-Windows 2000 Gruppe ein größeres Sicherheitsproblem ist, war mir tatsächlich nicht bewusst, war eher „braucht man nicht mehr“.

Ich kann z. B. schon jetzt aus Deiner Antwort „ableiten“, dass es eher schlecht ist, die Authenifizierten User in der Prä-Windows 2000 Gruppe zu haben . So hatte ich das auch mit dem Passwort im Sinn. Wie findet die Firewall heraus, ob das Passwort stimmt oder nicht?

Guten Morgen, es gibt kein Problem, aber verstehen würde ich es trotzdem gerne. Wenn man z. B. die User eines VPN der Firewall gegen das AD authentifizieren will, macht man z. B. im Fall einer Sophos einen Domainjoin in das AD und hinterlegt in der Sophos einen User in dessen Kontext Abfragen (Gruppenmitgliedschaften, Kennwort korrekt usw.) an das AD gestellt werden. Dieser User benötigt aber keinerlei besondere Rechte. Gruppenmitgliedschaften auslesen gehört zu den Standardberechtigungen, die man ja auch einschränken kann. Aber wie funktioniert das mit den Passwörter? Klar kann jeder User versuchen sich irgendwo mit einem fremden Account anzumelden und Passwörter erraten, aber wie macht das z. B. regulär eine Firewall? Auch mit einem Loginversuch, wo? Die Firewall braucht kein Passwort aus dem AD auslesen, es reicht ja die Info richtig oder falsch? Wenn man weiß wie das funktioniert, könnte man da evtl. ableiten, dass irgendwas besser verboten gehört, was bisher erlaubt ist? Danke und Grüße

Neuentwicklung: Der Fix wird lt. Support nicht in den Updates vom Oktober enthalten sein, sondern separat am 15. Oktober veröffentlicht werden. Insofern hat sich der Case dann doch gelohnt.