DISA STIG’s and SRG’s – Part III (Deploying GPO’s)

In DoD Security by Imperitiv Solutions1 Comment

The way I like to deploy these is rather simple once you get the hang of it, but this method can cause some headaches and confusion the first time or two you run through it. Since many of the STIG settings are the same from one GPO to the next, there’s tons of overlap. This is one of the reasons why they provide the WMI queries, but I don’t go that route. I find the common settings between the operating system STIG’s and put them all in one GPO and apply it at the domain level. Then I take the remaining OS unique STIG’s and apply them with an OS unique GPO with a WMI query, or if possible, to an OU that contains only that type of OS; such as a “Windows 7 Workstation” OU.

When done this way, I need only go back to one GPO and update OS settings that I want to impact all flavors of Windows. If I used separate Windows 7, 10, Server 2012 and Serer 2016 GPO’s, I need to edit that setting in each GPO separately. It’s more work up front doing it the way I do, but it gets you much more intimate with the settings and what’s going on and why.

Additionally, for troubleshooting sake, I divide up all the common OS settings into a few separate GPO’s. I create a GPO for the following categories: Security, System, Network, Windows Components and Miscellaneous. This way if I do run into a problem that appears to be coming from a GPO policy that’s too tight or incorrect, I can narrow down the offending setting quicker. I can disable each GPO one at a time and see if that elevates the issue. If I had all the settings in one large GPO I’d only be able to determine that it was a GPO setting.

Another reason I do this is for restores. There was a time back in the Windows 2000/2003 days where GPO’s could become corrupt and you’d have to restore them to be able to edit and work with them. If you didn’t have any recent or usable backups, you’d have to create them all over from scratch. Dividing the settings up into multiple sets protects you from losing all your GPO eggs should your basket become corrupt. I haven’t seen that since Windows Server 2008 was released, but as I discussed in the previous paragraph, it’s not the primary reason I do it.

There are also times when those domain level GPO settings aren’t what you want for a subset of machines. In those cases, you can apply a GPO to counter those settings within a child OU. Say you want your screensaver to be 15 minutes throughout the enterprise, but you have a subset of workstations used by HR where you need the screensaver set to 5 minutes. You can create an HR unique GPO and set that and any other HR unique settings just on that OU.

If you’re having any GPO issues, would like any assistance setting up a new GPO structure or have a desire to revamp an existing structure that’s become unmanageable we’d be happy to help.


Leave a Comment