Wann wird das AD-Passwort des Computerkontos erneuert? Nicht nur alle 30 Tage?

[wznutzer 35]

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.

[cj_berlin 1.329]

Moin,

 

der Titel passt vermutlich nicht zum Sachverhalt, denn das Ändern des Kennworts scheint ja nicht das Problem zu sein. Was das Problem mit dem Secure Channel und dem Event 3210 vermutlich wirklich verursacht hat ist, dass 389/udp zu diesem DC immer noch möglich ist, während alle anderen, auf TCP basierenden Protokolle blockiert sind. Ich trau mich das gar nicht zu fragen: Hat sich der Secure Channel repariert, nachdem die Regel entfernt und der betroffene PC neugestartet wurde?

 

Seit Windows 7 SP1 wird Netlogon das lokale Kennwort erst ändern, wenn bestätigt ist, dass es auch im AD gesetzt wurde.

[wznutzer 35]

vor 7 Stunden schrieb cj_berlin:

der Titel passt vermutlich nicht zum Sachverhalt, denn das Ändern des Kennworts scheint ja nicht das Problem zu sein.

Das liegt an meiner Unwissenheit. Ich dachte die Vertrauensstellung geht nur verloren, wenn die Kennwörter des Computerkontos nicht übereinstimmen.

 

vor 7 Stunden schrieb cj_berlin:

Ich trau mich das gar nicht zu fragen: Hat sich der Secure Channel repariert, nachdem die Regel entfernt und der betroffene PC neugestartet wurde?

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.