Windows Server 2016 Admin durch GPO ausgesperrt,

[Borstel86]

Hallo liebe Community,

mir ist leider etwas sehr Dummes passiert und ich sitze jetzt relativ ratlos da. Einfach aus gedrückt habe ich das Auto per Funk zu gemacht, den Schlüssel rein geschmissen und die Tür zugeknallt. Jetzt hoffe ich auf den ADAC.

Mal Spaß bei Seite, ich habe in einer Hyper-V ein Win10 System angelegt für eine externen Mitarbeiter, der nichts mit unser Firma direkt zu tun hat. Nun habe ich extra ein Domain Controller für AD auf unserem Server eingerichtet, um per GPO den Nutzer so maximal wie nötig einzuschränken. Er braucht quasi nur ein Programm zum arbeiten und dies über VPN/RDP starten.

Jetzt hab ich extra eine eigene Richtlinie erstellt und dort nur den Benutzer hinzugefügt, doch leider hat es meinen Admin mit erwischt. Sprich der Admin des Servers darf auch gar nichts mehr, kein CMD, kein gpedit, kein regedit, keine Netzwerkverbindung ändern, nicht mal auf C: zugreifen oder generell ein anderes Programm ausführen geht nicht. Jetzt habe ich es schon über die lokale Anmeldung versucht, nur da meldet er die ganze Zeit dass entweder Passwort oder Benutzer falsch sei.

Ich stehe jetzt ziemlich ratlos da und weiß nicht wie ich vorgehen soll bzw. kann. Das System neu aufsetzen wäre die aller letzte Lösung, da ich auch noch eine Hyper-V hatte mit Linux und einen wichtigen Diensten. Die neu einzurichten ist schon eine Menge Arbeit. :/

Danke schonmal.

 

[Rickmer]

https://www.isunshare.com/windows-10-password/create-new-administrator-without-windows-10-login.html

 

[kartoffelpü]

Ich versteh nicht ganz. Wieso nicht einfach die GPO wieder deaktivieren oder so anpassen, dass du dich an der VM wieder anmelden kannst?

 

[Tamron]

Das System neu aufsetzen wäre die aller letzte Lösung, da ich auch noch eine Hyper-V hatte mit Linux und einen wichtigen Diensten. Die neu einzurichten ist schon eine Menge Arbeit. :/

Täglich grüßt das Backup .....

 

[autopilot]

Die GPO entsprechend wieder ändern?!

 

[von Schnitzel]

@kartoffelpü und @autopilot
Wie, wenn er / das Adminkonto keine Berechtigungen hat irgendwas zu machen?

Sprich der Admin des Servers darf auch gar nichts mehr, kein CMD [...]

Edit:
Wird wohl nichts anderes übrig bleiben als das was Rickmer schrieb.
Um mir solche Probleme zu ersparen, lege ich immer noch ein zweites Adminkonto an.

 

[Sebbi]

ich würde da de

da ich auch noch eine Hyper-V hatte mit Linux und einen wichtigen Diensten. Die neu einzurichten ist schon eine Menge Arbeit. :/

hmmm die kann man doch dann meines Wissens nach wieder problemlos einbinden, musst nur die config und Datendateien sichern, Server neu aufsetzen und diese wieder einspielen, dann sollte der Linuxteil wieder rennen wie zuvor.

"By default: The virtual machine configuration files are stored in "C:\ProgramData\Microsoft\Windows\Hyper-V". The virtual hard drives are stored in "C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks""

Wenn die Partitionen nicht verschlüsselt sind dann auslesen und sichern, ggf mit einer LiveCD

 

[madmax2010]

http://www.chntpw.com/download/

Viel glueck

 

[Borstel86]

Danke euch erstmal für euren Input, werd wohl Montag mich mal ransetzen und die verschiedenen Lösungswege ausprobieren. Ich hoffe es führt zum Erfolg, danach werd ich mich wohl mal intensiv damit beschäftigen was ich bei der Vergabe der Richtlinien falsch gemacht habe, weil nochmal soll mir sowas nicht passieren und ich habe ja immernoch die „Aufgabe“ für den Externen.

 

[BFF]

Als Erstes erstellst Du dafuer eine Richtlinie und bastelst NICHT an den default-policies rum.
Als Zweites machst Du dann ganz sicher, dass die Richtlinie die Du da erstellst nicht auf den DC wirken kann.

 

[Borstel86]

@BFF

Jetzt hab ich extra eine eigene Richtlinie erstellt und dort nur den Benutzer hinzugefügt, doch leider hat es meinen Admin mit erwischt.

Nur trotzdem lief irgendwas schief, keine Ahnung was.

 

[kartoffelpü]

@kartoffelpü und @autopilot
Wie, wenn er / das Adminkonto keine Berechtigungen hat irgendwas zu machen?

Okay, ich hatte überlesen, dass er sich an seinem Server auch nicht mehr anmelden kann. Dachte, dass es nur um die Win10-VM ging..

Dein Setup hört sich auch etwas abenteuerlich an.
Nach meinem Verständnis hast du einen Win-Server, auf dem per Hyper-V 2 VMs (Linux und Win10) laufen und deinen Server hast du zum DomainController gemacht.
VMs auf einem DomainController betreiben halte ich für keine gute Idee.


Wie hast du denn einen Benutzer zu der Policy hinzugefügt?
Policies werden auf OUs verlinkt und für alle darin befindlichen User/Computer wird die Policy angewandt.
Allerdings muss man natürlich noch zwischen Computer Configuration und User Configuration unterscheiden...

Wenn aktuell dein DomainAdmin und der User in der gleiche OU liegen (oder deine Policy auf oberster Ebene liegt), bekommen sie auch die gleichen Policies zugewiesen.

 

[BFF]

Nur trotzdem lief irgendwas schief, keine Ahnung was.

Wenn Du Dich nicht erinnerst was Du da gemacht hast, ja ok. Unsereiner kann dann nur vermuten.
Meinereiner vermutet, dass Du es irgendwie geschafft hast die Gruppen der Administratoren komplett rauszuwerfen.

Das es auf einem DC keinen lokalen Admin mehr gibt nachdem Du ihn zum DC gemacht hast weisst Du noch?

 

[CptHirni]

Ich gehe mal davon aus, dass du mit deinen Rechten dann auch nicht mehr direkt in \\deinedomain.local\sysvol\deinedomain.local\Policies herumfuckeln darfst. Wenns doch geht, dann kannst du dir den Umweg über PE sparen.

Boote das System in ein Windows PE, z.B. vom Installationsmedium des Servers, oder ein Windows 10 per Media Creation Tool o.ä.
Sobald dich das Setup begrüßt öffnest du mit Shift+F10 ein cmd Fenster. Darin kannst du notepad.exe aufrufen und hast über den Datei-Öffnen Dialog einen Windows Explorer für Arme.
Kannst natürlich auch irgendein anderes (Linux-)Live-System nutzen mit Zugriff auf die lokalen Datenträger.

Die hier relevanten Einstellungen der GPOs [IPSec Einstellungen und noch ein paar andere liegen direkt im GPC im AD, aber damit wirst du dich wohl kaum ausgesperrt haben] liegen in C:\Windows\SYSVOL\domain\Policies\{GUID-der-GPO}
("C:\" entsprechend dem Buchstaben, den das Live-System deiner lokalen DC-Systempartition verpasst hat)

Wenn du die GUID der bösen GPO nicht weißt, kannst du dich nach dem Erstelldatum der Ordner richten. So viele werden es da wohl nicht sein. Einer gehört zur Default Domain Policy und einer zur Default Domain Controller Policy. Im Normalfall die beiden ältesten Ordner da, die solltest du nicht anfassen.

Navigier in den entsprechenden GUID-Ordner der bösen GPO und verschieb alles aus den Unterordnern "Machine" und "User" an einen anderen Ort. Die beiden Ordner sollten dann leer sein.
Nicht die GPT.ini direkt im \{GUID} Ordner verschieben, die bleibt so liegen wie sie ist.

Damit ist die GPO "leer", wie eine neu erstellte GPO.
Durchbooten (sollte reichen), gff. ein gpupdate /force einwerfen, und in der Gruppenrichtlinienverwaltung die GPO löschen. Danach auch den entsprechenden Ordner {GUID} in SYSVOL löschen, falls noch vorhanden.

Edit: Wenn dir gpupdate einen Eventlog-Fehler wirft ala ...\Machine\..\registry.pol oder ..\User\..\drives.xml kann nicht gelesen werden, die Policy nicht verarbeitet wird und du immer noch keinen Zugriff hast, kannst du leere dummy Dateien mit den passenden Namen in den passenden Ordnern erstellen. Oder die originalen gebackupten Dateien editieren und wieder zurück in die Ordner packen.
Du kannst auch die Dateien auf einen anderen DC importieren (da eine leere GPO mit dem selben Namen erstellen und den gesamten Inhalt des {GUID}-Ordners mit deinen Backup-Daten ersetzen) und bequem mit gpedit nur die Stellen die auf deinen Admin/DC wirken editieren und wieder zurück auf den defekten DC schieben. Wäre wohl das eleganteste und sicherste, wenn man schon diesen schlammigen Weg nehmen muss.



Der schnellere/nicht ganz so dreckige Weg (falls mal jemand darüber stolpert der noch cmd öffnen und Befehle gegens AD ausführen darf):
Im laufenden System cmd öffnen:

dsquery * -filter (objectClass=groupPolicyContainer) -attr displayName distinguishedName >"%USERPROFILE%\Desktop\gpos.txt"

Erstellt dir eine txt auf dem Desktop in dem die GPOs gelistet sind. Benötigt wird der distinguishedName der betroffenen GPO.

dsrm "CN={GUID},CN=Policies,CN=System,DC=deinedomain,DC=local" /subtree

Der Befehl entfernt die GPO aus dem AD. Also wirklich die richtige GUID nehmen...

Dann ein gpupdate /force und ggf. ein reboot oder logout/login damit alle Einstellungen der GPO tatsächlich weg sind.
Die GPO kann dann in der Gruppenrichtlinienverwaltung gelöscht werden. Dann nach
C:\Windows\SYSVOL\domain\Policies\ (oder \\deinedomain.local\sysvol\deinedomain.local\Policies ) und da den entsprechenden {GUID}-Ordner auch löschen. Wirklich die richtige GUID nehmen...


Ob der eine oder der andere Weg, ein Backup sollte selbstverfreilich vorhanden sein.

P.S.: Den Hyper-V Host als DC herzunehmen (falls ich das richtig verstanden hab) halte ich nicht für die beste Idee. Eine DC-VM braucht lächerlich geringe Ressourcen und sollte wohl noch mit drin sein.

 

[Borstel86]

Danke für deine ausführliche Antwort. Habe den DC nicht in der VM laufen, sondern mit auf dem Server wo die VMs drauf laufen. Also ist schon getrennt, Windows Server mit DC,AD und Hyper-V.

In den VMs läuft lediglich ein Linux und ein Win10 als Client System.

Werde mich Montag dann mal ransetzen und dann berichten.

Wenn Du Dich nicht erinnerst was Du da gemacht hast, ja ok. Unsereiner kann dann nur vermuten.

War ja an sich auch nicht so gemeint, mir is klar dass der Grund wie dies passiert ist, aus der Ferne schwer bis unmöglich zu sagen ist.😄

 

[Tamron]

Dein Host sollte nicht gleichzeitig auch noch der DC sein. Zieh dir einen weiteren als VM hoch und nimm den DC vom Host weg.

 

[Borstel86]

So, bin heute erst leider dazugekommen. War alles gar nicht so einfach wie erst gedacht. Erst musste ich eine Möglichkeit finden per WindowsPE bzw. Installationsmedium aufs System zu kommen, durch den Raid
Controller war dies nicht ganz so einfach. Als ich dann endlich drin war, war der erste Anlauf die Variante den GUID-Ordner der GPO zu löschen, leider erfolglos. War gar keine Veränderung. Dann kam die utilman.exe/cmd.exe Lösung zum Einsatz, dann hat der Windows Defender das ganze wieder unterbunden. Habe dann die Registry des Systems mit dem WinPE geladen und dort cmd.exe als Debbuger bei ultiman.exe hinterlegt. Dies lief dann super.

Dann versuchte ich die Variante des neuen Nutzers über CMD und net user zu erstellen, dies ging leider nicht. Er hat zwar den Nutzer erstellt, aber beim Login kam immer "Benutzer oder Kennwort falsch" denke es wird daran gelegen haben, dass per GPO keine lokale Anmeldung erlaubt war.

Habe dann Powershell über CMD gestartet und darüber dann den ServerManager. Da bin ich dann halt den Weg gegangen und habe AD, DNS und Gruppenrichtlinienverwaltung bei den Serverrollen entfernt und nach dem Neustart war dann der Server endlich wieder nicht mehr in der Domäne (ist logisch), ich konnte mich wieder lokal Anmelden und dies mit kompletten Zugriff wieder.

Ganz schöner Aufwand und nochmal kommt mir dies hoffentlich nicht nochmal vor. Danke für eure Hilfe!

 

[BFF]

Dann sorg, wie eigentlich ueblich, fuer genuegend Backup bevor Du solche Schnellschuesse auf Deine Live-Systeme los laesst.

Und dann sorg dafuer, das der Host einzig und allein Hyper-V macht.
Domainenkontroller laesst Du als VM rennen und den Rest natuerlich auch.
Und der DC ist und bleibt DC, nix weiteres.

Das hier:

Habe den DC nicht in der VM laufen, sondern mit auf dem Server wo die VMs drauf laufen. Also ist schon getrennt, Windows Server mit DC,AD und Hyper-V.

ist keine Trennung.

BFF

 

[Sebbi]

setz für den DC eine eigene VM auf - nur das ist dann echte Trennung

Windows Server mit DC,AD und Hyper-V.

genau darum ist ja dieser Mist ja erst entstanden.

Und vorher kümmerst du dich um ein ortentliches Backup Konzept

 

[Art Vandelay]

...

Grandioser Post! Zum ersten mal in diesem Forum das Gefühl ist müsste ihn mir abspeichern wenn's mal knallen sollte mit dem DC!