7
Windows XP Registry File -Security- Kein Zugriff mehr, hab ich mich ausgesperrt ?
EDIT: Ich habe weiter unten eine Korrektur angebracht, damit der Sinn der Folgethreads ersichtlich bleibt.
Vor allem dieser Absatz...
Hallo, ich habe eventuell einen bösen Fehler bei der Rechtevergabe für das Registry-File "Security" begangen.
ist Inhaltlich falsch, es war der Key...
Um einige Änderungen vorzunehmen, hatte ich kurzzeitig vom Admin-Account im abgesicherten Modus mit Regedit Vollzugriff für den Root-Schlüssel "Security" eingestellt.
Als ich diesen wieder zurücknehmen wollte, setzte ich zunächst Häckchen bei "Verweigern".
Dann fiel mir ein, das dort vorher gar keine waren, und entfernte sie wieder.
Daraufhin wurden automatisch wieder welche bei "Zulassen" gesetzt, die ich auch entfernte.
Es kam eine Warnung, dass durch diese Einstellung NIEMAND mehr Zugriffsrechte hätte, die ich mit "OK" quittierte. Daraufhin wurden alle Kästchen für die Rechtevergaben grau, und es liess sich gar nichts mehr einstellen.
Ich konnte mir irgendwie nicht vorstellen, dass man den Zugriff auf irgendwas wirklich für JEDEN (auch den Admin) sperren kann, oder liege ich damit falsch und hab nur was übersehen?
Beim nächsten Bootvorgang musste ich dann feststellen, dass auch das System nicht mehr auf "Security" zugreifen kann, es kommt eine Messagebox die meldet, dass lsass.exe keinen Zugriff bekommt (worauf genau steht dort zwar nicht, aber vorher lief alles...), und wenn ich auf "OK" klicke, wird einfach ein Reset ausgelöst.
Habe bisher versucht:
Alle Bootvarianten, die im Menü(F8) angeboten werden zu starten.
Es kommt immer diese Fehlermeldung.
"Security" in diesen -glaub ich- recht bekannten Linux-Offline-Registry&Password-Editor zu laden doch keine Funktionen zur Änderung der Rechte gefunden, ausserdem wird beim Versuch, untergeordnete Schlüssel zu laden, immer angezeigt, das diese nicht vorhanden wären, obgleich sie in der Liste auftauchen.
Ich komme in mein System einfach nicht mehr rein.
Deshalb wollte ich mal vorsichtig fragen, wie dass jetzt wieder rückgängig zu machen ist, bin wirklich aufgeschmissen...
Vor allem dieser Absatz...
Hallo, ich habe eventuell einen bösen Fehler bei der Rechtevergabe für das Registry-File "Security" begangen.
ist Inhaltlich falsch, es war der Key...
Um einige Änderungen vorzunehmen, hatte ich kurzzeitig vom Admin-Account im abgesicherten Modus mit Regedit Vollzugriff für den Root-Schlüssel "Security" eingestellt.
Als ich diesen wieder zurücknehmen wollte, setzte ich zunächst Häckchen bei "Verweigern".
Dann fiel mir ein, das dort vorher gar keine waren, und entfernte sie wieder.
Daraufhin wurden automatisch wieder welche bei "Zulassen" gesetzt, die ich auch entfernte.
Es kam eine Warnung, dass durch diese Einstellung NIEMAND mehr Zugriffsrechte hätte, die ich mit "OK" quittierte. Daraufhin wurden alle Kästchen für die Rechtevergaben grau, und es liess sich gar nichts mehr einstellen.
Ich konnte mir irgendwie nicht vorstellen, dass man den Zugriff auf irgendwas wirklich für JEDEN (auch den Admin) sperren kann, oder liege ich damit falsch und hab nur was übersehen?
Beim nächsten Bootvorgang musste ich dann feststellen, dass auch das System nicht mehr auf "Security" zugreifen kann, es kommt eine Messagebox die meldet, dass lsass.exe keinen Zugriff bekommt (worauf genau steht dort zwar nicht, aber vorher lief alles...), und wenn ich auf "OK" klicke, wird einfach ein Reset ausgelöst.
Habe bisher versucht:
Alle Bootvarianten, die im Menü(F8) angeboten werden zu starten.
Es kommt immer diese Fehlermeldung.
"Security" in diesen -glaub ich- recht bekannten Linux-Offline-Registry&Password-Editor zu laden doch keine Funktionen zur Änderung der Rechte gefunden, ausserdem wird beim Versuch, untergeordnete Schlüssel zu laden, immer angezeigt, das diese nicht vorhanden wären, obgleich sie in der Liste auftauchen.
Ich komme in mein System einfach nicht mehr rein.
Deshalb wollte ich mal vorsichtig fragen, wie dass jetzt wieder rückgängig zu machen ist, bin wirklich aufgeschmissen...
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 68516
Url: https://administrator.de/contentid/68516
Printed on: April 19, 2024 at 08:04 o'clock
7 Comments
Latest comment
schon versucht, unter Erweitert den Besitz zu übernehmen, und dann die Rechte setzen?
Achtung, nach Besitzübernahme Eigenschaften schliessen, neu öffnen und dann...
Achtung, nach Besitzübernahme Eigenschaften schliessen, neu öffnen und dann...
tjo da hast du dich sauber rausgeschmissen 
boote mit der windows cd und gehe in die konsole.
gehe ins verzeichnis c:\windows\system32\config und benenne die datei security in security.old um.
dann kopierst du die datei "security" von c:\windows\repair nach c:\windows\system32\config
dann sollte der zugriff wieder klappen.
boote mit der windows cd und gehe in die konsole.
gehe ins verzeichnis c:\windows\system32\config und benenne die datei security in security.old um.
dann kopierst du die datei "security" von c:\windows\repair nach c:\windows\system32\config
dann sollte der zugriff wieder klappen.
Hallo,
Danke euch für die schnellen Reaktionen!
Da ich im Moment von meinem Rechner aus nicht schreiben kann,
hat es bei mir dann etwas gedauert...
@smerlin
Im Moment fährt das System leider nicht hoch, und ich weiss nicht, wie oder ob ich so überhaupt MS Regedit starten kann.
In dem Linux-Tool scheint es keine Funktionen für Besitzübername oder Rechtevergaben zu geben.
Oder anders gesagt: Habe keine gefunden.
@Kosh
Ok, die Datei "Security" habe ich nun gesichert und mit der aus dem Repair-Verzeichnis ersetzt.
Leider fährt das System immer noch nicht hoch.
Die ursprüngliche Fehlermeldung ist zwar verschwunden, wurde jedoch von dieser abgelöst:
lsass.exe:
"Bei dem Versuch, ein Kennwort zu aktualisieren, zeigt dieser Rückgabestatus an,
dass der als Kennwort angegebene Wert ungültig ist".
Diesmal erfolgt der Reset von alleine, etwa 1 Sekunde, nachdem die Meldung erscheint.
Im Abgesicherten Modus das gleiche.
Was auch immer diese Meldung jetzt genau bedeutet, Kennwörter hatte ich definitiv für keine der aktiven Benutzerkonten (2 Stück, Admin [abgesichert] und Hauptbenutzer [normaler Start] ) gesetzt.
Danke euch für die schnellen Reaktionen!
Da ich im Moment von meinem Rechner aus nicht schreiben kann,
hat es bei mir dann etwas gedauert...
@smerlin
Im Moment fährt das System leider nicht hoch, und ich weiss nicht, wie oder ob ich so überhaupt MS Regedit starten kann.
In dem Linux-Tool scheint es keine Funktionen für Besitzübername oder Rechtevergaben zu geben.
Oder anders gesagt: Habe keine gefunden.
@Kosh
Ok, die Datei "Security" habe ich nun gesichert und mit der aus dem Repair-Verzeichnis ersetzt.
Leider fährt das System immer noch nicht hoch.
Die ursprüngliche Fehlermeldung ist zwar verschwunden, wurde jedoch von dieser abgelöst:
lsass.exe:
"Bei dem Versuch, ein Kennwort zu aktualisieren, zeigt dieser Rückgabestatus an,
dass der als Kennwort angegebene Wert ungültig ist".
Diesmal erfolgt der Reset von alleine, etwa 1 Sekunde, nachdem die Meldung erscheint.
Im Abgesicherten Modus das gleiche.
Was auch immer diese Meldung jetzt genau bedeutet, Kennwörter hatte ich definitiv für keine der aktiven Benutzerkonten (2 Stück, Admin [abgesichert] und Hauptbenutzer [normaler Start] ) gesetzt.
alles klar.
dann mache dasselbe noch mal mit der datei "SAM" (von repair -> config).
dann sollte es klappen.
es kann allerdings sein etwaige angelegte benutzer dann nicht mehr vorhanden sind.
wenns das auch noch nicht war, dann auch noch "SYSTEM" umkopieren.
vergiss nicht die aktuellen reg-hives in " .old" umzubenennen.
wenn du dich dann wieder anmelden kannst schauen wir weiter.
dann mache dasselbe noch mal mit der datei "SAM" (von repair -> config).
dann sollte es klappen.
es kann allerdings sein etwaige angelegte benutzer dann nicht mehr vorhanden sind.
wenns das auch noch nicht war, dann auch noch "SYSTEM" umkopieren.
vergiss nicht die aktuellen reg-hives in " .old" umzubenennen.
wenn du dich dann wieder anmelden kannst schauen wir weiter.
Habe ich gemacht, genauer gesagt dann mit beiden Dateien, so fährt er endlich wieder hoch!
Das Hauptbenutzerkonto ist noch intakt und ich konnte erstmal alle geschützten Dokumente sichern.
Danke! Damit war für mich schonmal einiges gerettet
Hatte gestern vorher noch was ausprobiert, und auch wenn ohne Erfolg,
stünde damit seit dem noch eine parallele XP-Installation mit Zugriffsmöglichkeit auf die Systemdateien der betroffenen Installation zur Verfügung.
Ok, kurz gesagt, ich kann mich Anmelden, das System läuft bis auf einige Treiber und Dienste, Backups der reg-hives sind vorhanden, wie soll ich jetzt weiter vorgehen?
Das Hauptbenutzerkonto ist noch intakt und ich konnte erstmal alle geschützten Dokumente sichern.
Danke! Damit war für mich schonmal einiges gerettet
Hatte gestern vorher noch was ausprobiert, und auch wenn ohne Erfolg,
stünde damit seit dem noch eine parallele XP-Installation mit Zugriffsmöglichkeit auf die Systemdateien der betroffenen Installation zur Verfügung.
Ok, kurz gesagt, ich kann mich Anmelden, das System läuft bis auf einige Treiber und Dienste, Backups der reg-hives sind vorhanden, wie soll ich jetzt weiter vorgehen?
soweit ich dich verstanden habe hast du die berechtigungen direkt auf dem file "security" gesetzt.
das machen wir nun rückgängig.
mach den explorer auf, und setze die berechtigungen von "security.old" genau gleich wie sie bei der datei "security" gesetzt sind.
dies musst du allerdings als administrator machen.
wenn er dich die rechte nicht setzen lässt, musst du noch unter "sicherheit"->"erweitert"->"Besitzer" den besitz der datei übernehmen.
wenn du alles wieder geradegebogen hast, dann starte xp wieder von der cd, und benenne die zuvor in ".old" umbenannten regfiles wieder zurück.
nach einem neustart sollte dein system wieder wie gewohnt laufen.
das machen wir nun rückgängig.
mach den explorer auf, und setze die berechtigungen von "security.old" genau gleich wie sie bei der datei "security" gesetzt sind.
dies musst du allerdings als administrator machen.
wenn er dich die rechte nicht setzen lässt, musst du noch unter "sicherheit"->"erweitert"->"Besitzer" den besitz der datei übernehmen.
wenn du alles wieder geradegebogen hast, dann starte xp wieder von der cd, und benenne die zuvor in ".old" umbenannten regfiles wieder zurück.
nach einem neustart sollte dein system wieder wie gewohnt laufen.
Ich möchte mich entschuldigen, und hier eine Korrektur anbringen, nach einer Reproduktion sollte der Sachverhalt jetzt etwas besser ersichtlich werden, ich hatte alles aus dem Gedächtnis geschrieben und sorgfältig durcheinandergebracht...
Ich hatte in Regedit die Rechte für HKLM/Security geändert und beim Versuch, sie später wieder zurückzusetzen durch unüberlegtes Herumklicken an den Haken für
die Rechtevergaben, ohne es zu bemerken, alle Benutzerobjekte entfernt.
Nachdem ich den Sicherheitsdialog mit Ok geschlossen und versucht hatte, den Browser zu starten, um eine Lösung dafür zu suchen, bekam ich keine Verbindung mehr und es liessen sich danach auch keine Sicherheitseinstellungen mehr aufrufen, weder in Regedit, noch in Dateieigenschaften.
Es kam statt der Dialogfenster nur die Fehlermeldung, dass der Computer keiner eindeutigen Domäne mehr zugeordnet werden könne.
Ich veranlasste dann einen Neustart...
Nun ist es eloganter beschrieben, wenn auch auch noch unangenehmer für mich zu lesen
Ab da sollte es hinkommen.
Ich hatte dann versucht, den letzten Tip einfach so umzusetzen:
Hab die Rechtevergaben am Root-Key in der security.old mit dem aktiven hive als Vorlage wieder gesetzt, was problemlos möglich war, sofern ich das File als Struktur lud und dabei umbenannte.
Trotzdem kam beim Booten dann dies:
lsass.exe
Die Sicherheitskontenverwaltung konnte nicht geladen werden, da Folgender Fehler aufgetreten ist: Zugriff verweigert. Fehlerstatus 0x00002222
Empfehlung in dieser Box dann: Abgesichert Starten, Protokoll lesen.
Kam auch beim abgesicherten, protokollierten Start, und die Bootlog.txt, sofern damit gemeint, war danach unlesbar, ASCII war das jedenfalls nicht...
Die zwei .old Files hatte ich über die "Repairs" kopiert und das von Regedit neu ins Config-Verzeichnis geschriebene File umbenannt.
Statt mich weiter zu wundern, wollte ich nochmal fragen, ob unter diesen Voraussetzungen noch etwas zu machen ist, wegen dem ursprünglichen Text nochmals sorry, der Tag war eben meiner nicht....
Ich hatte in Regedit die Rechte für HKLM/Security geändert und beim Versuch, sie später wieder zurückzusetzen durch unüberlegtes Herumklicken an den Haken für
die Rechtevergaben, ohne es zu bemerken, alle Benutzerobjekte entfernt.
Nachdem ich den Sicherheitsdialog mit Ok geschlossen und versucht hatte, den Browser zu starten, um eine Lösung dafür zu suchen, bekam ich keine Verbindung mehr und es liessen sich danach auch keine Sicherheitseinstellungen mehr aufrufen, weder in Regedit, noch in Dateieigenschaften.
Es kam statt der Dialogfenster nur die Fehlermeldung, dass der Computer keiner eindeutigen Domäne mehr zugeordnet werden könne.
Ich veranlasste dann einen Neustart...
Nun ist es eloganter beschrieben, wenn auch auch noch unangenehmer für mich zu lesen
Ab da sollte es hinkommen.
Ich hatte dann versucht, den letzten Tip einfach so umzusetzen:
Hab die Rechtevergaben am Root-Key in der security.old mit dem aktiven hive als Vorlage wieder gesetzt, was problemlos möglich war, sofern ich das File als Struktur lud und dabei umbenannte.
Trotzdem kam beim Booten dann dies:
lsass.exe
Die Sicherheitskontenverwaltung konnte nicht geladen werden, da Folgender Fehler aufgetreten ist: Zugriff verweigert. Fehlerstatus 0x00002222
Empfehlung in dieser Box dann: Abgesichert Starten, Protokoll lesen.
Kam auch beim abgesicherten, protokollierten Start, und die Bootlog.txt, sofern damit gemeint, war danach unlesbar, ASCII war das jedenfalls nicht...
Die zwei .old Files hatte ich über die "Repairs" kopiert und das von Regedit neu ins Config-Verzeichnis geschriebene File umbenannt.
Statt mich weiter zu wundern, wollte ich nochmal fragen, ob unter diesen Voraussetzungen noch etwas zu machen ist, wegen dem ursprünglichen Text nochmals sorry, der Tag war eben meiner nicht....
