cj_berlin

Denk an Log4j - mit Bugs ist immer alles möglich. Ich würde Syno vorsichtig zutrauen, das soweit ordentlich gebaut zu haben, dass selektiver schreibender/löschender Zugriff auf WORM nicht möglich ist. Bei Ransomware spielt der gezielte Zugriff aber keine Rolle, und hier denke ich, dass es durchaus möglich ist, sämtliche Daten auf wiederbeschreibbaren Medien unbenutzbar zu machen. Platte mit ein bisschen Verschlüsselung und Software-Überbau ist eben kein WORM

Das ist der Sound, den der DNS-Cache beim Leeren macht

Moin, "realistischer abbilden" = "Windows RRAS als interner Router wird vermutlich nicht zur Anwendung kommen" pfSense kann ich wärmstens empfehlen. Grundlegendes Routing ist in 5 Minuten eingerichtet, und dann kann man sich austoben. Nutze ich seit Jahren, in allen meinen Laboren, von ganz klein bis ganz ordentlich. Mein derzeit größtes pfSense hat 14 Beine.

...doch wie immer man es drehen und wenden will, braucht es einen User *mit* Admin-Berechtigung, um einen Prozess mit erhöhten Rechten zu starten, sonst wäre das ganze UAC-Thema ja komplett für die Füße Du kannst einen geplanten Task mit dem gewünschten Sicherheitskontext erstellen und den "Normal-User" zum Starten dieses Tasks berechtigen.

Moin, welches Betriebssystem hat denn "der" Hyper-V Host? Lizenzierung von virtualisierten Client-OS ist generell nicht einfach.

Moin, das kann keine Absicht sein, da gibt es nichts dahin zu stellen. Wenn es sich reproduzieren lässt, ist es ein Bug, denn idealerweise sollte kein Zertifikat jemals dieses Merkmal haben.

Moin, schau mal, ob sich in die "Trusted Roots" am betroffenen Client ein Zertifikat eingeschlichen hat, das nicht von sich selbst signiert ist, und falls ja, verschiebe es entsprechend dem Nutzungszweck - Endpunktzertifikate nach "eigene" ("my"), Zertifizierungsstellen nach "Zwischenzertifizierungsstellen".

Moin, habt ihr bei der Portierung auch *wirklich* alle Spuren der physikalischen Netzwerkkarten bereinigt? Ich habe Ähnliches mal gesehen nach einem, sagen wir mal, blauäugigen P2V...

Das dachte ich mir auch 😎 https://link.springer.com/book/9798868809408

Oder, je nachdem, was der Kunde *wirklich* braucht, einfach keinen Exchange einsetzen, sondern MDaemon, SmarterMail, Kerio Connect oder sowas. Cloud ist NICHT die Antwort auf alles - das ist immer noch 42.

Moin, Exchange auf DC installieren, ist zwar (leider) nicht unsupported, hat aber die Eigenart, dass damit ein "Bund für das Leben" eingegangen wird - Du kannst dann weder den DC demoten, noch Exchange entfernen. Daher wäre selbst ohne das unglückselige Inplace-Upgrade der Weg, um das in einen verwaltbaren Zustand zu überführen ein steiniger: neuen DC in die Domäne aufnehmen, promoten, sicherstellen, dass Replikation funktioniert FSMO-Rollen auf neuen DC übertragen neuen Exchange auf einem Member-Server installieren Postfächen, Konnektoren und Client Access auf neuen Exchange migrieren versuchen, alten Exchange zu deinstallieren - manchmal gelingt es versuchen, alten DC zu demoten - manchmal gelingt es auch alten Server ausschalten, unabhängig vom Ergebnis der vorherigen beiden Versuche mit NTDSUTIL alten DC rausbereinigen mit ADSIEDIT Reste vom alten Exchange rausbereinigen Dabei habe ich bewusst "vergessen", dass auf dem alten Server die eigentlich wichtige Anwendung installiert ist, und mich nur auf die Microsoft-Produkte konzentriert Was ich aus Deiner Schilderung nicht verstehe, und die Frage wurde oben auch schon gestellt - wenn es alzeptabel war, alle Exchange-Daten zu löschen, warum soll Exchange jetzt nochmal aufgebaut werden? Exchange entfernen wenn es nicht benötigt wird --> https://www.frankysweb.de/exchange-2016-manuelles-entfernen-eines-exchange-servers-single-server/ und vermutlich ist es genau das, was Du machen musst. Exchange-Dienste kannst Du in der Registry löschen, virtuelle Verzeichnisse von Exchange aus IIS ebenfalls. Dann hast Du einen DC mit DATEV, auf dem ein Paar Restkrümel von Exchange noch rumdümpeln, aber die stören dann nicht.

Die "Account Policy <--> DDP"-Magie hat, wenn ich mich recht erinnere, auch ihre Entsprechung in "Klassische Audit-Policy <--> DDCP", woher die Empfehlung resultiert, Auditing für DCs in der DDCP zu konfigurieren, die man vereinzelt noch liest. Tatsächlich nutzt aber vermutlich keiner mehr die klassische Variante, und für Advanced gibt es keinen solchen Rückkanal mehr. Aber an sich war der Gedanke nicht ganz falsch - setze ich mit AUDITPOL.EXE die Einstellungen auf einem DC, dübelt er sie in die DDCP, und eine Zeit später haben wieder alle DCs die gleichen Überwachungseinstellungen.

Und jetzt Aufgabe mit Sternchen (ich weiß die Antwort tatsächlich nicht): Schließt das Häkchen in Martins Screenshot auch Änderungen an der SACL mit ein? Ich weiß mit Sicherheit, dass es das in AD nicht tut, und keine der MMC-basierten Konsolen zeigt dieses Recht oder erlaubt es zu setzen. Da gibt es aber die LDP.EXE, womit das grafisch geht - und halt mit den ganzan Kommandozeilen-Tools. Da der Dialog im Explorer verdammt ähnlich anmutet wie in ADSIEdit, es aber kein LDP.EXE für NTFS gibt, bleiben vermutlich nur Kommandozeilen-Tools. Richtig?

Moin, da würde ich doch gern meinen Vorrat an 2-Cent-Münzen hier ausschütten Re Overkill: Ich predige seit Jahren, vermutlich inzwischen Jahrzehnten: In Sachen Security ist alles, was mit vorhandenem Know-How und mit den vorhandenen Resourcen managebar ist, einfach zu tun. Alles, was sich gut anhört, aber nicht managebar ist, ist einer Risikobewertung zu unterziehen - ist es riskanter, XYZ nicht zu machen, oder mit einem nicht beherrschbaren Konstrukt zu leben? In meinen Augen gehört der Fall "Alles ist im AD, hört auf GPOs und hat eine Windows-Firewall am Start, also machen wir granulare Firewall-Regeln per GPO" in die Kategorie "managebar". Re Mikrosegmentierung: Ich wünsche mir seit Jahren, wir hätten zwei Begriffe dafür. Und dann wäre in meiner Welt "Mikrosegmentierung" genau NICHT das, was die Windows-Firewall tut, sondern Distributed Firewalls egal welcher Art, die den Traffic auch innerhalb eines Subnetzes zwar granular steuern, den einzelnen Hosts aber verborgen bleiben. Aber wir haben soweit ich weiß nur den einen Begriff, also deckt er auch die Windows-Firewall ab. Warum hier unterscheiden? Eine Host-Firewall ist ein anderthalbschneidiges Schwert - einerseits schützt sie direkt an der Quelle, andererseits muss dafür die Konfiguration lokal vorgehalten werden. Und bei der Windows-Firewall ist sie noch nicht einmal obfuskiert. Somit erschwert man zwar im ersten Moment Lateral Movement eines potentiellen Angreifers, erleichtert ihm dafür jedoch zumindest in einem Punkt die Reconnaissance. Besonders viel schenkt man den Kolleginnnen dann, wenn man nicht nur eingehende, sondern auch ausgehende Regeln pflegt. Da ist der von @daabm zitierte Ansatz schon deutlich sparsamer in Bezug darauf, was durch die lokale Registry preisgegeben wird.

...wo Festplatten noch in Megabyte und RAM in Kilobyte gemessen wurden und Monitore eine Zeilenlänge von 80 Zeichen hatten, so dass Abkürzungen durchaus ihre Daseinsberechtigung hatten

Patchen an sich ist eine Disziplin, die nur existiert, weil die Produkte fehlerhaft sind von Menschen gemacht werden.

Moin, "erste Gehversuche" immer im Audit-Modus beginnen und die Logs auswerten. Erst dann scharf schalten

Über eine Token Ring-Verbindung geht das doch Ruck-Zuck...

Moin, meinst Du mit "commit" die Autorisierung von DHCP in AD oder irgendetwas anderes?

Träumer

Die Limits sind wohl im Code, nicht im AD. Aber in jedem Fall ist es in Tagen

...und "für alle" wäre dann eine ForEach-Schleife.

Moin, für Fragen zu Purple Knight empfehle ich den offiziellen Slack-Channel: https://purpleknight.slack.com/join/shared_invite/zt-o8ojqo68-S7bQLV3U6w1V525lHMH~aA#/shared-invite/email . Dein Verständnis von lastLogon vs. lastLogonTimestamp ist korrekt. Was die echte Aktualisierung angeht, ist es "gut genug" (Du willst ja *eigentlich* am liebsten sofort wissen, dass dieses Konto benutzt wurde), zumal Purple Knight ja das Sync-Interval berücksichtigt, sofern es größer 14 ist, und das Fenster entsprechend erweitert. Die falschen positiven (https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/ba-p/257135) sind indes auch nicht ganz wertlos, da sie darauf hinweisen, dass *jemand* *etwas* mit diesem Account versucht hat In einer etwas weiter verzweigten Infrastrukltur kann ein Tool wie Purple Knight lastLogon nicht zuverlässig verwenden, da es möglicherweise keinen Computer gibt, der alle DCs sehen kann. Und, wie @daabm bereits anmerkte, der DC mit dem frischesten Wert muss zum Zeitpunkt der Abfrage noch vorhanden sein. Wie mache ich das? Das Attribut ist in Tagen, und das Minimum von 5 ist hartkodiert.

...und vor allem (das is bei @NilsK der Punkt "welche relevanten Szenarien...") solltest Du den häufigsten Fehler der HA-Projektierung nicht wiederholen: Man beschäftigt sich bis zur Erschöpfung mit dem Ausfall eines RZ-Standorts (was äußerst selten ist, vom kontrollierten Shutdown einmal abgesehen) und vernachlässigt dabei komplett den Ausfall der Standortverbindung (was Gang und Gäbe ist).

Moin, von allem anderen abgesehen, lass Exchange einfach Exchange sein, bau eine DAG über beide Standorte, bilde sie ordentlich im AD ab und stelle in jedem mindestens einen Domain Controller bereit. Für alles andere kannst Du Hyper-V Replica einsetzen, sofern für die jeweiligen Workloads supported.