8
Mit secpol.msc eine falsche policy angepasst und ausgesperrt
Mithilfe des secpol.msc (Lokale Sicherheitsrichtline) unter dem Eintrag "Lokalen Richtlinien" und den "Sicherheitsoptionen" habe ich ausversehen eine falsche Policy verändert und zwar diese hier: "Interaktive Anmeldung: Windows Hello for Business oder Smartcard erforderlich" (eigentlich wollte ich die Einstellung für "Zuletzt angemeldeten Benutzer nicht anzeigen" verändern, aber da hatte ich mich wohl um eine Zeile vertan.) Seitdem kann sich keiner mehr lokal an diesem Windows 10 20H2 Rechner anmelden.
Gibt es eine Möglichkeit via Konsole, Regedit, etc. diese Einstellung rückgängig zu machen, bzw. alle policys auf "default zurückzustellen.
Vielen Dank Mathias
Gibt es eine Möglichkeit via Konsole, Regedit, etc. diese Einstellung rückgängig zu machen, bzw. alle policys auf "default zurückzustellen.
Vielen Dank Mathias
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: 667002
Url: https://administrator.de/contentid/667002
Printed on: April 19, 2024 at 10:04 o'clock
8 Comments
Latest comment
Mit Offline-Medium booten z.B. mit dem Installationsmediumoder nem Knoppix oder anderen Live-Systemen und dann im Ordner der Windows Installation das registry pol File im Ordner \windows\system32\GroupPolicy\Machine löschen
Zusätzlich unter windows\security\Database das File secedit.sdb
https://windowsreport.com/full-fix-corrupt-local-group-policy-on-windows ...
Gruß w.
Zusätzlich unter windows\security\Database das File secedit.sdb
https://windowsreport.com/full-fix-corrupt-local-group-policy-on-windows ...
Gruß w.
Hab das hier grade gelesen und eine andere Idee gehabt und würde gerne wissen ob meine IDee auch geklappt hätte. Vielleicht weiß das ja jemand.
1. hätte man die beiden DAteien nicht einfach per Skript beim Systemstart löschen können?
2. Die Änderung per Secpol.msc macht ja unterm strich auch nichts anderes als Registry-Keys zu steuern. Hätte man die Registry KEys nicht einfach ebenfalls per GPO entsprechen setzen können?
Wenn das ging, wäre es für mich deutlich einfacher, falls mir das mal passiert als erstmal Knoppix zu organisieren.
Gruß
Doskias
1. hätte man die beiden DAteien nicht einfach per Skript beim Systemstart löschen können?
2. Die Änderung per Secpol.msc macht ja unterm strich auch nichts anderes als Registry-Keys zu steuern. Hätte man die Registry KEys nicht einfach ebenfalls per GPO entsprechen setzen können?
Wenn das ging, wäre es für mich deutlich einfacher, falls mir das mal passiert als erstmal Knoppix zu organisieren.
Gruß
Doskias
Zitat von @Doskias:
1. hätte man die beiden DAteien nicht einfach per Skript beim Systemstart löschen können?
Wie wenn du dich nicht anmelden kannst 🙃.1. hätte man die beiden DAteien nicht einfach per Skript beim Systemstart löschen können?
Außer man hat vorgesorgt und noch einen Remote-Zugang.
2. Die Änderung per Secpol.msc macht ja unterm strich auch nichts anderes als Registry-Keys zu steuern.
Nein, indem Fall nicht, die meisten local security policy settings landen nicht in der Registry sondern in einer File DB (s.o.).Hätte man die Registry KEys nicht einfach ebenfalls per GPO entsprechen setzen können?
Wenn das Teil denn per GPO gemanaged wäre, aber davon schreibt der TO ja nichts. Denke das wüsste er dann selbst wenn er ein AD betreiben würde.Zitat von @148121:
Außer man hat vorgesorgt und noch einen Remote-Zugang.
Zitat von @Doskias:
1. hätte man die beiden DAteien nicht einfach per Skript beim Systemstart löschen können?
Wie wenn du dich nicht anmelden kannst 🙃.1. hätte man die beiden DAteien nicht einfach per Skript beim Systemstart löschen können?
Außer man hat vorgesorgt und noch einen Remote-Zugang.
Per GPO sofortigen Task als System-Benutzer oder geplanter Task beim Systemstart, nicht bei der Anmeldung. Beim Systemstart wird dann vor der Anmeldung ausgeführt.
2. Die Änderung per Secpol.msc macht ja unterm strich auch nichts anderes als Registry-Keys zu steuern.
Nein, indem Fall nicht, die meisten local security policy settings landen nicht in der Registry sondern in einer File DB (s.o.).Hätte man die Registry KEys nicht einfach ebenfalls per GPO entsprechen setzen können?
Wenn das Teil denn per GPO gemanaged wäre, aber davon schreibt der TO ja nichts. Denke das wüsste er dann selbst wenn er ein AD betreiben würde.Schönen Sonntag noch
Zitat von @Doskias:
Per GPO sofortigen Task als System-Benutzer oder geplanter Task beim Systemstart, nicht bei der Anmeldung. Beim Systemstart wird dann vor der Anmeldung ausgeführt.
Joa, klar , da der TO hier aber lokal am Client rumfutelt denke ich ist ein AD wohl in weiter Ferne 😜Per GPO sofortigen Task als System-Benutzer oder geplanter Task beim Systemstart, nicht bei der Anmeldung. Beim Systemstart wird dann vor der Anmeldung ausgeführt.
Aber für den TO hat sich das hier ja anscheinend eh schon erledigt, kommt ja kein Feedback mehr.
Zitat von @148121:
Aber für den TO hat sich das hier ja anscheinend eh schon erledigt, kommt ja kein Feedback mehr.
Zitat von @Doskias:
Per GPO sofortigen Task als System-Benutzer oder geplanter Task beim Systemstart, nicht bei der Anmeldung. Beim Systemstart wird dann vor der Anmeldung ausgeführt.
Joa, klar , da der TO hier aber lokal am Client rumfutelt denke ich ist ein AD wohl in weiter Ferne 😜Per GPO sofortigen Task als System-Benutzer oder geplanter Task beim Systemstart, nicht bei der Anmeldung. Beim Systemstart wird dann vor der Anmeldung ausgeführt.
Aber für den TO hat sich das hier ja anscheinend eh schon erledigt, kommt ja kein Feedback mehr.
Stimmt. Mir ging es aber auch darum das Gesamtbild zu klären, da er ja auch schreibt
Gibt es eine Möglichkeit via Konsole, Regedit, etc. diese Einstellung rückgängig zu machen
GPO ist ja auch eine Möglichkeit und (kenne ich persönlich) manche Leute richten trotz GPO an einzelnen Rechner per SECPOl.MSC Dinge ein, wenn sie es nur auf einem Rechner haben wollen, weil Sie Einzelplatz.Einstellungen nicht in den GPOs sehen wollen. Für beide Seite gibt es argumente 
Und da es sich offenbar um mehrere User handelt, die sich nicht mehr lokal anmelden können, wäre es Zeit über eine Domäne nachzudenken, falls es wirklich keine gibt.
Hallo zusammen, danke für das Feedback! Das Problem ist/war, dass ich weder einen remote Zugang/Konto noch ein AD zur Verfügung hatte um mich irgendwie an das lokale Win10 20H2 System anmelden zu können. Die Sicherheitsrichtlinien sind, soweit ich das in Erfahrung bringen konnte, nicht per File System Zugriff und entsprechender Registry files/settings zu "umgehen".
Ich habe das System mittlerweile in eine VM geschoben und den Rechner neu aufgesetzt... An der VM kann ich dann weiter "rumdoktorn" und vielleicht noch ein paar neue Erkentnisse gewinnen.
Ich habe das System mittlerweile in eine VM geschoben und den Rechner neu aufgesetzt... An der VM kann ich dann weiter "rumdoktorn" und vielleicht noch ein paar neue Erkentnisse gewinnen.
Die Sicherheitsrichtlinien sind, soweit ich das in Erfahrung bringen konnte, nicht per File System Zugriff und entsprechender Registry files/settings zu "umgehen".
Doch, s. oben 
.
