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

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.


Comments (24)
  1. mikef2112 says:

    This is awesome….except that these policies generally aren’t up to IT discretion. Until the PCI/SOX/etc guidelines are changed, the compliance departments will force us to continue with the exact same policies and password expiration dates.

  2. >Why are we removing password-expiration policies?

    There are many compliance policies that still take into account password expiration times. Removing this option entirely from the baseline will not help those organizations.

    Also, while it is true that passwords can be broken in less than 15 30 42 60 or 90 days, that’s not the actual risk that password rotation addresses. In practice, password rotation mitigates the risk that passwords shared across multiple environments are still not valid years later. It helps mitigate the real risk that a user password that is captured or breached at a particular time, is not still valid an indefinite time later.

    If we’re going to get rid of password rotation altogether (as also proposed/suggested by newer NIST guidelines), then we should *first* ensure that multi-factor is implemented *everywhere* for all access. First. Otherwise, we are removing one mitigation because of a narrow view of the benefit it does or does not provide, while not automatically replacing it with an option that is more effective. And we are removing it before all compliance standards are onboard. Not helpful.

    [Aaron Margosis] I think you might be misunderstanding what we’re doing. You can still configure password expiration if you want (where “want” can include “we’re forced to by some regulation”). The password-expiration security option is still in Windows and will remain there. We are simply no longer recommending it as part of our GPO-centric security baselines. And as the post says, we recommend better alternatives including MFA and Azure AD Password Protection but those recommendations can’t be expressed within these baselines. As far as “all compliance standards” go, we have no control over them or their timelines, and it doesn’t make much sense for us to wait for them all. We need to be the last to change?

    BTW, none of these controls will help with passwords shared across multiple environments.

    1. Thanks for your response, Aaron. I realized that you were not taking the functionality out of Windows, but having it as an optional part of the baseline is still desirable. Fair point on not needing to wait for every other party to move on something before you do — I could have worded my concern in that area better.

      1. Concerning password expirations, many businesses are following a new NIST guideline for password strength versus frequently or arbitrary changing of passwords. You’re better off with complex passwords or phrases and never changing the password. A lot of folks are buying tools to manage complexity and have dictionary databases of compromised passwords that are updated sometimes daily or more.

        If you suspect compromise, change it. Otherwise I invite you to review the following.

  3. C. Beerse says:

    On the password expiry: Good to see it is not forced from the guidelines. On the other hand, I hope it remains available to be configured just in case other security routines (like Multi factor auth) are somehow not available.

    It would be nice if there is a password expiry that has a time-out based on the password strength. There are several routines that can generate a number for a password quality. Based on the quality, the password expiry can be somewhere from a single day to more than a year. With that, the user can choose to use an easy guessable password and be forced to change it the next day. Or the user is rewarded with a long password expiry if she uses a ‘strong’ password.
    And if there is a user option to use multi factor auth (or such), the user can be rewarded by getting a longer password expriy too.

    [Aaron Margosis] The setting is still available in the security editor. We’re only removing our recommendation to configure it.
    1. Reuvy says:

      No, I meant that it was in the GPO report itself I downloaded – but in the draft only. In the final version released I see it has been removed.

      [Aaron Margosis] Yes, they were accidentally left in the draft GPO reports but they weren’t in the draft GPOs. Fixed in the final, as you point out.
  4. I think that this is a very good and overdue decision. The usage of a complex password combined with a two-factor authentication and a notification of the user (via email or message to the smartphone) of unusual login events / attempts provides a much higher security and faster abuse detection than a regular change of passwords which are easy to remember and thus to guess.

    The situation looks different with service accounts. Here one should use long and complex passwords and rotate them from time to time to prevent them from being abused.

  5. guest23234 says:

    Would the same password expiry policy apply to all account types, i.e administrators, vendors, partners, etc…? Argument can be made that, with the controls in place,i.e MFA, ATA, etc…, the policy should be applied across the board to all those identities.

  6. Collin W says:

    For the PolicyRules files what is the difference between MSFT-Win10-v1903-DRAFT.PolicyRules and MSFT-Win10-WS-v1903-DRAFT.PolicyRules? Thanks.

    [Aaron Margosis] The one with “WS” in the name also includes the Windows Server settings. In other words, it’s the entire set including the Windows 10, Windows Server / Member Server, and Windows Server / Domain Controller settings. In Policy Analyzer, you can use the “GPO filter” feature to look at any subset of the combined set.
  7. I think this is a bad mistake. The research is all about a single threat vector, the end user’s password management. The baseline covers additional threat vectors such as stolen hashes, users disclosing passwords to Helpdesk personnel, shared common development accounts such as database users, typefisting and coffee shop video cameras and probably at least 3-4 other common issues.

    You are actively removing security value from the baseline, and given the new plethora of ID/password files being passed around, used in tools and traded, I’m puzzled that a few research papers examining only a single dimension of the issue would bring about such a policy change where a simple “or additional compensating control” guidance covers the downside without losing the upside.

    [Aaron Margosis] If a user intentionally or unintentionally exposes their password to an unauthorized and malicious actor, and the password expiration is still 40 days away — or even a week away — how much protection does that really provide? Password expiration is not the answer to that kind of problem.
    1. Aaron, it depends on the attacker, but with password dumps like Collections #1-5, passive captures and older video footage and disgruntled former employees, I suspect most of the value is >30 days out. The active threat model, just like the user-risk-only one is IMO too short-sighted.

      I often use old password dumps in the OSINT portions of my testing engagements. If the user’s credential was stolen a year ago and they haven’t had to change it, my job as an attacker becomes trivial. Changing the standard to make trivial attacks easier based on studies that only examine one threat vector is not a good thing.

  8. Since it appears the intent of changing the password expiration baseline is so that customers following a more recent guidance (such as NIST 800-63b Appendix A – ) do not get dinged on reports vs baselines, shouldn’t you also remove password complexity requirements for the same reason? Recent research shows that password length is more important than password complexity ( and there are significant downsides with complexity ( ). If a customer is following a more recent guidance, the above change just reduce the number of dings from 2 to 1. Of course the guidance is also to increase the minimum number of characters. Is it possible to have conditional baselines, where dropping the complexity requirements increases the minimum number of characters?

    It’s a shame Microsoft isn’t able to baseline the other controls at this time.

    [Aaron Margosis] You make a very valid point, of course. We might take up that change in a future baseline. For now, we decided that the biggest gain would be to remove the password-expiration recommendation.

    The baseline establishes minimum password length at 14. We can’t enforce a longer one through the standard Group Policy without using Fine-Grained Password Policies, which like some other recommended alternatives won’t fit in our current security baseline format.

    1. Lacz says:

      For example adding a special character makes a password stronger than adding one additional character to the length only in the case of
      about twenty-character passwords, under this length requiring a one character longer password makes more sense. And special characters are in totally different places on different keyboards so people using a home and an office computer with different keyboards and even different keyboards for different languages (we are more and more) have a big problem with special characters. By the way, Microsoft softwares have some annoying features which do not cater for multilingual work, like in Outlook you cannot change the language of the subject line, t is tied to your keyboard, similarly you cannot change the spellchecking language in different MS Word templates.

  9. Lacz says:

    There is a little mistake in your argument against regular password change: users are normally not notified if someone steals there password. The Linkedin hack was published years later, for example – and it is not necessarily the fault of the provider, they may not notice it. After some hacks the passwords are not utilised immediately but sold or published – thus if you change your password between the hack and the utilisation – which may be months – you are saved. Most people do not check regularly the pages where hacks are published.

  10. Reuvy says:

    You mention that you are “Dropping the File Explorer “Turn off Data Execution Prevention for Explorer” and “Turn off heap termination on corruption” settings,” but they appear in the Computer GPO. What’s the final on this?

    [Aaron Margosis] They’re not in the GPOs of this draft. They are still available in the GPO editor – is that what you mean?
  11. Nebuly says:


    I’m not sure removing the enforcement of both default admin and default guest accounts is something to be desired.

    On the field, I’ve seen plenty of times the first one enabled for various (but never good reasons), mainly lack of knowledge or because it bypasses UAC (or both).
    Many admins still use the default admin account because they reject UAC and least privilege model.
    Many business apps rely on the default admin account to be enabled, Simply because they are too lazy to rework their app to make it compliant with basic security rules. They also want a well-known SID so they don’t have to create a dedicated local account.

    That’s where Microsoft security guidance helps – it’s sometimes the only way for IT or IT security team to prove there is a security concern and have management look at it seriously. If you remove it, business apps will win, because they matter more than security 99,99% of the time. And don’t count on things like “we recommend it but we cannot write it in our guidance”. Those people take what’s written within the guidance, nothing more.
    At least SCM provided why the setting has been configured this way, and the corresponding countermeasure – SCT provides none of that. This is a huge loss.

    As for guest account, if it ain’t broken, Don’t fix it. Don’t tempt developers to do crazy stuff.

    I think you are thinking too much within a highly secured, highly automated datacenter bubble – ten years later, there are still many people recommeding to disable UAC if you app doesn’t work.

    [Aaron Margosis] Would you agree, though, that where “they reject UAC and least privilege model” they’re not using our baselines anyway? For them, nothing in our baselines will matter, right?

    BTW, the built-in admin doesn’t have a well-known SID, it has only a well-known RID (-500), but it’s “well-knownness” doesn’t really make anything easier either.

    We’d also like to make our guidance more consistent between Windows client and Windows Server; the built-in admin is not disabled by default on Server and our baseline guidance doesn’t include a recommendation to disable it, even though the issues involved are pretty much identical between Win10 and Windows Server.

    Re “we recommend it but we cannot write it in our guidance” – to be clear about that, that’s not what we’ve said. There are things we recommend that we cannot include in our baselines because with the way we deliver our baselines today, they need to be generic and cannot include anything that needs organization-specific configuration.

  12. MercuryZ says:

    Did anyone try using “Enable svchost.exe mitigation options” ? As far as I can see the setting doesn’t exist in the new template….

    [Aaron Margosis] Are you sure you have Win10 v1903 installed?
    1. MercuryZ says:

      Yes I’m sure, rest of the settings from the article are there, but not that one.

      [Aaron Margosis] It’s there. Look again. Computer Configuration\Administrative Templates\System\Service Control Manager Settings\Security Settings.
      1. MercuryZ says:

        Most of these settings weren’t there before I added the 1903 ADMXs so I know they’re installed correctly.

        And here I see no “Service Control Manager Settings”. What am I doing wrong?

        [Aaron Margosis] Do you have a ServiceControlManager.admx in %windir%\PolicyDefinitions and a corresponding .adml in a corresponding language subdirectory?

        Take a look at the list of settings in the “New settings in Windows v1903.xlsx” spreadsheet in the zip file’s Documentation folder; those are all the new settings in Windows – are all of those present? Note that the settings in “MS Security Guide” don’t ship in Windows but come with the baseline package.

        [Aaron Margosis] And just to be super-clear: installing the baseline package for v1903 does not install the ADMX files for v1903. Run “winver” to verify the Windows version you’re running.
  13. Please enforce the policy that Disables Password Recovery/Security Questions. This ‘helpful feature’ is dangerous! It represents a persistent, unauditable backdoor into 180x clients across the network.

    Computer Configuration\Administrative Templates\Windows Components\Credential User Interface => Prevent the use of security questions for local accounts

    [Aaron Margosis] We thought about it but opted not to. If you prevent the use of the new security questions feature, it reverts back to the previous “password hint” feature, which is also optional. Which do you prefer?
    1. I’m not a big fan of either, but at least password hints don’t provide a permanent backdoor into the client.

      It is trivial to change the reset questions/answers for accounts in the SAM (including the default 500 RID) and there are multiple toolsets available that automate this process. This ‘feature’ enables persistence for attackers who have already gained initial access – they can reset the admin password and login at will. Manually resetting the password does nothing to mitigate this vulnerability. Not only can attackers get back in on-demand, their manual password resets break LAPS.

      I have also not been able to find an effective way to audit this vulnerability, short of noting when the password resets – but by then it’s too late…

      If forced to pick between two bad options, I would rather deal with lazy end users than provide back-doors for criminals…

      [Aaron Margosis] By “initial access,” do you mean with a non-admin or an admin account? Are you saying that a non-admin can change the “security questions” for any other account, including the -500 admin?
      1. Security question password reset data (hereinafter ‘SQPRD’) for other accounts can only be modified by Admins/SYSTEM, of course, since the data lives in the SAM. (Unless it’s the x-500 account that was initially compromised, since anyone can change their own SQPRD without elevated privileges.)

        I realise that this vulnerability only exists post-compromise (i.e. an attacker must have already gained SYSTEM-level access to that PC), but this situation happens far more often than anyone wants to admit. (‘Assume Breach’ anyone?) Therefore, I would still consider this ‘High Risk’.

        Quite often, the first step taken once gaining elevated rights is to attack the LSA/SAM. If that attack includes modifying SQPRD to known values, the attacker now owns permanent persistence. Regardless of what else occurs defensively (whether the initial malware is detected/removed, the admin password is reset, LAPS and/or AppLocker are employed, and many other preventative/detective/corrective controls), the hacker now Always possesses a permanent way back into that PC – often Without needing any additional software. All they need to do is reset the account password by answering the security questions.

        Additionally, local SQPRD modification is Not something that is easily audited, noticed, or baselined across a domain. (i.e. Admins would likely never know when SQPRD changes and could, therefore, not take any corrective action.)

        I consider this a serious risk in the Post-Exploit/Persistence category. Exploitation will Not grant new/elevated access, but it Will virtually Guarantee an undetectable, codeless backdoor. (‘Codeless’ is the operative word – there is nothing detectable on a PC susceptible to admin password reset once the SQPRD is known to the attacker. To my knowledge, there is also No feasible way of blocking this backdoor without disabling the feature in question – thus my request).

        It is very hard to knock a determined attacker out of a large network when they can constantly reset admin passwords on any unknown number of previously powned clients. LAPS, CredGuard, and AaronLocker[sic] do nothing to mitigate this risk since exploitation only requires using standard OS functionality – technically, it’s ‘feature-misuse’ (rather than an ‘exploit’ which could be blocked via some preventative control).

        My personal feeling is that there should be a way to permanently block (or remove) this feature’s binaries from Business SKUs [Pro/Ent/EDU] (beyond merely setting a policy/regkey which attackers can change). I can’t see a legitimate risk/reward value proposition for SQPRD in centrally-managed networks. (This is not a personal device scenario, wherein the primary user would be permanently locked out of their BitLockered PC should they forget their password.) This ‘feature’ enables attackers to create permanent, codeless, backdoors into any endpoint they have previously compromised – one that cannot easily be identified, audited, or mitigated against [at scale], short of disabling this feature (or resorting to custom/scripted hacks that manage SQPRD like LAPS does passwords).

        Furthermore, in environments not enforcing LAPS and code white-listing, once laterally-usable-local-admin-credentials have been obtained, it should be possible to create ‘file-less’ (memory resident) worms that crawl across the network’s endpoints, resetting SQPRD everywhere (in a matter of minutes).

    2. An entirely different reason is that it would be useful to manage this setting via Intune. The reg settings for the Intune Security Baselines are pulled from this.

Comments are closed.

Skip to main content