Microsoft Security Guidance blog

Moving to a new blog platform

Aaron Margosis — Wed, 19 Jun 2019 21:55:59 GMT

The content on Microsoft's MSDN and TechNet blog platforms will soon become read-only. Look for future blog posts about Microsoft's security configuration baselines and the Security Compliance Toolkit on the new Microsoft Security Baselines Blog, along with a new Microsoft Security Baselines discussion space. We have also migrated our most important posts on this site to the new site. Do stay tuned! We will be posting an update to the Office 365 ProPlus security baseline soon.

Security baseline (FINAL) for Windows 10 v1903 and Windows Server v1903

Aaron Margosis — Thu, 23 May 2019 14:04:14 GMT

Microsoft is pleased to announce the final release of the security configuration baseline settings for Windows 10 version 1903 (a.k.a., “19H1”), and for Windows Server version 1903. Download the content from the Microsoft Security Compliance Toolkit (click Download and select Windows 10 Version 1903 and Windows Server Version 1903 Security Baseline.zip). Note that Windows Server version 1903 is Server Core only and does not offer a Desktop Experience (a.k.a., “full”) server installation option. In the past we have published baselines only for “full” server releases – Windows Server 2016 and 2019. Beginning with this release we intend to publish baselines for Core-only Windows Server versions as well. However, we do not intend at this time to distinguish settings in the baseline that apply only to Desktop Experience. When applied to Server Core, those settings are inert for all intents and purposes. This new Windows Feature Update brings very few new Group Policy settings, which we list in the accompanying documentation. This baseline recommends configuring only two of those. However, we have made several changes to existing settings, including some changes since the draft version of this baseline that we published last month. The changes from the Windows 10 v1809 and Windows Server 2019 baselines include:

Enabling the new “Enable svchost.exe mitigation options” policy, which enforces stricter security on Windows services hosted in svchost.exe, including that all binaries loaded by svchost.exe must be signed by Microsoft, and that dynamically-generated code is disallowed. Please pay special attention to this one as it might cause compatibility problems with third-party code that tries to use the svchost.exe hosting process, including third-party smart-card plugins.
Configuring the new App Privacy setting, “Let Windows apps activate with voice while the system is locked,” so that users cannot interact with applications using speech while the system is locked.
Disabling multicast name resolution (LLMNR) to mitigate server spoofing threats.
Restricting the NetBT NodeType to P-node, disallowing the use of broadcast to register or resolve names, also to mitigate server spoofing threats. We have added a setting to the custom “MS Security Guide” ADMX to enable managing this configuration setting through Group Policy.
Correcting an oversight in the Domain Controller baseline by adding recommended auditing settings for Kerberos authentication service.
Dropping the password-expiration policies that require periodic password changes. This change is discussed in further detail below.
Dropping the specific BitLocker drive encryption method and cipher strength settings. The baseline has been requiring the strongest available BitLocker encryption. We are removing that item for a few reasons. The default is 128-bit encryption, and our crypto experts tell us that there is no known danger of its being broken in the foreseeable future. On some hardware there can be noticeable performance degradation going from 128- to 256-bit. And finally, many devices such as those in the Microsoft Surface line turn on BitLocker by default and use the default algorithms. Converting those to use 256-bit requires first decrypting the volumes and then re-encrypting, which creates temporary security exposure as well as user impact.
Dropping the File Explorer “Turn off Data Execution Prevention for Explorer” and “Turn off heap termination on corruption” settings, as it turns out they merely enforce default behavior, as Raymond Chen describes here.

Additional changes that we have adopted since publishing the draft version of this baseline include:

Dropping the enforcement of the default behavior of disabling the built-in Administrator and Guest accounts. We had floated this proposal at the time of the draft baseline, and have since decided to accept it. The change is discussed in more detail below.
Dropped a Windows Defender Antivirus setting that applies only to legacy email file formats.
Changed the Windows Defender Exploit Protection XML configuration to allow Groove.exe (OneDrive for Business) to launch child processes, particularly MsoSync.exe which is necessary for file synchronization.

Dropping the password expiration policies. There’s no question that the state of password security is problematic and has been for a long time. When humans pick their own passwords, too often they are easy to guess or predict. When humans are assigned or forced to create passwords that are hard to remember, too often they’ll write them down where others can see them. When humans are forced to change their passwords, too often they’ll make a small and predictable alteration to their existing passwords, and/or forget their new passwords. When passwords or their corresponding hashes are stolen, it can be difficult at best to detect or restrict their unauthorized use. Recent scientific research calls into question the value of many long-standing password-security practices such as password expiration policies, and points instead to better alternatives such as enforcing banned-password lists (a great example being Azure AD password protection) and multi-factor authentication. While we recommend these alternatives, they cannot be expressed or enforced with our recommended security configuration baselines, which are built on Windows’ built-in Group Policy settings and cannot include customer-specific values. This reinforces a larger important point about our baselines: while they are a solid foundation and should be part of your security strategy, they are not a complete security strategy. In this particular case, the small set of ancient password policies enforceable through Windows’ security templates is not and cannot be a complete security strategy for user credential management. Removing a low-value setting from our baseline and not compensating with something else in the baseline does not mean we are lowering security standards. It simply reinforces that security cannot be achieved entirely with baselines. Why are we removing password-expiration policies? First, to try to avoid inevitable misunderstandings, we are talking here only about removing password-expiration policies – we are not proposing changing requirements for minimum password length, history, or complexity. Periodic password expiration is a defense only against the probability that a password (or hash) will be stolen during its validity interval and will be used by an unauthorized entity. If a password is never stolen, there’s no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem. If it’s a given that a password is likely to be stolen, how many days is an acceptable length of time to continue to allow the thief to use that stolen password? The Windows default is 42 days. Doesn’t that seem like a ridiculously long time? Well, it is, and yet our current baseline says 60 days – and used to say 90 days – because forcing frequent expiration introduces its own problems. And if it’s not a given that passwords will be stolen, you acquire those problems for no benefit. Further, if your users are the kind who are willing to answer surveys in the parking lot that exchange a candy bar for their passwords, no password expiration policy will help you. Our baselines are intended to be usable with minimal if any modification by most well-managed, security-conscious enterprises. They are also intended to serve as guidance for auditors. So, what should the recommended expiration period be? If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration? And if they haven’t implemented modern mitigations, how much protection will they really gain from password expiration? The results of baseline compliance scans are usually measured by how many settings are out of compliance: “How much red do we have on the chart?” It is not unusual for organizations during audit to treat compliance numbers as more important than real-world security. If a baseline recommends 60 days and an organization with advanced protections opts for 365 days – or no expiration at all – they will get dinged in an audit unnecessarily and might be compelled to adhere to the 60-day recommendation. Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines. Dropping the enforced disabling of the built-in Administrator and Guest accounts To keep baselines useful and manageable, we tend to enforce secure defaults for policy settings only when 1) non-administrative users could otherwise override those defaults, or 2) misinformed administrators are otherwise likely to make poor choices about the setting. Neither of those conditions are true regarding enforcing the default disabling of the Administrator and Guest accounts. Note that removing these settings from the baseline does not mean that we recommend that these accounts be enabled, nor does removing these settings mean that the accounts will be enabled. Removing the settings from the baselines simply means that administrators can now choose to enable these accounts as needed. The built-in Guest account. The Guest account (RID -501) is disabled by default on Windows 10 and Windows Server. Only an administrator can enable the Guest account, and an admin would presumably do so only for a valid reason such as for a kiosk system. The built-in Administrator account. The local Administrator account (RID -500) is disabled by default on Windows 10 but not on Windows Server. When installing Windows 10, Windows Setup prompts you for a new account which becomes the primary administrative account for the computer. By contrast, Windows Server’s setup prompts you for a new password for the Administrator account. The main differences between the built-in -500 Administrator account (when enabled) and a custom administrative local account are 1) the -500 account is not subject to account lockout, account expiration, password expiration, or logon hours; 2) the -500 account cannot be removed from the Administrators group; and 3) that by default the -500 account always runs with full administrative rights without UAC prompts, including over the network. This third difference can be removed (as our baselines always do) by enabling the security option, “User Account Control: Admin Approval Mode for the Built-in Administrator account.” Our recommendations for administrative local accounts include:

You can choose not to have any administrative local accounts enabled and to administer domain-joined systems only with domain accounts.
If you choose to use local accounts for computer administration, you should have only one administrative local account enabled per computer. With this change in the baseline, you can choose to use the -500 Administrator account or a custom account, according to your needs. Note that if you rely on account lockout for defense against password-guessing attacks, you should not enable the -500 account – and you should consider disabling it on Windows Server.
The administrative local account’s password should be strong and should be different from the same account’s password on every other computer. We recommend the Local Administrator Password Solution (LAPS) or a similar tool to ensure that passwords are random and strong. LAPS can manage the password of the -500 account or a custom named local account on Active Directory domain-joined Windows clients and domain-joined member servers (but not for Domain Controllers). Note also that LAPS’ password-expiration enforcement is independent from Windows’ password-expiration mechanism, and always applies to whatever account LAPS manages.
Renaming the Administrator account is perfectly fine but is “security by obscurity.” Renaming is easy to do through Group Policy and doing so can mitigate some threats, but it’s less than a speedbump against other threats.

Security baseline (DRAFT) for Windows 10 v1903 and Windows Server v1903

Aaron Margosis — Wed, 24 Apr 2019 11:41:42 GMT

Microsoft is pleased to announce the draft release of the security configuration baseline settings for Windows 10 version 1903 (a.k.a., “19H1”), and for Windows Server version 1903. Please evaluate these proposed baselines and send us your feedback via blog comments below. (Note: the final version of this baseline was published here.) As usual, the content includes GPO backups, GPO reports, scripts to apply settings to local GPO, Policy Analyzer rules files for each baseline and for the full set, and spreadsheets documenting all available GPOs and our recommended settings, settings that are new to this Feature Update, and changes from the previous baselines. Note that Windows Server version 1903 is Server Core only and does not offer a Desktop Experience (a.k.a., “full”) server installation option. In the past we have published baselines only for “full” server releases – Windows Server 2016 and 2019. Beginning with this release we intend to publish baselines for Core-only Windows Server versions as well. However, we do not intend at this time to distinguish settings in the baseline that apply only to Desktop Experience. When applied to Server Core, those settings are inert for all intents and purposes. This new Windows Feature Update brings very few new Group Policy settings, which we list in the accompanying documentation. The draft baseline recommends configuring only two of those. However, we have made several changes to existing settings, and are considering other changes. Please review the changes carefully and let us know what you think. The changes from the Windows 10 v1809 and Windows Server 2019 baselines include:

Enabling the new “Enable svchost.exe mitigation options” policy, which enforces stricter security on Windows services hosted in svchost.exe, including that all binaries loaded by svchost.exe must be signed by Microsoft, and that dynamically-generated code is disallowed. Please pay special attention to this one as it might cause compatibility problems with third-party code that tries to use the svchost.exe hosting process, including third-party smart-card plugins.
Configuring the new App Privacy setting, “Let Windows apps activate with voice while the system is locked,” so that users cannot interact with applications using speech while the system is locked.
Disabling multicast name resolution (LLMNR) to mitigate server spoofing threats.
Restricting the NetBT NodeType to P-node, disallowing the use of broadcast to register or resolve names, also to mitigate server spoofing threats. We have added a setting to the custom “MS Security Guide” ADMX to enable managing this configuration setting through Group Policy.
Correcting an oversight in the Domain Controller baseline by adding recommended auditing settings for Kerberos authentication service.
Dropping the password-expiration policies that require periodic password changes. This change is discussed in further detail below.
Dropping the specific BitLocker drive encryption method and cipher strength settings. The baseline has been requiring the strongest available BitLocker encryption. We are removing that item for a few reasons. The default is 128-bit encryption, and our crypto experts tell us that there is no known danger of its being broken in the foreseeable future. On some hardware there can be noticeable performance degradation going from 128- to 256-bit. And finally, many devices such as those in the Microsoft Surface line turn on BitLocker by default and use the default algorithms. Converting those to use 256-bit requires first decrypting the volumes and then re-encrypting, which creates temporary security exposure as well as user impact.
Dropping the File Explorer “Turn off Data Execution Prevention for Explorer” and “Turn off heap termination on corruption” settings, as it turns out they merely enforce default behavior, as Raymond Chen describes here.

In addition, although we have not changed the draft baseline at this time, we are considering dropping the enforcement of the default behavior of disabling the built-in Administrator and Guest accounts. The proposal is discussed in more detail below and we would very much like to get feedback before we proceed with any change. Dropping the password expiration policies. There’s no question that the state of password security is problematic and has been for a long time. When humans pick their own passwords, too often they are easy to guess or predict. When humans are assigned or forced to create passwords that are hard to remember, too often they’ll write them down where others can see them. When humans are forced to change their passwords, too often they’ll make a small and predictable alteration to their existing passwords, and/or forget their new passwords. When passwords or their corresponding hashes are stolen, it can be difficult at best to detect or restrict their unauthorized use. Recent scientific research calls into question the value of many long-standing password-security practices such as password expiration policies, and points instead to better alternatives such as enforcing banned-password lists (a great example being Azure AD password protection) and multi-factor authentication. While we recommend these alternatives, they cannot be expressed or enforced with our recommended security configuration baselines, which are built on Windows’ built-in Group Policy settings and cannot include customer-specific values. This reinforces a larger important point about our baselines: while they are a solid foundation and should be part of your security strategy, they are not a complete security strategy. In this particular case, the small set of ancient password policies enforceable through Windows’ security templates is not and cannot be a complete security strategy for user credential management. Removing a low-value setting from our baseline and not compensating with something else in the baseline does not mean we are lowering security standards. It simply reinforces that security cannot be achieved entirely with baselines. Why are we removing password-expiration policies? First, to try to avoid inevitable misunderstandings, we are talking here only about removing password-expiration policies – we are not proposing changing requirements for minimum password length, history, or complexity. Periodic password expiration is a defense only against the probability that a password (or hash) will be stolen during its validity interval and will be used by an unauthorized entity. If a password is never stolen, there’s no need to expire it. And if you have evidence that a password has been stolen, you would presumably act immediately rather than wait for expiration to fix the problem. If it’s a given that a password is likely to be stolen, how many days is an acceptable length of time to continue to allow the thief to use that stolen password? The Windows default is 42 days. Doesn’t that seem like a ridiculously long time? Well, it is, and yet our current baseline says 60 days – and used to say 90 days – because forcing frequent expiration introduces its own problems. And if it’s not a given that passwords will be stolen, you acquire those problems for no benefit. Further, if your users are the kind who are willing to answer surveys in the parking lot that exchange a candy bar for their passwords, no password expiration policy will help you. Our baselines are intended to be usable with minimal if any modification by most well-managed, security-conscious enterprises. They are also intended to serve as guidance for auditors. So, what should the recommended expiration period be? If an organization has successfully implemented banned-password lists, multi-factor authentication, detection of password-guessing attacks, and detection of anomalous logon attempts, do they need any periodic password expiration? And if they haven’t implemented modern mitigations, how much protection will they really gain from password expiration? The results of baseline compliance scans are usually measured by how many settings are out of compliance: “How much red do we have on the chart?” It is not unusual for organizations during audit to treat compliance numbers as more important than real-world security. If a baseline recommends 60 days and an organization with advanced protections opts for 365 days – or no expiration at all – they will get dinged in an audit unnecessarily and might be compelled to adhere to the 60-day recommendation. Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines. Proposal: Dropping the enforced disabling of the built-in Administrator and Guest accounts To keep baselines useful and manageable, we tend to enforce secure defaults for policy settings only when 1) non-administrative users could otherwise override those defaults, or 2) misinformed administrators are otherwise likely to make poor choices about the setting. The proposal asserts that neither of those conditions are true regarding enforcing the default disabling of the Administrator and Guest accounts. Note that removing these settings from the baseline would not mean that we recommend that these accounts be enabled, nor would removing these settings mean that the accounts will be enabled. Removing the settings from the baselines would simply mean that administrators could now choose to enable these accounts as needed. The built-in Guest account. The Guest account (RID -501) is disabled by default on Windows 10 and Windows Server. Only an administrator can enable the Guest account, and an admin would presumably do so only for a valid reason such as for a kiosk system. The built-in Administrator account. The local Administrator account (RID -500) is disabled by default on Windows 10 but not on Windows Server. When installing Windows 10, Windows Setup prompts you for a new account which becomes the primary administrative account for the computer. By contrast, Windows Server’s setup prompts you for a new password for the Administrator account. The main differences between the built-in -500 Administrator account (when enabled) and a custom administrative local account are 1) the -500 account is not subject to account lockout, account expiration, password expiration, or logon hours; 2) the -500 account cannot be removed from the Administrators group; and 3) that by default the -500 account always runs with full administrative rights without UAC prompts, including over the network. This third difference can be removed (as our baselines always do) by enabling the security option, “User Account Control: Admin Approval Mode for the Built-in Administrator account.” The proposed recommendations for administrative local accounts include:

You can choose not to have any administrative local accounts enabled and to administer domain-joined systems only with domain accounts.
If you choose to use local accounts for computer administration, you should have only one administrative local account enabled per computer. With the proposed change in the baseline, you could choose to use the -500 Administrator account or a custom account, according to your needs. (Note that if you rely account lockout for defense against password-guessing attacks, you should not enable the -500 account.)
The administrative local account’s password should be strong and should be different from the same account’s password on every other computer. We recommend the Local Administrator Password Solution (LAPS) or a similar tool to ensure that passwords are random and strong. LAPS can manage the password of the -500 account or a custom named local account. Note also that LAPS’ password-expiration enforcement is independent from Windows’ password-expiration mechanism, and always applies to whatever account LAPS manages.
Renaming the Administrator account is perfectly fine but is “security by obscurity.” Renaming is easy to do through Group Policy and doing so can mitigate some threats, but it’s less than a speedbump against other threats.

Issue with SystemGuard Launch setting in Windows 10 v1809 and Windows Server 2019

Aaron Margosis — Fri, 25 Jan 2019 15:52:37 GMT

[Update, 17 April 2019: Microsoft released a fix for this issue in the 2019-03 Cumulative Updates for Windows 10 Version 1809 and Windows Server 2019. See https://support.microsoft.com/kb/4490481 for more information.] Customers that deployed Microsoft’s security baseline for Windows 10 v1809 and Windows Server 2019 on systems with UEFI secure boot enabled might experience device boot failures. The Device Guard GPO setting to enable Virtualization Based Security in the Windows security configuration baselines includes enabling the System Guard Secure Launch (“ConfigureSystemGuardLaunch”) setting which on supported hardware protects the Virtualization Based Security environment from exploited vulnerabilities in device firmware. That setting was newly introduced in Windows 10 v1809 (also known as “Redstone 5” or “RS5”) and thus is only included in our recommended baselines for Windows 10 v1809 and Windows Server 2019. Microsoft discovered a boot issue that could affect systems with the System Guard Secure Launch set to enabled regardless of whether the underlying hardware support for the feature is present. The issue manifests itself after taking an update whereupon the device reboots into a blank screen. The issue has been root caused to a problem with catalog file validation and whether it shows up is highly dependent on set and order of signed components in the boot path so it is not predictable when or whether a system will hit this issue. Microsoft is currently actively working to release a fix for this issue via a Windows update. While Microsoft is working on a solution, Windows 10 v1809 and Windows Server 2019 customers who are affected may revert the “ConfigureSystemGuardLaunch” Group Policy setting to “Not Configured” or configure it to “Disabled” to alleviate this issue. This should be a temporary workaround until this issue is addressed in a Windows update. Note: Removing this setting will not negatively impact systems that do not have the hardware support for System Guard Secure Launch. At the time of this blog post no devices have yet shipped that include hardware support for Secure Launch including all Microsoft Surface devices and any other OEM devices. The first devices with this support included are not expected to be available on the market until the 2^nd quarter of calendar year 2019.

Remote Use of Local Accounts: LAPS Changes Everything

Aaron Margosis — Mon, 10 Dec 2018 20:10:05 GMT

Long overdue post revisiting the question about whether and when to block the use of local accounts, particularly for remote administration.

Beginning in 2014 with our baselines for Windows 8.1 and Windows Server 2012R2, our security baselines have been blocking remote use of local accounts. Back then, Windows had yet to offer anything resembling secure management of administrative local account credentials. It was typical for an entire organization to have an administrative local user account with the same username and password on every Windows computer. One problem with that is that the common password often becomes a well-known secret over time with no way to revoke access from anyone who ever received it. But by far the biggest problem is that an attacker with administrative rights on one machine can easily obtain the account’s password hash from the local Security Accounts Manager (SAM) database and use it to gain administrative rights over the other machines using “pass the hash” techniques.

In May 2015, Microsoft released the Local Administrator Password Solution (LAPS). LAPS is an elegant and lightweight mechanism for Active Directory domain-joined systems that periodically sets each computer’s admin account password to a new random and unique value, storing the password in a secured confidential attribute on the corresponding computer object in Active Directory where only specifically-authorized users can retrieve it.

LAPS changes everything.

Not only does LAPS neutralize both the pass-the-hash and well-known-secret problems, it creates new opportunities for remote management. With LAPS – or in fact, with any solution that makes local account passwords unique and not guessable – using local accounts for remote computer management actually offers some advantages over using domain accounts. They can, that is, provided that their use isn’t blocked by security policy – which our baselines do today.

It’s all about credential hygiene. Good credential hygiene means not exposing credentials on a potentially-compromised system when those credentials can be used to compromise another system. Credentials can be a plaintext password, an account’s NTLM hash, or a Kerberos TGT. Microsoft’s Pass the Hash whitepapers go into detail about which remote logon types and tools expose credentials and which ones don’t.

Let’s say your helpdesk technicians each have a domain account that is granted administrative rights on all workstations in the domain. User Umberto reports computer issues, so Helen helpdesk technician logs on remotely to the workstation using her privileged domain account, not realizing that the workstation has been compromised with credential theft malware. Depending on how Helen logged on, her account credentials could be stolen and the thief can now gain administrative control over all workstations. All the technicians might follow the whitepapers’ recommendations, but they must do it the right way every single time. One technician with a privileged account making one mistake just one time can lead to a domain-wide compromise.

Let’s say instead of using a privileged domain account, Helen helpdesk technician retrieves the LAPS password for the workstation and uses the LAPS-managed administrative local account to log on. Credential theft is not a problem. If the thief gets the hash or even the plaintext password, it’s useful only on the computer that the thief already controls. So Helen can use whichever logon type or remote tool is most convenient for the work being performed.

Note: One caveat about using remote desktop: do not enable drive redirection for your local volumes when connecting to a potentially-compromised system. And avoid clipboard redirection as well. This caveat applies whether you’re using a LAPS-managed account, /restrictedAdmin, or anything else.

If you have deployed LAPS or another local account password management solution and you want to use local accounts for the remote administration of Windows computers, you need to change three of the Computer Configuration settings that we recommend in the baselines for Windows client and Windows Server in the Member Server role. We recommend these changes only if you plan to use LAPS-managed local accounts for remote administration. Note also that the local-policy scripts included with the Windows 1803 and 1809 baseline packages include “Non-Domain” options that implement these same changes.

*Policy path*	Windows Settings\Security Settings\Local Policies\User Rights Assignment
*Policy name*	Deny access to this computer from the network
*Baseline setting*	Win client: NT AUTHORITY\Local Account Win Server: NT AUTHORITY\Local account and member of Administrators group
*Updated setting*	[empty]

*Policy path*	Windows Settings\Security Settings\Local Policies\User Rights Assignment
*Policy name*	Deny log on through Remote Desktop Services
*Baseline setting*	NT AUTHORITY\Local Account
*Updated setting*	[empty]

*Policy path*	Administrative Templates\MS Security Guide ()*
*Policy name*	Apply UAC restrictions to local accounts on network logon
*Baseline setting*	Enabled
*Updated setting*	Disabled

(*) “MS Security Guide” is a collection of custom settings that comes with the security baselines and is represented in SecGuide.admx. You can configure the updated setting directly by configuring the registry value LocalAccountTokenFilterPolicy to REG_DWORD value 1 in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.

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

Aaron Margosis — Tue, 20 Nov 2018 23:48:58 GMT

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.
[Update to this text, Dec 27 2018] Removed the configuration of the "Increase scheduling priority" user rights assignment, as the default is good and is unlikely to be modified by a misguided administrator or malicious actor. In addition, the Windows default recently changed and is now granted to Administrators and to "Window Manager\Window Manager Group," under which Dwm.exe processes execute. Our previous guidance was overriding the new default.
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.

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

Aaron Margosis — Mon, 01 Oct 2018 04:56:02 GMT

Microsoft is pleased to announce the draft release of the security configuration baseline settings for Windows 10 version 1809 (a.k.a., “Redstone 5” or “RS5”), and for Windows Server 2019. Please evaluate these proposed baselines and send us your feedback via blog comments below. (Note: the final version of this baseline was published here.) 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 Policy Analyzer file (MSFT-Win10-v1809-RS5-WS2019-DRAFT.PolicyRules). 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.
BaselineDiffs-to-v1809-RS5-DRAFT.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-DRAFT.xlsx:

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 hereand 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.
- Enabled the “Require UEFI Memory Attributes Table” option.
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.
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!)
Removed Credential Guard from the Domain Controller baseline. (Credential Guard is not useful on domain controllers and is not supported there.)
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 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
LGPO.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

Policy Analyzer - minor update

Aaron Margosis — Fri, 29 Jun 2018 21:50:30 GMT

Policy Analyzer is a utility in the Security Compliance Toolkit for analyzing and comparing sets of Group Policy Objects (GPOs). We have just posted a minor update that resolves a localization bug reading some non-English advanced auditing settings files (audit.csv), and another bug that would cause Policy Analyzer to crash when reading an invalid GPO backup XML file. Policy Analyzer should be completely bug free now. :) The download package also adds PolicyRules files for the four Windows and Office baselines we have published since Policy Analyzer was last updated.

Security baseline for Windows 10 "April 2018 Update" (v1803) – FINAL

Aaron Margosis — Mon, 30 Apr 2018 22:52:00 GMT

Microsoft is pleased to announce the final release of the security configuration baseline settings for Windows 10 “April 2018 Update,” also known as version 1803, “Redstone 4,” or RS4. Download the content from the Microsoft Security Compliance Toolkit (click Download and select Windows 10 Version 1803 Security Baseline.zip). The downloadable attachment to this blog post (which will be incorporated into the Security Compliance Toolkit shortly) includes importable GPOs, scripts for applying the GPOs to local policy, custom ADMX files for Group Policy settings, all the recommended settings in spreadsheet form and as a Policy Analyzer file (MSFT-Win10-v1803-RS4-FINAL.PolicyRules), and a Policy Analyzer-generated spreadsheet showing the differences from the RS3/v1709 baseline. The only change from the draft version of this baseline is that after discussion we have removed the recommendation to configure the “Microsoft network server: Amount of idle time required before suspending session” security option. Enforcing that setting does not mitigate a contemporary security threat. The differences between this baseline package and that for Windows 10 v1709 (a.k.a., “Fall Creators Update,” “Redstone 3”, RS3) include:

Two scripts to apply settings to local policy: one for domain-joined systems and a separate one that removes the prohibitions on remote access for local accounts, which is particularly helpful for non-domain-joined systems, and for remote administration using LAPS-managed accounts.
Increased alignment with the Advanced Auditing recommendations in the Windows 10 and Windows Server 2016 security auditing and monitoring reference document (also reflected here).
Updated Windows Defender Exploit Guard Exploit Protection settings (separate EP.xml file).
New Windows Defender Exploit Guard Attack Surface Reduction (ASR) mitigations.
Removed numerous settings that were determined no longer to provide mitigations against contemporary security threats. The GPO differences are listed in the “Delta RS3 to RS4 baseline.xlsx” spreadsheet in the package’s Documentation folder. (Since the draft release of the RS4 baseline, we removed one more setting: “Microsoft network server: Amount of idle time required before suspending session.”)

After the draft baseline was released, Windows added another GPO setting that we considered adding to the baseline but ultimately decided not to configure at this time. The GPO path is Computer Configuration\Administrative Templates\System\Credentials Delegation\Encryption Oracle Remediation. You can read information about the setting here and here. (Note that the term “Oracle” here refers to a cryptographic concept and not to anything having to do with Oracle Corporation or its products.) While we recommend patching systems and incorporating this setting as soon as possible, we opted not to include it in the baseline for broad use in the short term because if all servers and clients aren’t patched in a timely fashion the setting will block remote desktop connections. We anticipate incorporating this setting in the next baseline that we publish. When we published the draft baseline for RS4, we requested feedback about replacing the firewall’s logging facility with Advanced Auditing, such as by auditing failure events for Filtering Platform Connection. At this time, we’re going to keep the baseline as it is rather than introduce more changes. But remember that the baseline is just that: a starting point. If monitoring security events works better for you than monitoring firewall logs, do so. Or if you want to use both, do so. Windows 10 v1803 (RS4) has greatly expanded its manageability using Mobile Device Management (MDM). However, our mapping from the baseline’s GPO settings to MDM is not ready to publish at this time. We will publish the baseline in MDM form as soon as it is ready.

Security baseline for Windows 10 v1803 “Redstone 4” – DRAFT

Aaron Margosis — Tue, 27 Mar 2018 18:56:14 GMT

Microsoft is pleased to announce the draft release of the security configuration baseline settings for the upcoming Windows 10 version 1803, codenamed “Redstone 4.” Please evaluate this proposed baseline and send us your feedback via blog comments below. (Note: the final version of this baseline was published here.) The downloadable attachment to this blog post includes importable GPOs, scripts for applying the GPOs to local policy, custom ADMX files for Group Policy settings, and all the recommended settings in spreadsheet form and as a Policy Analyzer file (DRAFT-MSFT-Win10-RS4.PolicyRules). The differences between this baseline package and that for Windows 10 v1709 (a.k.a., “Fall Creators Update,” “Redstone 3”, RS3) include:

Two scripts to apply settings to local policy: one for domain-joined systems and a separate one that removes the prohibitions on remote access for local accounts, which is particularly helpful for non-domain-joined systems, and for remote administration using LAPS-managed accounts.
Increased alignment with the Advanced Auditing recommendations in the Windows 10 and Windows Server 2016 security auditing and monitoring reference document (also reflected here).
Updated Windows Defender Exploit Guard Exploit Protection settings (separate EP.xml file).
New Windows Defender Exploit Guard Attack Surface Reduction (ASR) mitigations.
Removed numerous settings that were determined no longer to provide mitigations against contemporary security threats. The GPO differences are listed in a spreadsheet in the package’s Documentation folder.

We’d like feedback regarding an Advanced Auditing setting that we have considered adding to the baseline but haven’t so far. The auditing and monitoring reference, mentioned above, recommends auditing failure events for Filtering Platform Connection. This is somewhat redundant because the Windows client baseline’s firewall configuration logs dropped packets. The Advanced Auditing setting collects richer data, but can add large numbers of events to the Security event log. The reference recommends against auditing successful connections. So, should the baseline:

Stay as it is, with firewall logging only and no Advanced Auditing for Filtering Platform Connection?
Keep firewall logging as it is, and add Failure auditing for Filtering Platform Connection? (This creates duplication between dropped packet logging and failure audit events.)
Keep firewall successful-connection logging only, and replace the recommendation for dropped-packet logging with Failure auditing for Filtering Platform Connection? (An obvious disadvantage is that admins have to look in two places for firewall-related events.)
Another alternative?

Please let us know in the comments below. Thanks.