;)
You want me to do what?
The alarm clock is screaming at me to get the heck out of bed. I snooze it twice, then finally get up. Once I’ve dressed, I cruise to the kitchen for some much-needed coffee because I stayed up waaay too late the night before. After coffee, I walk to my home office where my laptop awaits, along with a likely plethora of emails to respond to before continuing work on a client’s project. It seems like just another day, nothing new… on cruise control.
As soon as I sit down, I check Teams to see what’s going on and if anybody needs any immediate assistance with some technical issue they are experiencing. Wouldn’t you know it, my manager is pinging me to discuss an upcoming project for one of our clients.
Manager: “Hey! We have a project slated to start next week, and I think it’s right up your alley!”
…I’ve heard this before…
Me: “Awesome! What needs to be done?”
Manager: “Our customer needs to have some ConfigMgr work done around Compliance Settings.”
…Compliance Settings in ConfigMgr? This is going to be another quick and easy engagement…nothing too difficult or strange to worry about…
Me: “Great! I’m in.”
…famous last words…
There was much more conversation than that, but I will spare you the details and just cut to the kick-off call with the customer…
Customer: “We have a security audit approaching, and we need to apply security settings to our servers and workstations. As well as be able to document and convey our strategy moving forward according to our security specifications.”
Me: “No problem, what exactly are we looking at doing? Don’t you already have Active Directory GPO to set these?”
Customer: “We do… but moving forward as an organization we are moving away from GPO for many of the ‘STIG’ settings and want to leverage ConfigMgr to accomplish our goals.”
Me: “STIG settings?”
Customer: “Yup.”
…I’ve not had to do much with STIG settings in the past because these were always handled by the various security teams. Surely I was selected for this project by mistake, right? But I like to think that I’m an intelligent guy, I can figure this out..let’s roll with it…
Me: “OK, do you have the settings rules identified and your organizational settings documented?”
Customer: “We do, in total there are close to 3 to 5 HUNDRED security settings that need to be checked, monitored, and remediated when needed on an ongoing basis for Windows Server 2016 alone. We need the same done for Windows Server 2008, 2012, 2012 R2, 2016, 2019, and Windows 10.”
…Did he just say “3 to 5 HUNDRED security settings for Windows Server 2016 alone”??… holy cow that’s a lot…
Me (as if it didn’t even phase me): “No problem, when does it need to be done?”
Customer: “We’d like to have this done yesterday or as soon as possible, because the Federal audit begins in about a month.”
…Hmmm…That’s 3 to 5 hundred settings for each of 6 operating systems…That means a potential of 3,000 settings to check, remediate, and report on in a month for a Federal audit…What have I gotten myself into here?…
Me: “I’m not sure that we can get up to 3,000 settings done in under 4 weeks, but we’re going to try. If we don’t make it by the time the audit starts, we definitely will have a documented strategy in place that we can communicate.”
Customer: “Excellent! That will work. Is Monday good for you as a start day?”
Me: “Works for me!”
The whole time we were on the call, I was searching the internet for everything that I could find about applying STIG settings with ConfigMgr Compliance. Let me just say this…there is a serious lack of documentation around this…
I made the commitment, I better deliver. Time to get to work.
What are some of the ways that I can do this?
Below are simply a few of the ways that we can get this job done. These are in no way intended to be the final word on the subject.
Active Directory Group Policy
We can also create a backup of the policies and then grab the settings we need from the ‘GptTmpl.inf’ file. With the settings we need, we can create INF files to be used to effect the settings desired using ‘secedit.exe’.
During my searches, I found the Microsoft Security Compliance Toolkit. The description of the toolkit from Microsoft says that it is a set of tools that allow administrators to “download, analyze, test, edit and store Microsoft-recommended security configuration baselines for Windows and other Microsoft products, while comparing them against other security configurations.”
After having downloaded the toolkit, I found that it is preconfigured Group Policy Objects that can be imported into the domain. Once imported, we are able to modify the policies to match what internal security teams have determined to be the best for their organizations. This is all well and good, except that many of these settings may not be tested in an environment and carry with them the potential to cause widespread issues upon deployment if they aren’t vetted first. Remember, each environment is different. Different applications, jurisdictions, requirements, work styles, people, and cultures. Also these preconfigured policies may have far more settings configured than what is needed by a particular organization.
Further, if an organization already has a large number of policy objects and filters within the domain that are deployed . The aggregation of these policies and filters can conflict (if they are not planned and modeled properly), and cause performance issues in applying the policies. This can result in policy processing timeouts that are seen by incomplete application of the settings, or policies not being applied at all; as reflected by the errors reported in client event logs.
Tattoo the Local Registry
The term is exactly as it sounds. It means to manual create or import registry settings that remain static on a destination system.
Registry settings will work for a great number of things except policies like renaming guest accounts, renaming administrator accounts, password complexity, and user rights assignments to name a few. If your organization decides that a change or modification is needed, all that needs to be done is to push out the settings with a deployment tool or script that applies the changes through PowerShell remoting, or WinRM. However, if the setting is determined to need removal, we might run into some difficulties if we don’t have a toolset that allows us to perform this action in bulk. The recommendation is to avoid registry tattooing; if it cannot be avoided, only tattoo settings that we know will NEVER change after they are initially set.
Manually Edit the Local Security Policy
Using the command ‘secpol.msc /s’ at the command prompt (elevated), will open up the “Local Security Policy” editor. From here we can go through each of the desired settings and make the changes necessary to effect the security posture as defined by our organization. Of note here is the ability to set a configuration as needed, then export that configuration from the command-line using ‘secedit.exe’. Once we have the configuration exported, we can then import that same configuration onto other systems using different command-line options for ‘secedit.exe’.
This is great if we only have a few dozen systems to manage. When we begin talking about hundreds or even thousands of machines, we need to be looking for a better way (or combining this with other methods).
Use PowerShell Desired State Configuration (DSC)
In Microsoft Docs, there is an article called “Quickstart: Convert Policy into DSC” that describes how to convert Group Policy backups into DSC. This works great if we are converting the canned policies from the Microsoft Security Compliance Toolkit. Mileage may vary when we try to use it on a GPO backup from and existing policy within our domain. The command ‘ConvertFrom-GPO’ within the ‘BaselineManagement’ PowerShell module doesn’t seem to handle the quotes and apostrophes within the legal banner and header text in the GPO correctly. As of January 2021, this has been an issue for almost three years with no movement toward getting it fixed. To get around the issue, you’ll need to modify the ‘GptTmpl.inf’ file within the GPO backup or remove the settings from a copy of the GPO prior to making the backup.
Once we are able to successfully run the ‘ConvertFrom-GPO’ command, a MOF file is created with all of the settings contained in the GPO. This MOF file can then be used to apply our DSC configuration to our target systems.
Please note that to successfully apply the configuration, two additional modules will be needed on the target systems:
Of course, this method is not without its potential issues. If your environment leverages FIPS policies as part of the security configuration, the PowerShell modules needed will not be able to be installed onto target systems. We’ll need to figure out a way to download and install those modules offline in order to have success.
OK, so what now? What’s my path?
Pick a Pony and Ride That Thing!
Ultimately, we chose to do a combination of the following:
- Active Directory Group Policy
- Grab the ‘GptTmpl.inf’ files from GPO backups
- Create custom INF files for each of the non-registry policy settings we need
- Create PowerShell discovery scripts to determine compliance with the settings
- Create PowerShell remediation scripts that run ‘secedit.exe’ to import the custom INF files we created
- Create ConfigMgr Configuration Items for registry policies using a PowerShell script “Convert-GPOtoCI”
- Create ConfigMgr Configuration Items for non-registry policies and leverage the custom discovery & remediation scripts we’ve created
We decided to do the work this way because:
- In order to install PowerShell modules onto the target systems, we would have needed a rollout plan for that including change management because of the potential impact on the environment
- FIPS policies were in place and modules could not be downloaded from the gallery
- ‘Secedit.exe’ was on every target Operating System within scope
- We had time constraints that didn’t allow addition of project effort and scope at the time
With the decision made, we needed to get moving. Time was not our friend.
