NilsK

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

Moin, Geschieht das immer zur selben Uhrzeit? Gruß, Nils

Moin, das Dokument, das ihr da bekommen habt, ist nicht der Partnervertrag. Es ist nur das MPN Agreement, das einem bestehenden Microsoft-Partner Rechte für den Zugriff auf das Microsoft Partner Network einräumt. Also, wenn euch das als Partnervertrag vorgelegt wurde, der angeblich belege, dass dieses halbseidene Angebot rechtens sei, dann reden wir hier schon ernsthaft über Betrug. Arnds Vorschlag mit Hof und Wüste ist da noch zurückhaltend ... Gruß, Nils

Moin, Nobby, bitte nicht immer nach Franz rufen. Schon gar nicht, wenn du nicht mal die Frage gelesen hast. Was dir, @ottersberg, da angeboten wurde, ist selbstverständlich nicht vorgesehen. So, wie du es schilderst, fällt es durchaus in die Kategorie Betrug. Das Partnermodell ist für Handelspartner von Microsoft da, die die Voraussetzungen dafür natürlich auch selbst erfüllen müssen. Gruß, Nils

Moin, Das ist simpel. LastLogonTimestamp ist genau dafür da. Nimm dir OldCmp von joeware.net, damit kriegst du die Auswertung über alle Accounts. Davon filterst du dann die ohne Mail-Adresse raus. Edit: OldCmp enthält nicht das Feld Mail. Das könnte man durch einen zweiten Export in Excel dazubasteln. Oder man nimmt noch AdFind vom selben Hersteller dazu, füttert es mit dem Filter, den OldCmp erzeugt hat und fügt dort noch "!(mail=*)" hinzu - also den Ausdruck für "Feld mail enthält keinen Wert". Beispiel: OldCmp hat mir gerade den Filter erzeugt "(&(samaccounttype=805306368)(|(lastLogonTimestamp<=132655412548630000)(!(lastLogonTimestamp=*))))" - den zeigt es netterweise im HTML-Report an, dort also kopieren ergänzen um Mail, also: "(&(samaccounttype=805306368)(|(lastLogonTimestamp<=132655412548630000)(!(lastLogonTimestamp=*)))!(mail=*))" Diesen Filter an AdFind verfüttern, fertig Ist jetzt ungetestet, sollte aber so gehen; vielleicht noch etwas rumspielen, kann sein, dass die Syntax noch nicht ganz passt Wichtig: Nicht den Filter aus diesem Beispiel kopieren, der bezieht sich auf den Timestamp von gerade eben. Gruß, Nils

Moin, für mich klingt das jetzt auch sehr doppelt. Wenn der Hosteintrag auf die Ziel-IP verweist, braucht es ja keinen gleichnamigen Alias mehr. Oder verstehe ich da was miss? Weitergehend könnte man jetzt auch mal klären, was das Ganze überhaupt soll. Welches Problem soll durch das Konstrukt gelöst werden? Warum greift man nicht einfach direkt auf die Zieladresse zu? Gruß, Nils

Moin, gut. Wenn du jetzt noch Fragen hast, dann bitte konkret fragen. Gruß, Nils

Moin, gut, dann ist deine Frage also, wie man auf dem internen DNS einen CNAME einträgt? Dann müssten wir jetzt noch wissen, was denn das für ein DNS-Server ist. Ferner ist es untypisch, dass ein Hostname "Kundenportal-qat-local.de" lautet - das ist erstmal ein Domänenname. Geht, wäre aber ungewöhnlich. Üblich wäre eher "testportal.kunde.de". Solltest du also noch mal prüfen. Ist es ein Windows-Server? Dann brauchst du dort eine DNS-Zone "Kundenportal-qat-local.de" und eine DNS-Zone "Produktivportal-local.de". In jeder dieser Zonen legst du dann einen neuen CNAME-Eintrag ohne Namen an, der auf den gewünschten Host verweist. (Dies wäre der untypische Fall. Im Normalfall "testportal.kunde.de" würde man in der DNS-Zone "kunde.de" den CNAME "testportal" anlegen, der auf den eigentlichen Hostnamen verweist.) Gruß, Nils

Moin, <ot>oh Mann. Und das alles für Druckdienste, die schon Ende der Neunziger nicht konkurrenzfähig waren und sich seitdem (auch funktional) praktisch nicht weiterentwickelt haben.</ot> Gruß, Nils