Have you ever accidentally used Group Policy to prevent yourself from being able to edit Group Policy? You wouldn't be the first SysAdmin - it can happen to even the most seasoned of us; especially in the middle of the night during a particularly long maintenance window...
Here is the scenario:
A single Windows Server 2008 R2 machine running AD and RDS (clearly in need of a couple of Domain Controllers and the transfer of FSMO roles away from the Remote Desktop Session Host). Fortunately, AD Recycle Bin is enabled. A young SysAdmin decides to modify Group Policy on this time bomb without peer review or change management. Fortunately, they didn't edit the default Domain Policy, but they did apply a policy to all Users that prevented access to the Control Panel and explicitly forbid the execution of the MSCs from Start --> Run. Hell, he even disabled the execution of MMC, RegEdit, and CMD.EXE...!
Wouldn't you know it, he even had the courtesy to run a 'gpupdate /force'...
It is at this time that many SysAdmins would try to do things like edit the Registry, delete entries from SYSVOL, and other nefarious items that are sure to make your day a whole hell of a lot worse.
(Had the Jr. Admin only edited the default Domain Policy, we could perhaps use Dcgpofix to restore the default Domain Group Policy for our Disaster Recovery.)
Fortunately, TaskMgr was still accessible, and PsExec was installed on the host to fix a previous issue with a legacy application that wasn't multi-thread aware. (We modified the default shortcut for the application and added PsExec to set set the affinity of the application to a single core - works like a charm!) How did I fix the issue? I did the following:
Start --> Run --> taskmgr followed by File --> New Task (Run...) and 'psexec cmd.exe' with the task created with administrator privileges. This allowed me to spawn a shell. Now, I thought I was going to have to use REG from the command line to query and delete Registry keys, but my intuition told me to try running MMC for the hell of it...
And it launched.
Now, the real test is whether or not I can add the GPO snap-ins and edit the policy object...
Yes.
I then used the Group Policy Editor MMC snap-in to disable the GPO followed by another 'gpupdate /force' from my PsExec-spawned shell.
I saved the day, and now I have convinced the client to spin up a few Domain Controllers.
As for the Jr.? There never was a Jr. SysAdmin - it was me the entire time; or, at least I think it was me. An unnamed party also has Domain Admin rights, but they swear they didn't cause this blunder.
Maybe I will dig through the logs, for fun and profit, just to make sure...
Why would your domain admin account be in the same OU?
ReplyDeleteIt wasn't - the Group Policy was applied to all authenticated users and all users... LOL. Naturally, I convinced the client to let me build a new OU and a new Security Group.
DeleteThank you so much! This worked for me. I had to load the local policy snap-in because the GPO Management Edit kept erroring out with: Access is denied. Once I edited the local policy via psexec removing the groups: Domain Admin/Enterprise Admins from the Deny Log on Locally and Deny Remote Logon settings. Holy cow I can't thank you enough for getting us out of this 5 hour troubleshoot.
ReplyDelete