Locked out of DC and domain admin accounts via GPO

Question

I'm currently locked out of my domain controller and unable to log onto domain computers using accounts who are members of the domain admins group due to the incorrect application of a GPO at the top level. There are no other DCs in the domain. I have tried removing the GPO with RSAT on one of the workstations, but it is also disabled by this GPO. How can I remove this GPO and regain control of my domain? I have access to the DC through DSRM, but I'm not sure how I can use this since AD and Group Policy appear to be disabled when booting into DSRM. Unfortunately, we do not have a recent backup of AD I could restore to as we just recently migrated to a new DC.

Any ideas are greatly appreciated as I'm currently staying overnight at work until I get this resolved. Thanks all.

Answer 1

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.

Answer 2

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.

Answer 3

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!

Answer 4

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.

Answer 5

Boot into Restore mode aka DSRM on the DC. This login should be made with the account named "Administrator" and the restore mode password you provided when the DC role was added. Run the following command:

dsquery * -filter (objectClass=groupPolicyContainer) -attr displayName distinguishedName

Review the list for the offending GPO. Replace the distinguishedName in the command below with the distinguishedName from the offending GPO. The "RM" in this command is for "Remove" not "Restore Mode"

dsrm "CN={11111111-AAAA-2222-BBBB-333333333333},CN=Policies,CN=System,DC=acme,DC=com" /subtree
gpupdate /force

Reboot the DC into normal mode. Reboot other servers/workstations. Hopefully then you can login.

Answer 6

I, inadvertently, did the same thing yesterday. I was implementing new STIGs for Server 2008R2 and 2012R2. Did a bunch last week and all was looking good. Still had 15 more to fix based on Nessus scan so I looked at what they were and realized some I had already corrected (or thought I had). Most were ones that required you to deny Domain Admins, Enterprise Admins, and Guests from having login/remote/batch/service access.

Some commenters wanted to know what GPOs caused the problem so here is what did me in; Computer config-> Policies-> Win Settings-> Sec Settings-> Local Policies-> User Rights Assignments. There is Deny Log on a batch job, Deny log on locally (be careful), Deny logon through remote desktop services (be careful), and Deny access to this computer from the Network (this one did me in). There are also settings to allow some of these same rights but if you deny them, the allow doesn't overwrite.

I added Domain Admins to the GPO which already had the Guests and Enterprise Admins groups. This GPO was applied to all servers (including DCs). I was hesitant to do it but needed to test to see what would happened. Within 60 seconds of closing the GPO edit window, everything broke. No 90 minute wait for Group Policy to update. No reboot required to implement the computer policy. Things just broke, quickly.

I tried to make the boot CD or USB to edit the DSRM Administrator account to no avail. So, I used what Wilson mentioned above, edit the policy and change revision number. Worked perfectly after booting from the Server 2012R2 install disk and selecting repair. Then selected Advanced Tools and Command Prompt. Found the files, edited and saved them. Rebooted and still couldn't login but was able to remote in from a workstation. Disabled the bad GPO and rebooted the server. Everything is back to normal.

Biggest problem was all our Admin folks are in Domain Admins, I know it is bad practice now but some people are hesitant to change. Clearly we will create new groups and assign people only to the groups they need. Then use GPOs to give those specific groups access to what they need so we can still implement the STIGs.

Hope this helps!