8

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?

  • 3
    Just a thought, probably academic, but how do you accidentally do this? – Colyn1337 Aug 3 '16 at 21:49
  • @Colyn1337 It's probably not accidentally but not well considered. The administrator accounts are member of a group that every employee is member of and I added this group to the above mentioned GPOs which resulted in a lockout of every account. It didn't come to my mind that there is actually the possibility to lock out the built-in administrator account but there we are... – shagrinar Aug 3 '16 at 22:09
  • Does this policy also apply to other DCs, or just this one? (Can you just build a new DC and forcibly seize any roles this one has?) – Katherine Villyard Aug 5 '16 at 19:51
6

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.)

| improve this answer | |
  • 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. – Clayton Aug 4 '16 at 18:29
4

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.

| improve this answer | |
  • 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 Aug 3 '16 at 22:11
  • 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). – Massimo Aug 3 '16 at 23:49
  • 3
    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? – HopelessN00b Aug 4 '16 at 0:01
  • 1
    @KatherineVillyard FalconFour is a more advanced/modern/useful version of HBCD... Just sayin' – user368760 Aug 4 '16 at 2:53
  • @shagrinar If you can boot of PE--I have a PXE option of PE just for emergencies and diagnostics--that might work as well, although you won't have MMC without contortions. But try RSAT first if you haven't. It's the least painful option. – Katherine Villyard Aug 4 '16 at 15:43
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.

| improve this answer | |
  • 4
    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. – HopelessN00b Aug 3 '16 at 23:48
  • 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. – Massimo Aug 3 '16 at 23:51
  • In ad restore mode if he erase the gpo folder or add a ntfs deny on it he would be good. – yagmoth555 Aug 3 '16 at 23:52
  • @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". – HopelessN00b Aug 3 '16 at 23:57
  • 3
    I tried both of the above but with no success. The LDAP access is disabled. – shagrinar Aug 4 '16 at 9:56
3

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.

| improve this answer | |
  • Is there a way to back up all GPOs so I can put them back again (without the lockout-GPO)? – shagrinar Aug 4 '16 at 9:08
  • 2
    @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. – yagmoth555 Aug 4 '16 at 12:48
  • 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... – shagrinar Aug 4 '16 at 20:26
  • 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) – yagmoth555 Aug 4 '16 at 20:28
  • I removed everything inside History, sadly no success at logging in. – shagrinar Aug 4 '16 at 21:41
2

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.

| improve this answer | |
  • 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. – shagrinar Aug 3 '16 at 22:24
  • 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. – Colyn1337 Aug 3 '16 at 22:26
  • 1
    The account you are talking about is the Directory Services Restore Mode account; it's only used for performing maintenance on offline DCs, but it's not actually a domain administrator; it would be completely useless in this case, unless you want to restore AD from backups. – Massimo Aug 3 '16 at 23:43
  • @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 – Colyn1337 Aug 3 '16 at 23:50
  • 1
    @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. – HopelessN00b Aug 4 '16 at 0:04
1

First, shut down all domain controllers. Doing so will avoid bizarre replication problems.

The first step is to remove the bad Group Policy setting. Privilege assignments are stored in the GptTmpl.inf file in MACHINE\Microsoft\Windows NT\SecEdit under each policy folder. You'll know you have the right policy when that .inf file contains a line for SeDenyNetworkLogonRight, SeDenyInteractiveLogonRight, et cetera. Delete all the SeDeny...Right lines from it.

Windows won't apply the new settings unless it sees that the GPO has changed, which it determines by consulting the versionNumber attribute on an Active Directory object. Let's not try to edit AD offline. Instead, we'll remove the bad settings from the Registry manually.

Mount the domain controller's \Windows\System32\config\SECURITY hive into another Windows system's Registry with reg load. Open the Registry Editor and navigate to Policy\Accounts under the mounted hive. (You may need to be running regedit as SYSTEM for that to work. PsExec can do that.) Each subkey of that corresponds to a user or group, and the ActSysAc subkey of each of those holds the "rights." (The "privileges" are all in the Privilgs subkey.) Find the one with an ActSysAc value of C0 03 00 00, which corresponds to the four rights you denied. Delete ActSysAc or change its value to 00 00 00 00. Close the Registry Editor and unmount the hive with reg unload.

Boot up the domain controller you modified. You should be able to log in now. Use the Group Policy Management Console to make any edit (no matter how trivial) to the relevant GPO's Local Policies. That will increment the GPO's version number.

Boot up the other domain controllers and let the changes replicate.

| improve this answer | |
  • 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! – shagrinar Aug 6 '16 at 9:05
0

You can try to open in explorer \\domain.controler\c$\windows\sysvol\sysvol\domain.local\polices (You still have access)

There you will find all polices. Move all this dir to some temp destination and try to reboot PC. It will helps.

| improve this answer | |
  • 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 Aug 3 '16 at 22:22
  • 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" :) – kgimpel Aug 3 '16 at 22:31
  • 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? – shagrinar Aug 3 '16 at 23:16
  • 3
    @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 Aug 3 '16 at 23:38
  • 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. – kgimpel Aug 4 '16 at 6:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.