Understanding Microsoft Security Baselines and Applying Them – Part 2

Importing the Security Baselines into AD easily

The easiest method of importing all the settings into AD is a script that is included with the baselines, it’s stored beneath the Scripts folder named “Baseline-ADImport.ps1″.

In the image above you can see everything that is imported with the Security Baseline for Win10 v1909 and Server v1909. Do you need to use them all? No. You can choose which apply to you, and filter out the ones that you don’t require.

Where should you link the Security Baselines in your OU Structure?

Where to link your Group Policies is a common debate-fueled topic between sysadmins and engineers alike. Its the equivalent of asking what someone’s taste in music is. However, over some time we have developed some guidance that sysadmins can follow from an optimization perspective.

The first and most important aspect, is that you want the GPO applying to the parent OU which will guarantee that the targeted OS will be covered, but not so far up that every device in your domain is processing the GPO. What do I mean exactly? Let me show you.

In the above image you can see the “ideal” structure we propose to customers when we perform the Securing Lateral Account Movement (SLAM) offering from Microsoft Premier Services. The SLAM offering includes a lot of really awesome features which can allow a company to quickly start mitigating lateral account movement attack surface. It is comprised of settings for User Rights Assignments, Windows Firewall, as well as Local Administrator Password Solution (LAPS).

Since we know what we would like to have, we also need to realise what we currently have. Its a very common scenario where we see a client that is using the same old OU structure that they originally deployed with and they just decide its too much effort to move away from that legacy deployment. Our recommendation however is to change to a good structure and this will give you huge benefits in the long-term.

Back on topic however, where do we link the new Security Baselines we just imported to AD?

Lets say we want to deploy the “Windows 10 v1909 – Computer” baseline settings;
We ideally want to link the GPO above the OU where we will have all machines of the same OS type, however not so far up the structure that it applies to everything anyway. We want the GPO to be read and processed as close as possible to the target machine type.

In the image above we have the option of deploying the GPO right at the top of the structure which would be the SLAM OU, however there is a problem with that – it would also be applied to your Tier 1 Servers and every other device beneath the SLAM OU. Ideally I would recommend applying them directly to the Devices OU with WMI Filtering which will allow you to have multiple client OS versions, while still having only the specific OS version being applied to each client OS type. What will that look like?

Creating the Windows 10 v1909 WMI Filter
Select * from Win32_OperatingSystem WHERE Version LIKE "10.0.18363%" and ProductType = "1"

How do you edit the settings and merge your custom settings?

In any organization we always want to have custom settings, and sometimes the baselines dont give us exactly what we want. To extend upon the baselines we will now add your custom settings with a higher precedence above the baselines so that your custom settings will override the baselines.

Now you start seeing your GPO structure taking shape, while most importantly having the security baselines always applying first, and then your custom settings being applied last and overwriting any conflicts from below.

In the image above you can also take special note that I have gone ahead and changed the GPO status to User Configuration Disabled. I did this so that we don’t have any unnecessary processing or a potential performance impact when a user wants to log on.

What to do when things don’t work as expected during Testing?

First and foremost, ALWAYS do thorough testing before deploying Security Baselines into your live environment. I recommend taking a few test client machines that have all your company’s applications installed on them, and run a few testing based on a checklist to verify they work as expected.

In the situation that something breaks, what do we do? Firstly we need to identify what went wrong or which setting is potentially too strict, or not permitting your legacy applications from working correctly. We then have the option to either alter the Security Baseline itself, or create another GPO to “counter” the settings. My advice is to always keep your Security Baselines as provided by Microsoft, and create a differencing GPO with a higher precedence that lowers how strict some settings are.
NB** By removing or reducing the baselines to a less secure setting you are potentially adding additional attack surface to your clients. Do you utmost to rather resolve the core issue than create a workaround to make it work.

How do you revert the settings completely?

You have gone through weeks of testing, tweaking your custom settings, and you have decided to go live and enabled your GPO’s with the correct precedence and its working as it should. Soon after going live your helpdesk is inundated with calls saying that clients cannot work, application x or y is not working as it used to. The first and easiest solution is to disable the links for the GPOs on the Production OU’s, and then force a replication across your environment with the command repadmin /syncall /APe.

Once that replication has taken place, you can then ask your clients to run a gpupdate /force and do a reboot on their systems. It should proceed to revert all the settings you have applied and go back to normal. Once your operation is back up and running you can then do additional testing to identify what happened.

There is a HUGE catch however because some settings will tattoo the system. Tattoo settings are basically some GPO settings that when applied will NOT be removed once the GPO is disabled or removed from the target. How do we identify these settings? The simplest method I know of is by using the little icon next to the GPO setting itself – and if it shows the icon with a small black arrow pointing down, it means the setting will be treated as a preference and will remain once the GPO is removed.

The ideal scenario here is then to reverse the setting you have applied to “undo” it. You would only do that if you find an issue however. Alternatively you could run a registry key audit when the GPO is applied and identify which exact registry keys get changed when a GPO is applied. This would be more specific and allow you to directly alter the regkey itself. As an added bonus, you can usually get the registry key directly from the admx template by editing it and finding the exact setting you want to view. This will then assist you in pushing a new regkey value directly to the affected objects and undoing the problems caused above.

As any example – lets say I disable SMBv1 Server and after pushing the change to your servers you then realise that some of my legacy clients can no longer contact SYSVOL or any CIFS fileshare. You would then have to either edit the GPO and push the “counter” setting or you would just directly alter the registry on the system. Either would resolve the issue – however, be aware that the client would still need to run a gpupdate for the settings to apply. In some very specific instances, you would need a manual intervention here since the client will not be able to pull their new GPO settings from the DC.

Please take caution when directly changing registry keys – it is strongly advised to always make a registry backup before making changes directly. If you do not know how the registry works then its definitely not advisable to be making direct changes via GPO.

Conclusion

In conclusion, we have covered the Security Baselines in Part 1 where we introduced the concept of Security Baselines, explored how to get them into your environment, and some of the tools you can use to compare your baselines. In this article we have covered Importing the Security Baselines, Linking the Security Baselines and using Precedence, how to do testing as well as what to do when things don’t go as expected, and then identifying tattoo settings.

In the final part of the blog post series, we will cover large scale deployments, using multiple links for our Security Baselines, editing delegations to limit/restrict access on your GPOs, as well as optimal deployment methods in a new structure.

Thank you for reading and I look forward to helping you learn more from what we see in the field.
Have a great day ahead.