NilsK

Moin,

ah, OK, jetzt verstehe ich den Zusammenhang. Hätte er damals gleich Datacenter genommen, entstünde das Problem gar nicht erst. Ja, schwierige Situation.

Meine Vermutung: Dazu ("deaktivierte Cores") wird man keine wirklich exakte, verlässliche Antwort bekommen. Tendenz: Lizenzier das, was physisch drin ist, dann bist du auf der sicheren Seite. Alles andere wird immer ein Fragezeichen haben.

Gruß, Nils

Moin,

bei 10 VMs 4000 Euro Unterschied? Das würde mich sehr erstaunen.

Gruß, Nils

Moin,

Dazu sei auch angemerkt, dass man eine Gesamtstruktur mit mehreren Domänen heute (= seit über 15 Jahren) nicht mehr "absichtlich" entwirft. Sie ist technisch möglich, aber es gibt keine Gründe, sie einzurichten (etwas vereinfacht gesagt, aber darauf läuft es hinaus). Solche Fragen sind also tatsächlich sehr theoretisch.

Zu Frage 1 wäre also mindestens zu klären, wo denn die Anforderungen herkommen und was denn eigentlich erreicht werden soll. Dann kann man eine Lösung entwerfen. In der IT wird allzu oft von der Technik her gedacht, das führt aber oft in die Irre.

Rein technisch hat Evgenij den richtigen Hinweis gegeben: das steuert man dann - wenn es denn so sein soll - über Berechtigungen.

Auch bei Frage 2 wäre zu klären, was denn hinter der Anforderung steht. So, wir es da steht, ist es nicht zu lösen. Entweder man richtet das Schema (und die Exchange-Organisation) im bestehenden Forest ein oder in einem separaten Forest, was dann zusätzliche Konfigurationen erfordert. Beides hat Vor- und Nachteile.

Gruß, Nils

Moin,

vor 8 Minuten schrieb 4zap:

Aber dann sind wir wieder bei einer managed PKI und wer will das schon.

sagen wir es so: Wenn man sich eine Windows-PKI mal genauer ansieht, spricht einiges dafür, das nicht selbst an der Backe zu haben. 

Gruß, Nils

Moin,

sicher sogar. 

Ich verstehe auch, dass man das nutzen können will. Nur will Microsoft es offenkundig nicht mehr pflegen. Das ist eben eine übriggebliebene Komponente, hinter der sie eigentlich nicht mehr stehen, die sie aber auch nicht entfernen. So wie WINS.

Gruß, Nils

Moin,

wenn sie es wollten, hätten sie es schon getan. Ich gehe davon aus, dass von deren wichtigen Kunden niemand mehr diese Seite benutzt.

Gruß, Nils

Moin,

vor 38 Minuten schrieb zahni:

Hä, die erzeugt doch den Private Key? Irgendwie stehe ich auf dem Schlauch.

das glauben viele, ist aber falsch. Es ist so, wie Norbert und Evgenij sagen.

Der Witz am Private Key ist, dass er privat, also geheim ist. Nicht nur in einer idealen Welt darf der nie den Rechner verlassen, auf dem er erzeugt wurde (höchstens als Backup). daher kann die CA den auch nicht erzeugen, denn dann kennte sie ihn ja und er wäre nicht privat. Die Aufgabe der CA besteht ausschließlich darin, den zugehörigen Public Key zu zertifizieren (also zu bestätigen, dass sie davon ausgeht, dass er zu der beantragenden Einheit gehört).

Leider gab es in der Vergangenheit CAs, die das anders gesehen und ein Schlüsselpaar für Kunden erzeugt haben. Und leider haben das auch manche "Security-Komponenten" getan, die bei Enterprise-Kunden im Einsatz sind. Das ist ganz großer Käse und geht gar nicht.

Aus demselben Grund sind auch Zertifikate, die auf mehreren Servern eingesetzt werden, M*st.

Gruß, Nils

Moin,

ich erwähne es ungern, aber nslookup ist immer noch das falsche Tool. Die ganzen "no such name" sind dort normal bzw. Absicht.

Gruß, Nils

Moin,

vor 43 Minuten schrieb zahni:

Na, dann ist das Copyright doch abgelaufen

dieses Argument habe ich schon oft als wirklich ernst gemeinte Aussage gehört.

Gruß, Nils

Moin,

korrekt.

[Never change a running system? Bullshit! | faq-o-matic.net]
https://www.faq-o-matic.net/2008/02/20/never-change-a-running-system-bullshit/

Hier ja sogar ein besonders krasser Fall.

vor 3 Stunden schrieb Dutch_OnE:

Alles klar, vielen Dank für die Antwort. Sowas hatte ich mir schon fast gedacht.

Ach, und weil es bei jemand anderem vor Jahren so war, ist das bei dir auch so? 

Also, ich probierte jetzt erst mal Updates aus - der Aufwand ist doch deutlich geringer, als ein Board zu tauschen.

Gruß, Nils

Moin,

ja, der Artikel ist sehr laienhaft und überspielt mangelnde Sachkenntnis mit reißerischer Darstellung.

Zitat

Ein solcher Hinweis könnte bspw. in einem ungewollten Ausführen von Mimikatz auf einem System der Domäne liegen.

Auch dies klingt ja kompetenter als es ist. Wie sollte man so einen Nachweis denn bringen? Ist ja nicht so, dass Mimikatz ins Eventlog schreibt, wenn es läuft. Und den Angriff erkennt man i.d.R. deshalb nicht, weil Mimikatz ja nun mal Lücken ausnutzt und die Kommunikation technisch betrachtet valide ist.

Das Ändern des krbtgt-Kennworts wiederum ist eigentlich nur dann sinnvoll, wenn man während des Vorgangs sicher sein kann, dass der Angreifer nicht im Netz ist. Das ist nach einem Angriff in einer Offline-Phase der Fall - bei einem regemläßigen, prophylaktischen Wechsel aber eben nicht. Wenn ein Angreifer in der Situation drin bleiben will, lässt er sich vom ersten Wechsel benachrichtigen und hat dann genügend Zeit, vor dem zweiten Wechsel zu reagieren.

Gruß, Nils

Moin,

abgesehen davon, ist nslookup auch kein Tool, um die Namensauflösung zu prüfen. Damit fragt man die DNS-Datenbank ab. Das ist etwas ganz anderes. Und es arbeitet auch anders als der Client Resolver. Daher ist es manchmal interessant, aber meistens ohne Aussage für konkrete Probleme.

[Wenn (und warum) nslookup unerwartete Ergebnisse zeigt | faq-o-matic.net]
https://www.faq-o-matic.net/2014/02/12/wenn-und-warum-nslookup-unerwartete-ergebnisse-zeigt/

Gruß, Ni"ich erwähnte das vielleicht schon mal"ls

Moin,

Nun sei doch nicht so pragmatisch! 

Gruß, Nils

Moin,

Das Golden Ticket wird ungültig, wenn der Kennwort-Hash sich zweimal geändert hat. Es ist mit diesem Hash verschlüsselt.

Gruß, Nina

Moin,

spontan fällt mir dazu nur ein, dass du evtl. das falsche Backup wiederherstellst.

Gruß, Nils

Moin,

die AD-Replikationszeit kann man messen, dazu hab ich vor Urzeiten mal mit einem MS-Mitarbeiter einen Artikel geschrieben. Ich guck mal, ob sich dazu noch was Zugängliches findet.

Edit: Ach guck, da isses.

[ADRepCheckLatency: AD-Replikationslatenz messen | faq-o-matic.net]
https://www.faq-o-matic.net/2009/09/30/adrepchecklatency-ad-replikationslatenz-messen/ 

Die Kennwort-Dopplung bei dem Account ist genau auf die Bedenken zurückzuführen, die du hast. Allzu lang solltest du zwischen den Wechseln aber nicht warten, denn wenn du wirklich jemanden im Netz hast, der mit Golden Tickets angreift, dann willst du dem ja keine Zeit geben, rechtzeitig zu reagieren.

Gruß, Nils

Moin,

vor 33 Minuten schrieb jans1612:

Ich bin verwundert das es bei uns damit Probleme gibt.

deshalb: "Practice. I mean it." 

Wobei das, was du als Probleme nennst, eben wirklich erwartbar ist. Die Annäherung an die 100%, die du genannt hast, musst du über das Design der Umgebung vornehmen, nicht per "Backup", auch nicht per "Restore". Das Restore des AD ist die Kategorie Katastrophenreaktion, da bist du von den 100% immer weit entfernt.

vor 19 Stunden schrieb jans1612:

Einmal habe ich mir beim testen das ganze Active Directory zerschossen.

Das kommt vor - was auch immer das heißt. Deshalb testet man ja. Vermutlich würde man, untersuchte man, was da wirklich passiert ist, feststellen können, was man anders machen muss, damit man sich nicht das AD "zerschießt".

vor 33 Minuten schrieb jans1612:

Das Video ist echt super

Das freut mich, danke. 

Ach, und wo wir dabei sind: Dieser alte Artikel trifft im Kern noch immer zu und beleuchtet, was aus meiner Sicht viel wichtiger ist als ein DC-Restore.

[Video-Tutorial: Active Directory Object Recovery | faq-o-matic.net]
https://www.faq-o-matic.net/2009/09/07/video-tutorial-active-directory-object-recovery/

Gruß, Nils

Moin,

Exchange hat auch viele andere Funktionen zur Automatisierung nicht. Das hat nichts mit schwach zu tun, sondern liegt an der Ausrichtung des Produkts. Wer automatisierte Verarbeitung will, setzt meist ohnehin auf andere, spezialisierte Systeme.

Gruß, Nils

Moin,

egal, was für ein Tool man einsetzt, ich rate dazu, als Basis immer Windows Server Backup zu verwenden und weitere Tools nur als Ergänzung. Grund: Windows Server Backup ist das einzige Werkzeug, das vom Hersteller des Active Directorys direkt unterstützt wird. Sichern des Systemstate von mindestens zwei DCs pro Domäne.

Dass man in einer konkreten Recovery-Situation Aufwand mit der Wiederherstellung hat, sollte man einplanen. Es ist der Normalfall, wenn wirklich ein Fall eintritt, in dem man das AD aus einem Backup wiederherstellen muss. Das wird in solchen Situationen praktisch nie einfach so funktionieren; eine Netzwerkkarte neu einzurichten, fällt da unter "Peanuts". Im übrigen stellt man das AD wieder her, nicht einen DC.

[CDC-Video: Design for Change: Active Directory für das Cloud-Zeitalter | faq-o-matic.net]
https://www.faq-o-matic.net/2019/07/04/cdc-video-design-for-change-active-directory-fr-das-cloud-zeitalter/

(Oder auf Englisch: https://www.youtube.com/watch?v=cTjYMeoN1QI, dort vor allem ab Minute 48:39)

Gruß, Nils

Moin,

wenn ein ping auf den Kurznamen funktionieren soll, muss der anzusprechende Host entweder im selben Subnet sein, man muss WINS nutzen, oder der Client Resolver muss wissen, welche Suffixes er versuchen soll. In sofern: Ja.

Gruß, Nils

Moin,

vor 2 Stunden schrieb Dutch_OnE:

Warum funktioniert NSLOOKUP und Ping dagegen nicht?

weil beide völlig unterschiedlich arbeiten. nslookup fragt die DNS-Datenbank ab, ping nutzt den Client-Resolver, um eine Namensauflösung zu machen. Das sind zwei unterschiedliche Dinge. Im echten Leben etwa: das eine ist eine Melderegisterabfrage, das andere versucht, die Person wirklich anzutreffen.

[Wenn (und warum) nslookup unerwartete Ergebnisse zeigt | faq-o-matic.net]
https://www.faq-o-matic.net/2014/02/12/wenn-und-warum-nslookup-unerwartete-ergebnisse-zeigt/

Gruß, Nils

Moin,

vor 59 Minuten schrieb MrCocktail:

Ganz richtig ist die Aussage, dass sich die verschiedenen Zertifikate nicht unterscheiden auch nicht.

die hat hier auch niemand getätigt. 

Der Punkt, um den es mir ging: Der technische Kern von Zertifikaten ist - mit Ausnahme der jeweiligen Algorithmen für Hash und Verschlüsselung - identisch. Bei einem selbstsignierten Zertifikat passiert in der Verschlüsselung nichts anderes als bei einem DV- oder einem EV-Zertifikat. Auch ein TLS-Zertifikat und eins für Code Signing unterscheiden sich auf dieser Ebene nicht. Nicht einmal Root-Zertifikate und "ausgestellte" Zertifikate sind technisch verschieden. Die Unterschiede liegen nur noch in den Metadaten (z.B. in den Einsatzzwecken der Zertifikate, die willkürlich eingeschränkt sind - im Wesentlichen als Mechanismus, durch den Zertifikatsanbieter Geld verlangen können) und in der Handhabung beim Ausstellen der Zertifikate. Ein kommerzielles Zertifikat ist technisch aber nicht "sicherer" als ein selbstsigniertes, und ein EV-Zertifikat ist nicht sicherer als ein DV-Zertifikat.

Gruß, Nils

Moin,

domain0001, domain0002, domain0003. Oder einen der vielen Generatoren für freie Domänennamen, die kann man dort auch gleich buchen.

Am Ende ist es auch eine Frage der Abwägung. Wenn es um richtig kleine Kunden geht, für die du die Domänen betreibst, dann wäre im Notfall der Aufwand, in eine neu benannte Domäne zu migrieren, vielleicht auch nicht so wild. Oder es ist nicht so wild, einen überholten Namen weiter zu verwenden - denn außer bei der Anmeldung sieht ein User den sowieso nie (und selbst da eigentlich kaum).

Machen wir am besten keine Glaubensfrage draus. Mir ist es auch egal, wenn Kunden meine Empfehlungen nicht befolgen, ist ja ihr Netzwerk, nicht meins.

Gruß, Nils

Moin,

oh, engstirnig würde ich nicht sagen. Aber vielleicht solltest du dich mit dem Gedanken anfreunden, dass wir 2021 haben und 1998 schlappe 23 Jahre her ist.

Gruß, Nils

Moin,

ohne Domäne bedeutet ja sowieso NTLM. Ich würde da also zuerst die Frage stellen, warum man ohne Domäne arbeitet.

Die Idee, sprechende Namen zu verwenden statt IPs, setzt ja vor allem zweierlei um: Zum einen können sich Menschen Namen besser merken als Nummern (zumindest wenn man nicht so idi*tische Namen wählt wie W2K12R201234) und zum anderen bleibt ein Name auch dann gleich, wenn sich mal die IP-Adresse ändert. (Ja, das kommt oft vor, glaubt einem alten Mann mit grauem Haar, der seit über 25 Jahren IT-Dienstleister ist.)

Gruß, Nils