cj_berlin

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.

Moin, das mit dem Domain Join des VPN-Konzentrators bzw. des RADIUS-Servers kann helfen, LDAP mit S nicht betreiben zu müssen, denn wenn Kerberos bereits zwischen Client (VPN-Konzentrator) und Server (Domain Controller) verwendet wird, kann auf LDAPS verzichtet werden. Aber nur, wenn es ordentlich gemacht wurde

Was auch gerne genommen wird, sind GPOs, welche das Skript nicht ausführen, sondern als geplanten Task hinterlegen. Das kannst Du auch nochmal checken.

Ja.

Wo sind die Skripte hinterlegt? Group Policy? Dann sind sie vielleicht in zwei, drei GPOs hinterlegt, die da gelten - GPRESULT ist Dein Freund.

Upgrade von 2016 auf 2019 ist doch "Version", nicht "Edition"

Wenn Du auf dem Admin-Account andere Berechtigung hast als auf dem AdminSDHolder, dann funktioniert entweder der SDHolder-Prozess nicht, oder auf dem AdminSDHolder ist die Vererbung aktiviert (auch darüber müsste Dir PurlpleKnight berichtet haben). Der Normalzustand der Admin-User ist "Vererbung deaktiviert, ACL identisch mit AdminSDHolder". Und auf dem AdminSDHolder kannst Du den Exchange Servern alle Rechte entziehen, die Du willst, im Prinzip sogar alle, wenn Du nicht vorhast, Admin-Accounts Postfächer zu verpassen.

Wenn Du in allen Sites DCs hast und die Topologie nun stimmt, ist sie nicht erforderlich. Ansonsten, Enabling Clients to Locate the Next Closest Domain Controller | Microsoft Learn

Moin, unabhängig von PurpleKnight: Solche Anpassungen, und zwar lieber ein entferntes "allow" als ein hinzugefügtes "deny", musst Du für hochprivilegierte Benutzer und Gruppen nicht am Objekt selbst, sondern am AdminSDHolder-Container vornehmen, denn sonst werden sie nach einer Stunde (default) wieder überschrieben. So wie Du es schlderst, prüft PurpleKnight hier scheinbar nicht genau genug, aber ich lasse es jetzt checken. Nichtsdestotrotz, alles, was sich zu den Default-Admin- und Operator-Gruppen zurückverfolgen lässt, bekommt die Berechtigungen vom AdminSDHolder normalerweise drübergebügelt.

Hatte noch keine Zeit gefunden reinzugucken, aber ich habe die Frage dort platziert, wo sie hingehört. Wenn ich was höre, poste ich es hier.

Moin, das würde ich machen. Eine Topologie, die automatisch die korrekten Verbindungen erzeugt, ist immer schöner, als manuell nachhelfen zu müssen. Zumal bei Dir ja keine extremen Sonderlocken vorhanden sind. Du wirst allerdings nur eine Verbindung automatisch angelegt bekommen, und das ist auch gut so.