Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Security baseline (DRAFT): Windows 10 and Windows Server, version 2004
Published May 27 2020 10:00 AM 29.9K 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.

Version history
Last update:
‎Nov 29 2021 08:37 AM
Updated by: