Täglichlerner

Moin zusammen, die mir hier geantwortet haben, es ist ja ein recht komplexes Thema und ich bin dankbar für alle Beiträge, von denen ich etwas gelernt habe - würde ich einen NiCHT markieren als hilfreich, wäre das unfair (selbst der Backup-Hinweis ist ja wichtig für jemanden, der die Absicht hat, die CA-Stelle platt zu machen). Ich habe mich also durch die entsprechenden Links getankt und dann mich entschlossen, nach CA-Backup Prozedur, den entsprechenden DC (ja, es ist früher mal die CA auf einen DC installiert worden, leider - heute gibt es 3 DC) - also die CD-Stelle platt zu machen und den DC mal für zwei Tage aus dem Netz zu nehmen. Es gab dann "nur" ein Problem mit d.velop-Archiv. DAS aber hatte seine CA nur auf dem d.velop-ArchivServer (VM). Um das Problem mit dem Archivzugriff zu lösen, habe ich die CA-Stelle aus dem Backup wieder hergestellt und LDP mit 636 klappte wieder ohne Fehler. Das Ganze ist aber nur eine Übergangslösung, denn der d.velop Archivserver wurde inzwischen auf einer neuen VM mit neuer Version - und per IDP diesmal - als neues Testsystem neu aufgesetzt bis auch die ERP-Soft (infor) mit neuem Meilenstein installiert wird und dann mit der neuen d.velop-Version als Testsystem in Gang gesetzt wird. So lange also lasse ich das alte Prod-System weiter laufen - seit meiner Spielerei mit der Abschaltung der CA-Stelle und der erneuten Aussetzung per aktuellem Backup läuft alles einwandfrei. Gelernt habe ich, dass es einfacher ist, sich mit einer kostenpflichtigen Fachperson zusammenzusetzen (gerne auch remote), dann kann man besser schlafen. Bei diesem Projekt mit den geplanten Upgrades der ERP und der Archivsoftware brauche ich lt. Auskunft von infor und d.velop keine CA-Stelle da die Zugriffe der Clients via IDP abgesichert werden. Dann endlich werde ich den alten Hardware DC, auf dem die jetzige CA läuft, nach CA-Rückbau, demoting der alten DC-Maschine und Entfernung aus dem AD in. den Hades schicken. Also - noch mal Danke für eure Beiträge, die alle was dazu beigetragen haben, mich für den Umgang mit CA zu sensibilisieren !!

ich bezog mich auf cj_berlin: "Ansonsten google mal nach capolicy.inf und installiere die CA erst mal "blank" und veröffentliche nur die Vorlagen, die Du wirklich brauchst, berechtigt nur für die User/Computer, die sie jeweils wirklich benötigen." ... und beobachte die Veränderungswünsche vom Archiv-Software-Support (kritisch), weil es ja "nur" darum gehen sollt, dass sich die 5 Clients bei Verbindungen zum Archiv beim Server authentifizieren sollen - mehr nicht. Dazu müsste ich allerdings in der Lage sein, das zu beurteilen ... ich schau mal und frage euch ggf. ;)

Vielen Dank für die drei Beiträge vom Wochenende ! .... ja, ich habe ein Backup der CA..stelle vom Januar 2025. Aber ich möchte keine neue CA aufsetzen mit einem Import des Backups, sondern mich von den Altlasten einer nie benutzten CA seit Einrichtung 2020 befreien. (macht das Sinn?) Ich überlege gerade, ob ich die phys. Maschine für CA wieder zum Laufen kriege, um dann eine geordnete Dekommissionierung der CA nach Vorlage etwa von https://learn.microsoft.com/en-us/troubleshoot/windows-server/certificates-and-public-key-infrastructure-pki/decommission-enterprise-certification-authority-and-remove-objects hinbekomme - trainingsmäßig :) Aber meint ihr nicht auch, dass das zu viel Aktion ist - nur Training StepbyStep lt URL? Danke auch für den Hinweis zum Thema "Smartcard" (NTAuth-Container). Und ja, die DCs werde ich vom alten CA-Müll säubern. Die neue CA-Stelle will ich auf einer separaten VM aufsetzen und sie ist in meiner Umgebung nur dazu da für eine neue ArchivSoft D.velop, die in ihrer neuen Version eine CA-Stelle braucht (sie wird von d.velop bei mir eingerichtet). Ich selber setze also nur die CA "blank" auf. Und, Nils, ob ich eine PKI brauche, muss mit dem d.velop-Supporter geklärt werden. In meiner kleinen Umgebung brauchte ich eigentlich keine CA - jetzt eben nur für die Authentifikation der paar Clients mit dem neuen d.velop-Archivserver d3. "PKI sind böse" ... ich dachte eher Putin oder Trump sind es. Viele Grüße

Die alte Maschine mit einem nicht genutzten, aber mal installiertem CertServer Server2019 ist irreparabel defekt. Ich möchte gerne eine VM 2022 aufsetzen und dort einen neuen CertServer einrichten, der dann aber auch bald für ein neu zu installierendes Programm in der Domäne genutzt werden soll. Meine Frage an die Experten: - Laufe ich in irgendwelche Probleme, wenn ich in der Domäne einen neuen CertServer installiere? - MUSS ich in den beiden DCs, die laufen, irgendwelche Einträge VOR der neuen 2022 CertServer-Installation suchen und entfernen? Ich betone lieber noch mal: der physisch defekte Server mit der Cert... ist nur einmal vor Jahren standardmäßig installiert worden, aber es sind nie Zertifikate darauf eingerichtet worden. Bedanke mich für ein paar Hinweise ! Muriel

Ja, ich hab´s kapiert. Time is changing faster than i thought. Danke für alle wohlgemeinten Ratschläge.

Es sei denn, man ist masochistisch veranlagt :- Natürlich ist es besser, die Schotten antizipatorisch dicht zu machen und die Email-user zur Vorsicht aufzurufen. Aber da sitzen Menschen an den Kisten - unterschiedlichste Beweggründe zum Fehlgriff. Realität ist eben alles zwischen "worst case" und "oh, Datei weg". b***d wäre nur, wenn das "Emergency Response Team" einen auf Auslassungen aufmerksam macht, die man hätte bei Wissen vermeiden können.

ok, die Terminologie könnte ich noch verbessern. Daher thx für die Klarstellung. ERP mit SQL2016 und PowerShell-Script zum Export der DB alle 4 Std. Muss ich da nachsehen, ob zum Original eine Änderung stattgefunden hat? Sonst Makros kein Thema hier.

@NorberFe :- .. ich wollte mit dem DB-Beispiel sagen, dass eben alle Altdaten aus Sicherungen - wenn dann schon seit Monaten oder Jahren "unbemerkt" gehackt - sleeper - immer korrupt sein könnten. WO soll man da ein Zeit-Limit für "saubere" Daten setzen. Ja, selbst, wenn ich die letzte DCvm nähme und händisch in einen neu aufgesetzten DC das AD vom DCvm "abschreiben" würde - ich hätte also ein sauberes AD/DC - dann kämen ja irgendwann auch wieder die Übernahme von bis zum Hack-Screen gesicherten Unternehmensdaten wieder rein und so ein Schläfer schaut aus einem Client aus einem PDF-File raus und alles wäre wieder obsolet.

Klar kann man da spekulieren: jahre-, monatelange Infiltrierung. Dann kann man ja theoretisch ALLES vergessen. Selbst die Datenbanken von Wochen oder Monaten wären obsolet. Ich betrachte den letzten verbliebenen DC auch nicht als vertrauenswürdig. Nehme mal einen, der zwei, drei, vier Wochen alt ist (tombstone 365) und nicht im Netz war. Aber wie ist die Alternative: DCs neu aufsetzen und alle nötigen Einstellungen neu? Und was ist, wenn eine ERP Datenbank gehackt ist, ein Mitgliedserver/Fileserver mit einem PDF z.B.?? Läßt sich ein KMU für >100tsd ein Anti-Hacker-Team kommen?? Oder wieder Karteikarten?

Danke, auch DAS hat mir weitergeholfen. Gruß, Muriel

Danke. So habe ich es vor 2 Wochen in einer Testumgebung gemacht mit unter der Annahme, dass alles alte durch Ransom korrupt ist und das auch schon unbemerkt vor 2 Wochen passiert sein kann was die DCvm angeht: Bis hierher lief die Testung ohne sichtbare Macken durch. Kommt jetzt drauf an, wann die Daten korrupt wurden durch Hack und wie sauber die Sicherungen waren. Hoffe, euch nicht mit diesem Newbie-Teil zu sehr aufgehalten zu haben. Und noch mal vielen Dank allen !

Gut. Du meinst jetzt die Metadaten im verbliebenem DCvm mit Bezügen zu den plattgemachten Hardw.-DCs?

Ok, verstanden. Dann würde ich mich freuen, wenn ich ausschließlich zu diesem Punkt der gleichen Namen und IPs was hören würde. Und zwar ohne ;- würde gerne von cj-Berlin wissen: Er schrieb: "Physische DCs mit den alten Namen und IP-Adressen wieder promoten". Geht das wirklich so? Sind da nicht eigene SIDs der Maschinen, wenn ich nun nicht den "hardware "plattgemachten DC" neu aufsetze, sondern eine neue Hardware nehme? Bislang habe ich es testweise so gemacht: neue Hardware, neuer Name und IP, bei der "echten" DCvm angemeldet. Dann in der DCvm alle Metadaten der beiden korrupten DC gelöscht. Dann den hardware-DC promotet und in einem Test-Client (Image eines PROD-Clients) die DNS angepasst. Danke.

Moin, danke erst mal für eure hilfreiche Beteiligung. Wollte noch - bevor ich mit meiner ausführlichen Antwort und meinem Testbericht beginne - etwas von cj-Berlin wissen: Er schrieb: "Physische DCs mit den alten Namen und IP-Adressen wieder promoten". Geht das wirklich so? Sind da nicht eigene SIDs der Maschinen, wenn ich nun nicht den "hardware "plattgemachten DC" neu aufsetze, sondern eine neue Hardware nehme? Bislang habe ich es testweise so gemacht: neue Hardware, neuer Name und IP, bei der "echten" DCvm angemeldet. Dann in der DCvm alle Metadaten der beiden korrupten DC gelöscht. Dann den hardware-DC promotet und in einem Test-Client (Image eines PROD-Clients) die DNS angepasst. Also passiert nichts, wenn ich in den sauberen neuen DCs die gleichen Namen und IPs nehme? Ansonsten würde ich gerne den hier Beteiligten eine ausführlichere Beschreibung des Recovery anbieten, um auch auf eventuelle Lücken zu sprechen zu kommen. Sicher ist das hier für einen >50 Betrieb kein Thema, aber ggf. gibt es ja solche Leser von KMU, für die das interessant wäre? Muriel

Danke Dir für den Hinweis, dass AD recovery ein wichtiger, aber nicht einziger Schritt ist. Genau das habe ich ausdrücklich in meinem Text anklingen lassen (2. Abschnitt). Aber es geht mir hier jetzt ausschließlich um das AD und dessen Wiederherstellung mithilfe einer sagen wir 2-wochenalten VM (die offline war bei Hack) nach Verschlüsselung aller online gewesenen Geräte. DIE sind alle gebackuped und können supi neu aufgesetzt werden ohne Datenverlust. Meine Aufmerksamkeit gilt den laufenden DCs mit AD, die im angenommenen Fall auch verschlüsselt wären und meine Bitte wäre an euch, mir zu sagen "ist es eine Möglichkeit, die AD so wie beschrieben, wiederherzustellen"? Und was habe ich ggf. übersehen?