Security baseline (FINAL) for Windows 10 v1809 and Windows Server 2019


Microsoft is pleased to announce the final release of the security configuration baseline settings for Windows 10 October 2018 Update (a.k.a., version 1809, “Redstone 5” or “RS5”), and for Windows Server 2019.

Download the content from the Microsoft Security Compliance Toolkit (click Download and select Windows 10 Version 1809 and Windows Server 2019 Security Baseline.zip).

The downloadable attachment to this blog post includes importable GPOs, a PowerShell script for applying the GPOs to local policy, custom ADMX files for Group Policy settings, documentation in spreadsheet form and as a set of Policy Analyzer files. In this release, we have changed the documentation layout in a few ways:

  • MS Security Baseline Windows 10 v1809 and Server 2019.xlsx – multi-tabbed workbook listing all Group Policy settings that ship in-box with Windows 10 v1809 or Windows Server 2019. Columns for “Windows 10 v1809,” “WS2019 Member Server,” and “WS2019 DC” show the recommended settings for those three scenarios. A small number of cells are color-coded to indicate that the settings should not be applied to systems that are not joined to an Active Directory domain. Cells in the “WS2019 DC” columns are also highlighted when they differ from the corresponding cells in the “WS2019 Member Server” column. Another change from past spreadsheets is that we have combined tabs that used to be separate. Specifically, we are no longer breaking out Internet Explorer and Windows Defender AV settings into separate tabs, nor the settings for LAPS, MS Security Guide, and MSS (Legacy). All these settings are now in the Computer and User tabs.
  • A set of Policy Analyzer files:
    • MSFT-Win10-v1809-RS5-WS2019-FINAL.PolicyRules – a Policy Analyzer file representing all the GPOs in the combined Windows 10 and Server 2019 baselines.
    • MSFT-Win10-v1809-RS5-FINAL.PolicyRules – a Policy Analyzer file representing the GPOs intended to be applied to Windows 10 v1809.
    • MSFT-WS2019-MemberServer-FINAL.PolicyRules – a Policy Analyzer file representing the GPOs intended to be applied to Windows Server 2019, Member Server.
    • MSFT-WS2019-DomainController-FINAL.PolicyRules – a Policy Analyzer file representing the GPOs intended to be applied to Windows Server 2019, Domain Controller.
  • BaselineDiffs-to-v1809-RS5-FINAL.xlsx – This Policy Analyzer-generated workbook lists the differences in Microsoft security configuration baselines between the new baselines and the corresponding previous baselines. The Windows 10 v1809 settings are compared against those for Windows 10 v1803, and the Windows Server 2019 baselines are compared against those for Windows Server 2016.
  • Windows 10 1803 to 1809 New Settings.xlsx – Lists all the settings that are available in Windows 10 v1809 that were added since Windows 10 v1803. (We used to highlight these settings in the big all-settings spreadsheets.)
  • Server 2016 to 2019 New Settings.xlsx – Lists all the settings that are available in Windows Server 2019 that were added since Windows Server 2016. (We used to highlight these settings in the big all-settings spreadsheets.)

Highlights of the differences from past baselines, which are listed in BaselineDiffs-to-v1809-RS5-FINAL.xlsx:

  • Added two new Attack Surface Reduction rules in Windows Defender Exploit Guard: “Block Office communication applications from creating child processes” (which includes Outlook), and “Block Adobe Reader from creating child processes.” Note that these were added since the draft release of these baselines.
  • Since the draft baseline, we removed the “Turn off printing over HTTP” setting in “Computer Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication settings.” This setting had been in our baselines at least as far back as Windows XP because of the mistaken belief that it distinguished between HTTP and HTTPS. Enabling this setting also disables printing over HTTPS, which breaks legitimate and necessary functionality for no security benefit.
  • The MS Security Guide custom setting protecting against potentially unwanted applications (PUA) has been deprecated, and is now implemented with a new setting under Computer Configuration\...\Windows Defender Antivirus.
  • We have enabled the “Encryption Oracle Remediation” setting we had considered for v1803. At the time we were concerned that enabling the newly-introduced setting would break too many not-yet-patched systems. We assume that systems have since been brought up to date. (You can read information about the setting here and here.)
  • Changes to Virtualization-Based Security settings (used by Credential Guard and Code Integrity):
    • “Platform Security Level” changed from “Secure Boot and DMA Protection” to “Secure Boot.” If system hardware doesn’t support DMA protection, selecting “Secure Boot and DMA Protection” prevents Credential Guard from operating. If you can affirm that your systems support the DMA protection feature, choose the stronger option. We have opted for “Secure Boot” (only) in the baseline to reduce the likelihood that Credential Guard fails to run.
    • Enabled the new System Guard Secure Launch setting which will enable Secure Launch on new capable hardware. Secure Launch changes the way windows boots to use Intel Trusted Execution Technology (TXT) and Runtime BIOS Resilience features to prevent firmware exploits from being able to impact the security of the Windows Virtualization Based Security environment.
    • Disabled the “Require UEFI Memory Attributes Table” option. This is a change from the draft release, and is intended to increase compatibility.
    • Removed Credential Guard from the Domain Controller baseline, while retaining the rest of the VBS settings. This is implemented in a new DC-only GPO named “MSFT Windows Server 2019 - Domain Controller Virtualization Based Security.” Note that this is a change from the draft baseline in which we had removed all VBS settings from the DC baseline. (Credential Guard is not useful on domain controllers and is not supported there.)
  • Enabled the new Kernel DMA Protection feature described here. The “External device enumeration” policy controls whether to enumerate external devices that are not compatible with DMA-remapping. Devices that are compatible with DMA-remapping are always enumerated.
  • Removed the BitLocker setting, “Allow Secure Boot for integrity validation,” as it merely enforced a default that was unlikely to be modified even by a misguided administrator.
  • Removed the BitLocker setting, “Configure minimum PIN length for startup,” as new hardware features reduce the need for a startup PIN, and the setting increased Windows’ minimum by only one character.
  • Since the draft release, we removed “Prevent users from modifying settings” from “Computer Configuration\Administrative Templates\Windows Components\Windows Security\App and browser protection,” as it merely enforced a default that non-admins could not override.
  • Enabled the new Microsoft Edge setting to prevent users from bypassing certificate error messages, bringing Edge in line with a similar setting for Internet Explorer.
  • Removed the block against handling PKU2U authentication requests, as the feature is increasingly necessary.
  • Removed the configuration of the “Create symbolic links” user rights assignment, as it merely enforced a default, was unlikely to be modified by a misguided administrator or for malicious purposes, and needs to be changed to a different value when Hyper-V is enabled.
  • Removed the deny-logon restrictions against the Guests group as unnecessary: by default, the Guest account is the only member of the Guests group, and the Guest account is disabled. Only an administrator can enable the Guest account or add members to the Guests group.
  • Removed the disabling of the xbgm (“Xbox Game Monitoring”) service, as it is not present in Windows 10 v1809. (By the way, consumer services such as the Xbox services have been removed from Windows Server 2019 with Desktop Experience!)
  • Created and enabled a new custom MS Security Guide setting for the domain controller baseline, “Extended Protection for LDAP Authentication (Domain Controllers only),” which configures the LdapEnforceChannelBinding registry value described here.
  • The Server 2019 baselines pick up all the changes accumulated in the four Windows 10 releases since Windows Server 2016.

We received and have been evaluating recommendations for more extensive changes to the baselines that we are continuing to evaluate for future releases.

We have replaced the collection of .cmd batch files for applying the baselines to local policy with a single PowerShell script that takes one of these five command-line switches to indicate which baseline you want to apply:

.\BaselineLocalInstall.ps1 -Win10DomainJoined      - for Windows 10 v1809, domain-joined

.\BaselineLocalInstall.ps1 -Win10NonDomainJoined   - for Windows 10 v1809, non-domain-joined

.\BaselineLocalInstall.ps1 -WS2019Member           - for Windows Server 2019, domain-joined

.\BaselineLocalInstall.ps1 -WS2019NonDomainJoined  - for Windows Server 2019, non-domain-joined

.\BaselineLocalInstall.ps1 -WS2019DomainController - for Windows Server 2019, domain controller

A couple of important notes about using the BaselineLocalInstall.ps1 script:

  • PowerShell execution policy must be configured to allow script execution. You can configure this with a command line such as the following:
    Set-ExecutionPolicy RemoteSigned
  • exe must be in the Tools subdirectory or somewhere in the Path. LGPO.exe is part of the Security Compliance Toolkit and can be downloaded from this URL:
    https://www.microsoft.com/download/details.aspx?id=55319

Windows 10 v1809 has greatly expanded its manageability using Mobile Device Management (MDM). The Intune team is preparing documentation about the Microsoft Windows MDM security baseline and how to use Intune to implement the baseline, and will publish it very soon. We will post information to this blog when that happens.


Comments (9)

  1. Can you explain what you mean by: “Removed the BitLocker setting, “Configure minimum PIN length for startup,” as new hardware features reduce the need for a startup PIN, and the setting increased Windows’ minimum by only one character.” Are you suggesting to not use Pre-boot/startup PIN?

    [Aaron Margosis] The pre-boot PIN helps protect against memory attacks such as with DMA that can expose keys without requiring a user to log on. Newer devices (such as those in Microsoft’s Surface line) don’t expose interfaces like external DMA that create that exposure, so the risk of unauthenticated memory attack is drastically reduced, and not worth the cost of not being able to reboot a device unless a human user is physically present and ready to enter the PIN.
  2. Should the Windows Server 2019 baselines be applied to Windows Server 2016 servers? If not, any advice on how to craft WMI filters, since both 2016 and 2019 are version 10.0.x?

    [Aaron Margosis] 2019 baselines have not been tested/validated on 2016, but probably wouldn’t cause significant problems.

    Our AD experts tell me that they recommend against the use of WMI filters, which is why we didn’t include them this time. They say security filtering is a better way to go.

    1. Can you expand on that , since this is a major departure from previous practices? Would you just create groups for each OS and use a powershell script to populate them? The consequence would be that new systems would not immediately apply baselines. Also, computers would have to be rebooted after they are added to the group.

      I would be nice if Server 2016 and 2019 were not both really 10.0.x…

    2. I was under the impression that Security Baselines were cumulative and supersede previous versions. Is this incorrect?

  3. ginganinja1 says:

    What’s with the date modified on the template files? the last Draft I downloaded had them all at 11/15/2018. This version has the AdmPwd files as 6/22/2015 and the MSS-legacy as 9/24/2015? Looks confusing when I do a replace on those files to see the old one with a newer modified date.

    [Aaron Margosis] Probably what happened is that you “unblocked” the zip file one time but not the other time. When you don’t “unblock” and then use Explorer to extract files from a zip, a side effect is that it ends up putting the current date and time on the files in your file system instead of the ones that were on the files when zipped, because after it extracts, it applies the same “mark of the web” that was on the zip file.
  4. It would be nice to see any changes between the DRAFT and FINAL versions organized/grouped by Baseline. This would help those of us that start testing using the DRAFT versions identify what needs to be changed in our GPO’s to meet the new FINAL version.

    [Aaron Margosis] That’s a good idea and I’ll add that to the list for the next round. I called out the differences in the blog post, and Policy Analyzer will identify them for you if you want. But would you hand-edit the GPOs, or just import the final baseline as a unit? I think the best way to apply these baselines is to import them and not modify them, and to apply any changes you want with a separate GPO applied at a higher precedence. That makes maintenance easier, and the separate GPO then serves as reliable documentation about the changes you’ve taken.
  5. Are the Domain Security Password requirements going to get updated to be inline with the current (2016) password recommendations?
    https://www.microsoft.com/en-us/research/publication/password-guidance/

    [Aaron Margosis] The issue with the baselines adopting the newer findings from password research is that the full set of recommendations is not something we can apply with available GPO settings. We could drop things like password expiration, but without also blocking the use of common passwords (e.g., P@ssw0rd1) you could be worse off. Microsoft does offer that ability both for Azure Active Directory as well as for on-premises Active Directory, but we can’t yet implement it as a baseline setting.
  6. Rich-GL says:

    So, assume, one has the security baselines for “Win 10 1607” deployed in it’s Active Directory. In the daily life there were created some exceptions to the settings in the security baselines.

    Is there a best practices to migrate from the “Win 10 1607” to “Win 10 1803/1809”?

    How should the new security baselines assigned to the corporate devices?

    We see there a lot of risk, when new group policies are applied to devices running already for a long time. How do you deploy those baselines?

    [Aaron Margosis] We recommend that the baseline GPOs be imported exactly as they are without modification. If there are settings you want to override, do so in a separate “delta” GPO that gets applied at a higher precedence. That way when the baseline gets updated, you just need to replace the baseline GPO without having to reimplement the deltas. The delta GPO also acts as documentation of the changes you decided to take from the baseline.
  7. We ran into an incompatibility with some of our older systems (Lenovo T460s and HP Revolve 810 G1/G2) with the new “System Guard Secure Launch” feature. This exhibited itself as an apparent “failure” of the TPM modules on these systems as, to Windows, the TPMs would either appear as disabled/hidden or would be visible, but inaccessible. This, of course, caused issues with our systems as BitLocker, protected by the TPM, could no longer decrypt the system. After a bit of testing, we found that by enabling the secure launch setting by GPO and rebooting would cause the issue, and then doing the reverse would resolve it.

    We also realized that after enabling the setting via GPO, we had to expressly set it to ‘Disable’ to force it off, instead of just setting it to ‘Not Configured’ as would do with most other group policy settings. I believe this setting effectively “tattoos” the registry when configured and setting it to “Not Configured” simply makes it configurable by local admins again, but doesn’t wipe out the last known setting.

    I was a bit surprised that this setting had this effect, as the wording within the GPO states that it would activate the feature only if supported by the hardware, but I have to figure that these systems may have a physical design issue that causes the failure to happen. Our other, newer systems do not show that the feature is active (assuming viewing via msinfo32 would reflect it accurately), but also did not cause the TPMs to “disappear”.

    I do not know if there is really any work here to be done by Microsoft, but it probably is good that others know to investigate this setting should they encounter similar issues.

Skip to main content