NilsK

Moin,

Danke für die Info. Wenn das so ist, wie du beschreibst, dann würde ich schleunigst alle VMs, die auf dem "alten" Host laufen, dort weg migrieren. Es kann gut sein, dass das Dateisystem dort kaputt ist.

Und nun hoffe ich, dass du nicht nur "Rollen überträgst", denn das ist das geringste Problem, sondern dein AD ausreichend betriebssicher aufbaust.

Gruß, Nils

Moin,

also, da wäre mein Optimismus begrenzt. Wer das braucht, sollte sich lieber die PowerShell ansehen.

Gruß, Nils

Moin,

wenn man wüsste, welche DLL dafür zuständig ist und wie die angesprochen wird, könnte man die evtl. einbinden. Wäre aber ohne offiziellen Support ein kruder Hack, den man bei einem Sicherheitsthema eher nicht haben möchte.

Gruß, Nils

Moin,

vor 14 Minuten schrieb possum72:

Es wurde aber KEINE AD-Sicherung durchgeführt.

das ist schlecht. Warum macht man sowas nicht?

vor 15 Minuten schrieb possum72:

Ein Exchange ist ebenfalls vorhanden. Ca. 15 User.

Dann ist der Schaden zumindest überschaubar. Was ich nun versuchen würde:

• für einen endlichen Zeitraum versuchen, die kaputte VM wieder zum Laufen zu bringen.
• falls der DC so wieder läuft:
  • einen weiteren DC einrichten auf Basis einer neuen, sauber installierten VM
  • falls dem wiederbelebten DC zu trauen ist: beide DCs weiter laufen lassen. Bei 15 Usern sind 2 DCs nicht zu viel, wie du gerade deutlich spürst.
  • falls ihm nicht zu trauen ist: noch einen weiteren DC neu installieren und den kaputten runterstufen und aus dem Netz nehmen
• falls er nicht wieder läuft
  • die 15 User informieren, dass die nächsten Tage etwas unschön werden
  • die Domäne mit einem neuen DC neu aufsetzen, dann direkt einen zweiten neuen DC dazu installieren
  • Exchange neu einrichten und die Mailboxen aus dem Exchange-Backup wiederherstellen
  • alle Workstations und Server in die neue Domäne aufnehmen
  • alle Berechtigungen für die neuen User und Gruppen setzen

und dass du unabhängig davon, welcher Weg funktioniert hat, künftig für ein eigenes, separates AD-Backup sorgst, dürfte nun auf der Hand liegen. Das geht mit Bordmitteln (Windows Server Backup) in ausreichender Qualität. Sollte künftig ein anderes Backup-Tool zum Einsatz kommen, dann sichert man das AD trotzdem zusätzlich immer mit Windows Server Backup, weil dies die einzige Methode ist, die Microsoft von vorn bis hinten supportet - das kann im Ernstfall durchaus hilfreich sein.

Gruß, Nils

PS. möglicherweise kommt dies auch in meiner Session auf der Experts Live Germany nächste Woche vor. 

Moin,

bitte mal langsam und der Reihe nach.

Du hast also eine kaputte VM, die der einzige DC einer Domäne war. Handelt es sich um ein Testnetzwerk oder um Produktion? Falls Produktion, von wie vielen Usern reden wir in etwa?

Das Wichtige beim AD-Recovery sind nicht die FSMO-Rollen, sondern die AD-Objekte. Die könntest du aus einem AD-Backup wiederherstellen, wenn dieses ordentlich erzeugt wurde. Du sprichst von 7 vorliegenden Backups - wie wurden diese Backups erzeugt?

Gruß, Nils

Moin,

Prima, danke für die Rückmeldung.

Gruß, Nils

Moin,

nein, die 29 Tage sind nicht ausschlaggebend. Das ist am Ende eure Einschätzung, wann ein Snapshot für euch wertlos oder sogar gefährlich wird. Es gibt auch gute Gründe, Snapshots gar nicht aufzubewahren bzw. gar keine zu erzeugen. (Genau betrachtet, gibt es mehr Gründe, keine Snapshots vorzuhalten, als Gründe, das zu tun.)

Die 30 Tage, die ich selbst oben nannte, sind das Intervall, in dem das AD neue Computerkennwörter aushandelt. Das ist aber eher eine maximale Zeitspanne, nach der das Kennwort garantiert geändert ist. Wenn die Änderung z.B. gestern erfolgt ist, dann ist der Snapshot von vorgestern schon so alt, dass die VM in dem Zustand nicht auf das AD zugreifen kann. Man sieht "von außen" nicht, wann der Kennwortwechsel erfolgt ist - kann man zwar rauskriegen, ist operativ aber auch unnötig.

Gruß, Nils

Moin,

Und es gibt kein aktuelles Backup, oder was willst du mit deiner Beschreibung sonst aussagen?

Wir sind hier ein Community-Forum, kein kommerzieller Support. Daher können wir nur das leisten, was wir hier eben tun. Wenn du mehr brauchst, ist das legitim, aber nicht als Anspruch uns gegenüber. Professioneller Support kostet Geld, das ist nun mal so 

Gruß, Nils

Moin,

wenn man eine VM, die Mitglied der Domäne ist, auf einen Snapshot zurücksetzt, der älter ist als 30 Tage, dann ist der Fehler mit der fehlenden Vertrauensstellung völlig normal. In dem Fall hatte das Windows in der VM (als es noch normal lief) turnusgemäß sein Domänenkennwort mit dem AD neu ausgehandelt. Der alte VM-Zustand hat natürlich nur ein altes Kennwort und kann sich deshalb nicht gegen die Domäne authentifizieren.

Dass das bei den Notebooks, über die wir hier ja auch schon ausführlich diskutiert haben, auch so ist, halte ich für wenig wahrscheinlich. Daher dürften die Ursachen unterschiedlich sein.

Wie es nun dazu kam, dass diese eine VM auf den Snapshot zurückgesetzt wurde, lässt sich hier nicht beurteilen. Angesichts dessen, was du beschreibst, halte ich die Fehlbedienung durch jemanden, der administrativen Zugriff auf die Umgebung hat, für die wahrscheinlichste Vermutung. "Kann gar nicht sein" ist oft der große Bruder von "ich hab nichts gemacht".

Hackerangriffe kann man zwar nie ausschließen, aber ein Hacker hätte sicher Besseres zu tun.

Problematisch ist, dass der Kunde nun anscheinend auf dem uralten Stand weiterarbeitet. Warum habt ihr dort nicht das aktuellste Backup der VM oder der Applikation wiederhergestellt?

Gruß, Nils

Moin,

Da es genau solche Effekte erzeugen kann: hast du das mit der Zeit geprüft? "Vom Server" ist immer so eine Sache, das kommt gleich nach "ich hab nichts gemacht". 

Gruß, Nils

Moin,

Ja, das ist auch so, prinzipbedingt. Allenfalls könnte man nach einem der wenigen seriösen Tests solcher Folien Ausschau halten (in der c't hatten sie mal einen, meine ich, ist aber schon einige Zeit her), aber die Unterschiede der Helligkeit dürften gering sein. Eher trennt sich die Spreu vom Weizen nach der Schutzwirkung.

Gruß, Nils

Moin,

wir sind ein deutschsprachiges Forum. Lass uns dabei bleiben, das macht es für alle einfacher.

Um einzusteigen:

• was hat sich zwischen vorher und jetzt an dem System geändert?
• was sagen die Eventlogs auf dem DC und den beteiligten Clients?
• nur vorsichtshalber: schon neu gestartet?
• und mal ins Blaue: die Systemzeiten laufen synchron?

Gruß, Nils

Moin,

vor 2 Stunden schrieb Squire:

Also mit max 2 Tagen DL bist Du durch

ja, aber. 

Zur Ehrenrettung der Dienstleister: da man in der Praxis häufig auf Unwägbarkeiten und "historisch gewachsene"(TM) Umstände trifft, ist das mit "max" immer so eine Sache. Als Orientierung mag das aber taugen.

Gruß, Nils

Moin,

weil ich es grad gestern selbst genutzt hab - da fiel mir ein, dass es hier passen könnte: In den PowerToys gibt es ein Tool namens "Awake", mit dem man das erreichen kann, was du suchst (wenn ich nicht irre).

Gruß, Nils

Moin,

na, das ist doch gut.

Die Idee hinter einem Offline Join ist, dass es leichter möglich sein soll, einen Client in die Domäne aufzunehmen, der keinen regelmäßigen Netzwerkkontakt zum AD hat. So erspart man sich dann, das Gerät mühselig hin- und herzuschicken.

Gruß, Nils

Moin,

nur kurz zur Einordnung: Martin hat natürlich Recht, aber das Szenario, das du beschrieben hast, passt nicht recht dazu. Da du das lokale Adminkennwort nicht kennst, musst du die Workstation ohnehin neu installieren. Und es besteht ja Netzwerkkontakt zum AD, also brauchst du auch keinen Offline Join.

Gruß, Nils

Moin,

zumal das Ganze wie im Beispielcode nur funktioniert, wenn der User lokaler Admin ist und die UAC abgeschaltet ist. Sonst dürfte C$ gar nicht zugreifbar sein. Ich halte das für überhaupt keine gute Idee.

Gruß, Nils

Moin,

vor 6 Minuten schrieb hanspeter5656:

Aber am Konzept hat sich ja grundlegend nicht allzu viel verändert

je nach Perspektive stimmt das tatsächlich. Erstaunlich viele Grundlagen sind noch so wie "früher". Aber nicht alle. 

Gruß, Nils

Moin,

Am 24.5.2023 um 01:41 schrieb gunter1:

ich habe folgendes Problem und such dafür Hilfe.

was ist denn genau das Problem? Dass da ein rotes Kreuz angezeigt wird? Oder funktioniert auch irgendwas nicht, was funktionieren sollte?

Gruß, Nils

Moin,

ich meine, dass Signaturen erst möglich sind, wenn man eine gewisse Anzahl an Beiträgen überschritten hat. Aber so viel Aufwand ist es ja auch nicht, freundliche Grüße zu schreiben. Ich habe das bei aktuell 16.654 Beiträgen manuell gemacht.

Gruß, Nils

Moin,

ohne dir zu nahe treten zu wollen, aber vermutlich wäre es sinnvoll, jemanden hinzuzuziehen, der sich mit der Domänenverwaltung auskennt. Du hantierst hier an einer Stelle, die über die Sicherheit des Netzwerks entscheiden kann und damit auch - um es deutlich auszudrücken - über den Fortbestand des Unternehmens.

Gruß, Nils

Moin,

was du hier machst und zeigst, ist das Vordefinieren eines Computerkontos im AD. Das ist ein optionaler Schritt. Der eigentlich wichtige Schritt besteht darin, dass man den Rechner in die Domäne aufnimmt. Dazu muss man sich dort lokal mit Administratorrechten anmelden und dann den Computer ausdrücklich in die Domäne aufnehmen (am Einfachsten: im Suchfeld nach dem Wort "Domäne" suchen, dann taucht dort die passende Funktion auf). Man kann das bei einer automatisierten Installation auch über ein Skript machen.

Wenn man das Computerkonto im AD nicht vorher anlegt, dann wird automatisch eins erzeugt, standardmäßig im Container CN=Computers.

Gruß, Nils

Moin,

ich habe (leider) noch nicht selbst damit gearbeitet, aber dies hier sieht aus, als würde es zu deiner Frage passen:

[Prepare people to use Windows Hello | Microsoft Learn]
https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use
 

Gruß, Nils

Moin,

ich sag es jetzt mal noch allgemeiner altersweiser: wie immer in organisatorischen Fragen sollte man sich nicht der Illusion hingeben, dass man den einen Weg findet, der für alle Zeiten passt.

Gruß, Nils

Moin,

und ich verrate nicht, wo die Mailboxen vorher lagen.

Gruß, Nils