How do I remove a group policy without access to the domain (controller)?

Question

I've got a (WS2012-R2) domain controller and a set of (WS2012-R2) servers that are member of the domain. I accidentally added a group all administrators are member of to the Group Policy "Deny logon access locally", "Deny logon as service", "Deny remote access" and "Deny network access". This resulted in me and all other administrators (even the built-in account) being locked out of the domain controller.

Is there a way to regain access to the server by removing the GPO or by removing an admin account from the group that has been denied?

Solution 1

Two thoughts come to mind.

You could, conceivably, use a boot CD to access the domain controller while it's offline and manually edit or delete the offending GPO - a domain's GPOs exist under the SYSVOL folder in the file system on domain controllers, and are applied as registry settings, both of which are accessible from a Boot CD - however, this would either be undone by replication or would cause domain replication errors as soon as the domain controller you did this on connected to the other domain controller(s) in the domain. (I'm making the assumption here that you do have more than one domain controller in your domain, as you should... if you only have the one, this wouldn't be a bad approach).

The other approach that comes to mind is to enter Directory Services Restore Mode and perform an authoritative restore from a backup that predates this GPO. (And this too, relies on the assumption that you're doing as you should do, and have backups to restore from.)

Solution 2

I haven't actually tried this. (Sorry.) I'm also assuming that RSAT won't work because of "deny remote/network access." (If you haven't tried this, it's worth a shot, but I'm not optimistic.)

Perhaps you could create a new administrator account with a Hiren's Boot CD and use that account to edit the policy.

Solution 3

Where is the group policy applied? Only to DCs or to the whole domain?

If it's only applied to DCs, then you can still log on to another member computer using a domain admin account; you can then enable the group policy management console and/or all other AD administrative tools if you are on a server OS, or install RSAT and do the same if it's a workstation; with those tools, you will be able to edit the offending GPO, or at least users and groups (the ADUC console uses LDAP queries, thus it's not subject to log on restrictions).

If the policy is instead applied to the whole domain and you can't actually log on anywhere using a domain admin account, then a possible workaround could be using the PowerShell Active Directory module: almost all cmdlets have a -credential parameter which lets you specify the credentials to use for running the command, even when PowerShell is actually running under a different user account; this includes Remove-ADGroupMember. Thus, a possible solution would be:

• Log in to any member computer using any available user account.
• Make sure AD administrative tools are installed on the system (either enable them on a server or install RSAT on a workstation).
• Launch PowerShell.
• Import-Module ActiveDirectory
• $admincreds = Get-Credential (this pops up a window where you need to input credentials for a domain admin account)
• Remove-ADGroupMember <GroupName> <UserName> -Credentials $admincreds

If this works, <UserName> will be removed from <GroupName>, and thus the offending policy will not lock it out anymore.

Solution 4

Boot your domain controller in active directory restore mode, with the account you setup when you created your domain. (It's simply a local admin account on the DC, named Administrator, and the password was setup in dcpromo.)

From there, remove all NTFS permissions on your SYSVOL volume, in the GPO ID folder. (Check the last modified folder to find the last modified GPO).

In that mode, the Active Directory database is not loaded, but you have access to the filesystem.

If nothing works, in that mode you can try a gpofix command, but be aware it will remove ALL GPOs.

Solution 5

When the domain was originally created there was a "god" account created. Find out what that was, its password, and you should be able to login to the DC hosting the global catalog. From there you should be able to undo what you did and give it time to propagate.

If that fails there are some hacker techniques you can use, but it wouldn't be appropriate for me to relay that here. Contact a local security expert as they're usually up to speed on hacker techniques and can help you regain the domain.

Of course, if this is just a few servers, and it's not critical, you might as well just wipe and start over.

View more solutions

Comments

[shagrinar]

Thanks for your answer, sadly I can't run the Hiren's Boot CD in my virtual machine as it is a Generation 2 Hyper-V machine. Is there maybe an alternative version of Hiren's Boot CD?

[shagrinar]

The domain controller is called asgard and the domain is called yggdrasil so I entered: \\asgard\c$\windows\sysvol\sysvol\yggdrasil\policies which resulted in an error message telling me that windows can't access the directory. I'm not trying to access this from the local administrator account of a computer that's inside the domain but from my private laptop - it still requires a login.

[shagrinar]

Can you give me a hint on how to find out which account this could be? I know of the local administrator account of the domain controller, which turned into a domain account when I installed the Active Directory but this is also affected. Wiping the servers would be my last option to consider.

[Colyn1337]

When creating a brand new domain, whether by script or wizard, you have to create a single master account and give it a password. It's generally only used in times of disaster recovery (like now) and only the person who created the domain would know. If you don't know who created the domain, check with your director, odds are someone in the management chain was given this info.

[kgimpel]

Check the directory, I'm not sure after sysvol. Can you log to \\\domaincontroller\c$ using domain credentials?Or you can try to use local admin like "asgard\admin" or "asgard\tor" :)

[shagrinar]

I tried this to no avail, but as it is a virtual machine the DC is running in I just mounted the virtual hard disk. I found the directory C:\sysvol\sysvol\fqdn_of_domain, trying to access it resulted in an error (it's some sort of symbolic link?). I found another folder C:\sysvol\domain which contains scripts and policies. I moved everything out of it, unmounted the VHD and fired up the machine. Sadly there is no change. Where does this link lead to? Any other options I can consider when having hard disk access?

[HopelessN00b]

@shagrinar Referencing the domain controller directly via an SMB share, which this answer advises, won't work because you've denied network access by GPO. You might be able to do \\domainname\sysvol\ and access the policies that way, but I wouldn't get my hopes up. Modifying sysvol requires domain admin privileges, and if you've locked all the domain admins out, you won't be able to access it with the required privileges to do this.

[HopelessN00b]

Doesn't Deny network access apply to access via RSAT (and PowerShell)? Not that I'm about to test, or have experience locking myself out of my DCs to fall back on, but I believe this won't work for that reason.

[Massimo]

ADUC uses LDAP queries, thus it should not be blocked by "deny network access" restrictions... but you'd need to actually launch it using a domain admin account, which you can only do if you have at least one machine to which the offending GPO isn't applied. However, PowerShell might instead be able to help (see my answer for details).

[Colyn1337]

@Massimo I think you're info is a bit old... " you can configure a domain controller so that you can log on to it with the DSRM Administrator account if the domain controller was started normally but the AD DS service is stopped for some reason." technet.microsoft.com/en-us/library/cc816897(v=ws.10).aspx

[Massimo]

ADUC uses LDAP queries, this should be be outside the area restricted by "deny network access"; the problem is in getting it running using a domain admin account. I'm not sure about PowerShell, but it instead doesn't need to be actually running under the same user account which you use to run the command, so it's definitely worth a shot.

[yagmoth555]

In ad restore mode if he erase the gpo folder or add a ntfs deny on it he would be good.

[Massimo]

@Colyn1337 I know you can use the DSRM account to access a running DC, but this doesn't change the fact that the account doesn't have domain admin rights, and it can't perform actions inside AD (such as removing a user from a group), but only outside it (such as restoring from backup).

[HopelessN00b]

@Massimo Like I said, I can't say for sure, but the documentation on this particular GPO states, under Best Practices: "Because all Active Directory Domain Services programs use a network logon for access, use caution when you assign this user right on domain controllers." That sounds to me like a warning that this particular configuration applies to "all Active Directory Domain Services programs".

[Massimo]

@yagmoth555 I don't think so, that would be overwritten by replication as soon as the DC is back online. Probably worth a try, but I'm not betting on it to work.

[Massimo]

@HopelessN00b That's possible; both options are still worth a try, though.

[HopelessN00b]

A thought occurs on this answer. Since we're dealing with a domain controller, which doesn't have local accounts... how would one create a new administrator account via a Boot CD on a domain controller? I'm drawing a blank. I've used this technique to reset the Administrator/DSRM password on domain controllers before, but am doubting it's possible to create a new user with it. Am I missing something?

[Colyn1337]

It exists outside AD, enabling it to repair and fix problems. Such as wiping GPO and restarting.

[HopelessN00b]

@Massimo It would be possible to remove the GPO from its location in the sysvol folder on the file system, as well as edit the registry to alter the settings using this technique. I assume that's what being suggested in this answer.

[Admin]

@KatherineVillyard FalconFour is a more advanced/modern/useful version of HBCD... Just sayin'

[kgimpel]

Inside of SYSVOL\Domain\Policies You can sort, find and move only directories created in the past day. One of them will be your "problem" policy.

[shagrinar]

Is there a way to back up all GPOs so I can put them back again (without the lockout-GPO)?

[shagrinar]

\\domainname\\sysvol sadly did not work, I can access the hard drive of the DC and modify contents as stated above. What would I have to delete/modify to remove the GPO?

[shagrinar]

I tried both of the above but with no success. The LDAP access is disabled.

[kgimpel]

Go to directory C:\windows\SYSVOL\domain\Policies sort all directories inside by date. Policies it is a folders they are have names as {7305EB24-5EAA..} move this policies to another directory.

[yagmoth555]

@shagrinar No... but only removing all NTFS permission on the GPO folder might be better as it will block the GPO to apply, and will only make your DC display that your GPO is corrupted in the GPO's MMC.

[Katherine Villyard]

@HopelessN00b I haven't tried it myself. But HBCD is no respecter of anything, and once I promoted a machine with local accounts already to a DC (for reasons) and the local accounts still existed, there was just no way to manage them.

[jojojoj]

If you have a small number of DC's (2,3,4?) and can manage to lose all but one of them, the first option may work. Shut down, retire, destroy all but one DC, jurry rig that one, seize the FSMO roles. If you get that far, build some new DC's to replace those you had to destroy.

[shagrinar]

Removing all NTFS permissions on SYSVOL has no effect, same as removing all files from the directory. Entering DSRM was possible and I could login with the account but running dcgpofix gave me an error message saying I have to be logged in with a domain member account...

[yagmoth555]

The gpo setting are still applied, can you erase the cache while in DSRM mode? (see there for the registry location; support.microsoft.com/en-us/kb/201453)

[shagrinar]

I removed everything inside History, sadly no success at logging in.

[shagrinar]

Just like moving everything or revoking NTFS permissions it has no success.

[shagrinar]

Using RSAT was not successful, I got no access to the DC in any way possible except DSRM and - while shut down - hard disk access.

[yagmoth555]

Unfortunatly, I now start to think that you will have to do a authoritative restore like @HopelessN00b stated in is answer.. do a offline image of the server before in worst case and it will allow you to test a restore after. That will allow you to be able to get back if the restore fail.

[shagrinar]

This looks very promising, sadly I can't confirm that it works. By now I'm rebuilding everything. If anyone can confirm that this works, I'm more than happy to mark this as the answer!