We have got an Active Directory domain with Windows Server 2016 on the domain controller and up-to-date Windows 10 on all clients. Not long ago I began deploying the Center for Internet Security (CIS) Level-1 security benchmarks on the domain via the Group Policy: Windows 10 ones in the default domain policy, with overrides based on the Windows Server 2012 R2 document (there isn't one for 2016 yet) in the default controller policy. I've been bitten by careless hardening of Windows before so this time I've been going through all the settings one by one, with the relevant documents open and checking the impact of any unfamiliar options. It worked fine - until today, when I managed to finally mess something up. The symptoms are as follows
- Left-clicking on any GPO in Group Policy Management shows an "access denied" error box. I can still examine and manipulate object properties though, including changing the GPO status;
- Opening one of said GPOs for edition shows "access denied" again, albeit in a different box, and when the editor starts the visible tree entries are marked with a red X;
- Back in Group Policy Management, if I go to the Details tab of a GPO I can only see its AD version. The one in sysvol is described as not available;
- Finally, when I run gpupdate /force on any domain computer - including the DC itself - I get an error like this:
The processing of Group Policy failed. Windows attempted to read the file \contoso.com\sysvol\contoso.com\Policies{foo}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may be transient and could be caused by one or more of the following: a) Name Resolution/Network Connectivity to the current domain controller. b) File Replication Service Latency (a file created on another domain controller has not replicated to the current domain controller). c) The Distributed File System (DFS) client has been disabled.
Unfortunately I've just realised I forgot to check the corresponding error code in the Event Log, however given that if I point Explorer to \contoso.com\sysvol\ (or for that matter any share on that server, using both the host and the domain name in the path) I get asked for credentials and have yet to find ones that work, my bet is on "access is denied" again. Accessing sysvol via the local path on the DC works fine, by the way.
In short, at least the latter two symptoms strongly suggest I have managed to lock myself out of the SYSVOL share; don't know if the former two are caused by this too or not. On a side note, after rebooting the domain controller to DSRM and then back to normal mode everything worked for around 10 minutes.
Now, I've got up-to-date backups so I could just restore to last working state and be done with it. However, what I would really like is to a) understand what settings exactly might have caused this problem (otherwise I'll likely run into the same issue again soon), and b) figure out how to make my domain work with all the hardening in place (CIS Level-1 benchmarks are baseline, they are not supposed to have much effect on functionality...). Oh, and c) if I can still actually do anything with the current configuration.
Anyone out there with experience with either hardening Windows in general or applying CIS benchmarks specifically, who could give me a nudge in the right direction? If so, thank you very much in advance!
Update: seems I was able to disable offending policies but it didn't undo the SYSVOL lockout. Resetting the local security policy to defaults with secedit hasn't helped either, possibly because of all the "access denied" warnings the procedure produced.
By the way, one interesting thing I noticed is that if I run "net share SYSVOL" on the DC from PowerShell prompt started with elevated permissions, it does return expected information (unlike running from a normal prompt which gives - you've guessed it! - "access is denied").
