NilsK

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, 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, 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. 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. 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, 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. 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". 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, 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, 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

Moin, das ist ja in dem ganz oben zitierten Artikel recht ausführlich diskutiert. Rein technisch spricht überhaupt nichts dagegen. Organisatorisch schon - das ist ein Fazit, das man nach über 20 Jahren AD sehr eindeutig ziehen kann. Am Ende muss sich das jede*r selbst überlegen. Empfehlungen sind nur Empfehlungen. Man kann es auch so machen wie die c't, die 20 Jahre Erfahrung und Diskussionen mit hunderten Kunden, die Millionen Euro unnötig vergeudet haben, um ungünstige Namenswahlen zu überwinden, als "Glaubensfrage" abtut (sie kommt dabei aber zum selben Ergebnis). Da bin ich dann raus, es sind ja nicht meine Netzwerke. Eher profitiere ich davon, weil einige -zigtausend von den Millionen Euro an mich als Dienstleister gegangen sind, damit ich dabei helfe, solche vermeidbaren Probleme zu überwinden. Gruß, Nils

Moin, ich tippe mal kühn auf das RAM im Host. Gruß, Nils

Moin, Azure AD ist kein AD. Das ist ein separater Dienst, der in seinem Namen zwar auf AD Bezug nimmt, technisch aber wenig damit zu tun hat. Dein Failover-Szenario ist keins, weil es so nicht funktioniert. Azure AD ist die Benutzerdatenbank für einen Azure-Tenant. Es ist funktional nicht vergleichbar mit dem AD. Nicht einmal Azure AD Domain Services würde das tun, was du vermutest. Eigentlich trifft keiner der von dir vermuteten Vorteile zu. Gruß, Nils

Moin, es gibt dort jetzt einen Link mit dem jeweils aktuellen Stand der Agenda. Bislang noch ohne Zeiten und unvollständig, aber immerhin. https://cim-lingen.de/#Agenda Gruß, Nils