Locked out of DC and domain admin accounts via GPO

After many hours I was able to regain access to the DC. What ended up working for me was the following. Keep in mind I had access to the DSRM login on the DC and basic domain network PowerShell commands.

1. Identify GPO GUID using PowerShell on a domain workstation.
   • (Import-Module GroupPolicy, Get-Gpo -all, note the GUID of the GPO)
2. Boot into DSRM using local administrator account.
3. Locate GPO by GUID in SYSVOL folder.
   • (C:\Windows\SYSVOL\domain\Policies{YOUR_GUID_HERE}
4. Navigate to GptTmpl.inf file in GPO folder structure.
   • (..\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf)
5. Make changes to the policy as needed. For me it was removing certain users from the "SeDenyInteractiveLogonRight", although I added them to the related 'allow' right as well for good measure. Save this file.
6. Go back up to the root policy GUID folder and locate the GPT.ini file.
7. Edit (increment) the version number here. It's easiest to add a 0 to the end of the version number, or at least add 10. Group Policy will check this number to determine if the policy should be re-processed.
8. Reboot the DC and, assuming you're able to login, disable/edit/delete the GPO and do a gpupdate /force from the command prompt to make sure the changes propagate quickly.

There were some lingering effects of the GPO that had to be cleaned up with counter-GPOs. For example, WID lost the ability to logon as a service because that right was defined but blank in the problem GPO. As I discovered these effects I wrote one-time GPOs to correct them and pushed them across the domain.

Hope this helps someone and thanks for all the suggestions.

I don't know if this will work for you but I figured it was worth posting as a "possible answer".

Some time ago while reading around the Internet I came across http://www.nobodix.org/seb/win2003_adminpass.html . According to that article while logged in in "directory services recovery mode" you can set up a "service" to run a command. Then after rebooting back into normal mode the service will run and execute your command as the "system" user.

I don't know if this technique will still work on more modern versions of Windows and I don't know if it will work for the commands you need (which seem more complex than a simple password reset) but it might be worth a shot.

Another user has a similar thread here on serverfault: How do I remove a group policy without access to the domain (controller)?

The asker never selected a winning answer, but the suggested methods include (in no particular order):

• Deleting the offending GPO from the SYSVOL folder (\\example.com\SYSVOL\Policies or C:\Windows\SYSVOL\sysvol\example.com\Policies) Sort by date modified and delete the new one.
• Use PowerShell's Active Directory module to Remove-ADGroupMember to get your account out of the banned group (assuming the GPO applies to a group other than Domain Admins)
• Manually editing the group policy's .inf and then deleting the registry settings from the domain controller https://serverfault.com/a/795162/337307

Good luck, I hope one of these methods will work for you!

I would say you are royally screwed here. My one major screw up in my tech career was something similar - I accidentally disabled every account in the domain, including all admin accounts (my own included). fortunately, as a child domain I was able to get someone with an Enterprise Admin account to enable my account, after which I was able to reverse what I did.

If you don't have this option, you will need to use DSRM to restore your admin account. You've mentioned that you migrated from another DC - if this is the case, and the DC is still in the domain and still a DC, make sure you understand the difference between authoritative and non-authoritative restores.

Restoring your own admin account (or whichever other admin accounts are in whatever backups you have access to) will let you undo whatever else has been done.