Security baseline (DRAFT): Windows 10 and Windows Server, version 2004

Published 05-27-2020 10:00 AM 19.2K Views

[Update, 8/4/2020: The final version of this baseline released and is now available as part of the Security Compliance Toolkit.]


Microsoft is pleased to announce the draft release of the security configuration baseline settings for Windows 10 and Windows Server, version 2004.

Please download the draft baseline (attached to this post), evaluate the proposed baselines, and leave us your comments/feedback below.

This Windows 10 feature update brings very few new policy settings, which we list in the accompanying documentation. Only one new policy meets the criteria for inclusion in the security baseline (described below), but there are two other policies we want to highlight for your consideration.

LDAP channel binding requirements

In the Windows Server, version 1809 Domain Controller baseline, we created and enabled a new custom MS Security Guide setting called Extended Protection for LDAP Authentication (Domain Controllers only) based on the values provided here. This setting is now provided as part of Windows and no longer requires a custom ADMX. An announcement was made in March of this year and now all supported Active Directory domain controllers can configure this policy. The value will remain the same in our baseline, but the setting has moved to the new location. We are deprecating our custom setting. The new setting location is: Security Settings\Local Policies\Security Options\Domain controller: LDAP server channel binding token requirements.

Note: this new policy requires the March 10, 2020 security update. (We assume that, as security conscious baselines users, you are patching!) Details of that patch are here.

Microsoft Defender Antivirus File Hash

Microsoft Defender Antivirus continues to enable new features to better protect consumers and enterprises alike. As part of this journey we have added a new setting to compute file hashes for every executable file that is scanned, if it wasn’t previously computed. You can find this new setting here: Computer Configurations\Administrative Templates\Windows Components\Microsoft Defender Antivirus\MpEngine\Enable file hash computation feature.

You should consider using this feature to improve blocking for custom indicators in Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP). This new feature forces the engine to compute the full file hash for all executable files that are scanned. This can have a performance cost but we are trying to keep it to a minimum by only generating hashes on first sight.  The scenarios where performance might be impacted would be new executable content being generated (for example, developers) or where you frequently install or update applications.

Because this setting is less helpful for customers who are not using Microsoft Defender ATP, we have not added it to the baseline, but we felt it was potentially impactful enough to call out. If you chose to enable this setting, we recommend throttling the deployment to ensure you measure the impact on your users’ machines.

Account Password Length

In the Windows 10 1903 security baselines we announced the removal of the account password expiration policy. We continue to invest in improving this experience. With Windows 10, version 2004, two new security settings have been added for password policies: ‘Minimum password length audit’ and ‘Relax minimum password length limits’. These new settings can be found under Account Policies\Password Policy.

Previously, you could not require passwords/phrase greater than 14 characters. Now you can! Being able to require a length of more than 14 characters (maximum of 128) can help better secure your environment until you can fully implement a multi-factor authentication strategy. Our vision remains unchanged in achieving a password-less future, but we also recognize that this takes time to fully implement across both your users and your existing applications and systems.

You should be cautious with this new setting because it can potentially cause compatibility issues with existing systems and processes. That’s why we introduced the ‘Minimum password length audit’ setting, so you can see what will happen if you increase your password/phrase length. With auditing you can set your limit anywhere between 1 and 128. Three new events are also created as part of this setting and will be logged as new SAM events in the System event log: one event for awareness, one for configuration, and one for error.

This setting will not be added to the baseline as the minimum password length should be audited before broad enforcement due to the risk of application compatibility issues. However, we urge organizations to consider these two settings. Additional details about these new settings will be found here, once the new article get published in the coming days.

As a reminder, length alone is not always the best predictor of password strength, so we strongly recommend considering solutions such as the on-premises Azure Active Directory Password Protection which does sub-string matching using a dictionary of known weak terms, and rejects passwords that don’t meet a certain score.


Finally, we do have some enhancements for LGPO and Policy Analyzer coming. We will go into more details on these enhancements in a future blog post!

Baseline criteria

We follow a streamlined and efficient approach to baseline definition when compared with the baselines we published before Windows 10. The foundation of that approach is essentially:

  • The baselines are designed for well-managed, security-conscious organizations in which standard end users do not have administrative rights.
  • A baseline enforces a setting only if it mitigates a contemporary security threat and does not cause operational issues that are worse than the risks they mitigate.
  • A baseline enforces a default only if it is otherwise likely to be set to an insecure state by an authorized user:
    • If a non-administrator can set an insecure state, enforce the default.
    • If setting an insecure state requires administrative rights, enforce the default only if it is likely that a misinformed administrator will otherwise choose poorly.

For further illustration, see the “Why aren’t we enforcing more defaults?” section in this blog post.

As always, please let us know your thoughts by commenting on this post.

Regular Contributor

This is great. I'm currently working on implementing the Baseline for Server 2019. Still need to do a lot of cleanup before.


I have one big question! Do your security settings baselines that are unset or not configured force that value into the security settings database?


Because when you import a security template, then settings that are unset or not configured are actually ignored and the old value stays in the local security settings database. I would be curious to know how your baseline does this, because that would simplify my cleanup before applying the baseline.


@Daniel Niccoli if I understand your question correctly.  If the value is not defined in our security baseline we will not overwrite anything on the client.  You mention the security template specifically, you can review the GP Reports, or the spreadsheet (Security Template tab) and will see which exact settings we adjust as they relate to the security template.  If there is a value in the column then we would adjust that specific setting but if the cell is blank we will not touch that setting.


For cleanup have you considered using Policy Analyzer?  We have many customers that start with it to identify where the conflict would be.


New Contributor

@Daniel Niccoli , Definitely check out the policy analyzer! Note, you will need to make a backup of each of your affected GPO's and then create a policy rule that includes those GPO's.

@Rick_Munck, On that topic, in the documentation, can you add details on the included Policy Rules? Example, what MSFT Baseline GPO's are included in each. It's a bit confusing when attempting to compare in-production GPO's to MSFT Baseline GPO's...


@Brian Steingraber thanks for the feedback and would like to know a little bit more about your ask so we can see about accommodating.  You are referring to the MSFT-Win10-WS-v2004-DRAFT.PolicyRules file correct?  Inside that file contains all the GPOs that are part of the release.  As I am sure you know they can be filtered under View -> GPO Filter.  Are you asking for each baseline GPO to have it's own PolicyRules file or to rename the actual PolicyRules file to better articulate what is inside?

New Contributor


"Are you asking for each baseline GPO to have it's own PolicyRules file or to rename the actual PolicyRules file to better articulate what is inside?

Yes, either of those solutions would work. Corresponding documentation that simply lists which baseline GPO each PolicyRule file includes would work as well.



Thanks @Brian Steingraber that helps and we appreciate the feedback!  Let me discuss within our team and see a way in which we might be able to address this.  If others have ideas on this please also let us know!  

New Contributor


Thanks Rick.

Special thank you for pointing out that filtering capability (View > GPO Filter). I did NOT know that. That allows for comparing GPO to GPO much easier!

I've searched for Documentation on the Policy Analyzer but have been unsuccessful in finding any...

Edit: Disregard the unable to find documentation. I was looking on the web. The documentation is included in the Policy Analyzer folder... :facepalm:

Senior Member

In the 2004 spreadsheet on the Security Template sheet, under Windows Server DC Column, it says to set the "Domain member: Maximum machine account password age" to 30 days when the policyrules file and the GP reports show that setting is unset.

Valued Contributor

Very helpful features and thank you for sharing.

Windows Defender Antivirus File Hash is good when we have users who are using important and sensitive data but they are not much care about security and downloading any file and easily could be tricked.

It is good additional defense layer.


@CollinWooldridge thanks for pointing that out.  Seems documentation got the best of us on that setting.  We will be sure to fix that in the final release!

Regular Visitor



I installed the latest available GPO templates for Windows 10 (2004), but I am not seeing GPO settings for Microsoft Defender that are referred to in the article. A cursory search of Google didn't reveal where I might download these GPO templates. All of my defender settings are still under Windows Defender. 


I am also not seeing GPO settings referred above in relation to the Minimum password length audit, nor the Relax Password Lengths. I must be missing something. 


I was able to see and configure the new LDAP Channel Binding requirements setting. Thanks for that!

Regular Visitor

Sorry. Figured it out. Thanks!

Occasional Contributor

Sorry for joining the conversation so late. @Brian Steingraber - in addition to the GPO filter, you can see which GPO (or GPOs) each setting belongs with in the lower pane. See the Options menu to control what's shown.

If you want to take a .PolicyRules file and split it by GPO into multiple PolicyRules files, see the Split-PolicyRules script that is included in the Policy Analyzer download. But one of the big benefits of Policy Analyzer is its ability to treat a set of GPOs as a single cohesive unit, particularly for comparison against other sets of GPOs. E.g., if you want to compare the v2004 baselines against the v1909 baselines. If each PolicyRules file represented just one GPO, there would be nothing but differences - e.g., there's no overlap between the BitLocker and WDAV GPOs.

Occasional Contributor

Hello.  The mechanics of the package are fine, but the GPO ID's in the MapGuidsToGpoNames.ps1 are the old ones from 1909.  The names have been updated but not the IDs, which threw me off when I tried to import them using Powershell :)

Occasional Contributor

@MecroTech - the names and GUIDs shown in the MapGuidsToGpoNames.ps1 file are there just to show an example of what the output can look like. Run MapGuidsToGpoNames.ps1 and point it to the GPO backup root directory and it will report the names and GUIDs of whatever GPOs you're pointing to.

(Unless the actual script code needs to be updated, MapGuidsToGpoNames.ps1 shouldn't be updated at all. The comments/documentation are good as they are.)

Senior Member

This Baseline based on GPO templates - any chance to obtain the same information based on Intune templates?



@Serhiy SMAHLYUK yes absolutely.  We are working with the Intune team and they will be coming out with an update as well.

Occasional Visitor


I would like to install a new Server2016 Domain Controller. Which baseline should I use for it? The old one for 2016 or the newest available like this v2004? And should I use the "normal" server member baseline settings AND DomainController baseline settings OR only the DC baseline settings?


Thanks a lot

Occasional Contributor

@Rick_Munck @AaronMargosis_Tanium yes, HasIM asked a good question.


Another question:

GPO applies "Credential Guard Configuration: Enabled with UEFI lock" to a member server and later I want to promote this server to a DC (no CG is possible/advised?) - do have to remove this UEFI lock manually?



@HaslM for the GPO question for DC.  You do not need the DC and MS GPO for a Domain Controller.  If you look at the 2 policies with Policy Analyzer you will see the GPOs are very similar.  We contemplated making the DC GPO additive at one point but haven't yet gone there as it would cause a change that frankly isn't probably worth the churn.


To the question on Server 2016.  This one comes up more often than it shoudl which means we need to get a blog posted on this :)  We said we were going to do it a few months ago and dropped the ball so I will say we will have once posted in the next 30 days (ish).  In the interim let's see if this helps as it will be the jist of the blog.  Ideally we would be able to go back and revisit every baseline at every release but the reality is we cannot.  We would also love to say just implement the latest and you will be good but we cannot say that either.  What we encourage customers to do is 1) evaluate the changes between 2006 and the current Server release with Policy Analyzer and then make an informed decision if any of the updated settings would have a negative effect in your environment.  


@Rafał Fitt to your question.  If deployed with UEFI Lock then yes it would be a physical touch to remove it

Occasional Contributor


Thanks, but there is no "IF" - it is part of "MSFT Windows 10 2004 and Server 2004 Member Server - Credential Guard", so it gets applied to everything and their dog :)

Perhaps a warning for member-server->DC promotion is needed ;)



@Rafał Fitt sorry, we dont have a place to put a warning on every permutation of settings and client/server movements.  We will discuss internally during the next update cycle though in case there is an option.

Version history
Last update:
‎Aug 04 2020 01:16 PM
Updated by: