This week another short blog post about another nice configuration addition to Windows. This time it’s about configuring additional Local Security Authority (LSA) protection for credentials. LSA, which includes the Local Security Authority Server Service (LSASS) process, validates users for local and remote sign-ins and enforces local security policies. Starting with Windows 8.1 and later, additional protection is provided for the LSA, to prevent reading memory and code injection by non-protected processes. That provides added security for the credentials that LSA stores and manages. Not really something new, but it’s good to know that something has changed from a configuration perspective. The protected process setting for LSA can also be configured in Windows 8.1 and later. That would, however, always require the manual creation of a registry setting. That has changed. Starting with Windows 11 version 22H2 these settings are introduced as actual GPO settings and as ADMX-backed settings via the Policy CSP. This post will start with a short introduction about the new setting, followed with the steps to actually configure that setting. This post will end with showing the behavior after applying the configuration.
Important: The intention of this post is not to discuss the usage of LSA protection version Credential Guard. Only to provide guidance with the technical implementation of enabling additional LSA protection. Besides that, I would always say that both technologies are complimentary to each other. For a good read have a look at this article.
Note: This new configuration option is introduced with the new policy definitions for Windows 11 version 22H2. No more manual registry keys required. In the future this might also come to earlier versions of Windows.
Introducing the Local Security Authority configuration options
The additional LSA protection is focused on running LSASS as a protected process. That configuration is now available as a GPO setting in the new LocalSecurityAuthority ADMX-file, and as an ADMX-backed setting in the new LocalSecurityAuthority node in the Policy CSP. That ADMX-file contains a couple of new settings that are available via GPO, and via the Policy CSP. Besides that, the default behavior of Windows has changed. Starting with Windows 11 version 22H2, additional LSA protection will be enabled by default with a new install of a device (not with the upgrade of a device). That does require the device to be (hybrid) (Azure) Active Directory joined and to be capable of hypervisor-protected code integrity (HVCI). When the additional LSA protection is not a standard within the environment yet, that might cause different behavior between old and new devices. Make sure to be familiar with this change. On existing devices running Windows 10 or later, it’s possible to use the new settings that are available via GPO, or via the Policy CSP. The table below provides an overview of those new settings and how those settings can be used.
|AllowCustomSSPsAPs||This policy setting controls whether the LSASS will allow loading of custom security support providers (SSPs) and authentication providers (APs). When enabled, LSASS will allow loading of custom SSPs and APs. And when disabled, LSASS will block custom SSPs and APs from loading.|
|ConfigureLsaProtectedProcess||This policy setting controls whether the LSASS will run as a protected process. When disabled (0) or not configured, LSASS won’t run as a protected process. When enabled with UEFI lock (1), LSASS will run as a protected process and this setting will be stored in a UEFI variable. When enabled without UEFI lock (2), LSASS will run as a protected process and this setting won’t be stored in a UEFI variable. The latter is the default for devices with a new install of Windows 11 version 22H2.|
Important: Unlike most ADMX-backed settings, the ConfigureLsaProtectedProcess policy setting requires an Integer as value that corresponds to the required configuration. Any other String configuration will result in error 0x86000011.
Note: The root node in the Policy CSP is ./Device/Vendor/MSFT/Policy/Config/LocalSecurityAuthority/.
Configuring the Local Security Authority configuration options
When looking at the actual configuration of these new settings in the Policy CSP, and using Microsoft Intune for the configuration, the configuration is actually pretty straight forward. In the future it will probably even become easier. For now, the configuration will still rely on using a custom device configuration profile. The following nine steps walk through the creation of that custom device configuration profile, with the settings to configure LSASS to run as a protected process.
- Open the Microsoft Endpoint Manager admin center portal navigate to Devices > Windows > Configuration profiles
- On the Windows | Configuration profiles blade, click Create profile
- On the Create a profile blade, provide the following information and click Create
- Platform: Select Windows 10 and later as the platform for the configuration profile
- Profile type: Select Templates as the profile type for the configuration profile
- Template name: Select Custom as the template name for the configuration profile
- On the Basics page, specify a valid Name and optionaly a Description and click Next
- On the Configuration settings page (see Figure 1), click Add to add rows for the following custom settings and click Next
- OMA-URI setting 1 – This setting is used to configure the LSASS process to run as a protected process
- Name (1): Provide a name for the OMA-URI setting to distinguish it from other similar settings
- Description: (Optional) Provide a description for the OMA-URI setting to further differentiate settings
- OMA-URI (2): Specify ./Device/Vendor/MSFT/Policy/Config/LocalSecurityAuthority/ConfigureLsaProtectedProcess
- Data type (3): Select Integer as data type for the configuration of the value of the setting
- Value (4): Specify 1 as value to configure LSASS to run as a protected process with UEFI lock
- On the Scope tags page, configure the required scope tags click Next
- On the Assignments page, configure the required assignment and click Next
- On the Applicability rules page, configure the required applicability rules and click Next
- On the Review + create page, verify the configuration and click Create
Important: Keep in mind that the device needs a restart to actually run the LSASS process as a protected process.
Note: At some point in time these settings might become directly available within Microsoft Intune.
Verifying the additional LSA protection
After configuring the additional LSA protection, the easiest method to verify a successful configuration is by looking at the Event Viewer. When the device is restarted, the Event Viewer will show Event ID 12 in the System log that will mention LSASS.exe was started as a protected process with level: 4. That information is shown below on the right in Figure 2. Besides that, it’s possible to simply verify the configuration by testing it. An easy method to test that is by using Mimikatz, as shown below on the left in Figure 2. Using the command
sekurlsa:logonpasswords would previously dump password data in LSASS for currently logged on account (and more), but is now simply denied.
Note: I did notice that using Microsoft Intune the configuration would apply successfully, but the LSA protection was not always active. Not sure why at this moment.
For more information about configuring the Network List Manager policies, refer to the following docs.
20 thoughts on “Easier configuring additional LSA protection”
Is this Custom OMA still required and not implemented into Intune somewhere else?
I haven’t found it in the Settings Catalog yet.
I think it is in the Intune Settings Catalogue now (either it is newly added or was just hard to find).
It is listed under: Device Guard > Credential Guard > Enabled with UEFI Lock.
I assume this is the same thing…
That’s not the same thing. That setting is about Credential Guard.
Every client we’ve tried this at fails, with error -2016281112 (Remediation failed). Any feedback on that?
That can be many things. Have you checked the Event Viewer for some more details?
https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-lsa shows this polic is only applicable to Windows 11, version 22H2+
Thank you Jeff. They’ve updated the documentation. Initially it was mentioned that it would be backported to Windows 10. I’ll update my note.
In the Configuration Profile settings under Defender, I see “Block credential stealing from the Windows local security authority subsystem”. I selected “Block”, but I don’t see this enabling or locking down this setting on my devices.
That setting is used for configuring that Attack Surface Reduction rule.
Hi Peter, there is a bug in this setting: https://www.bleepingcomputer.com/news/microsoft/windows-11-bug-warns-local-security-authority-protection-is-off/
You need an additional registry setting that will fix the UI in Windows.
Thank you for that, Tom!
The interesting part is that the setting to enable the RunAsPPL is just an entry in the registry.
But what if, before implementing an attack, the registry entry is deleted or changed to 0? 🙂
That is correct, Oscar. This is a setting in the Policy CSP, so I expect the setting to be remediated again (I haven’t specifically tested that yet).
That is covered by the lock with UEFI… reg can be deleted but protection is not disabled.
One question: Are you sure this applies to Windows 10 as well? This Microsoft page states it’s only applying to “Windows 11, version 22H2 [10.0.22621] and later”: https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-lsa#configurelsaprotectedprocess
When I assign this policy to Win10 devices, I’m getting the error code “-2016281112” and “0x87d1fde8”.
Thanks for the great work and best regards, Stefan
Thank you for that. They’ve updated the documentation. Initially it was mentioned that it would be backported to Windows 10. I’ll update my note.
Has this been only verified for Windows 11? Thanks.
Yes, but please have a look at the other comments to see what you can expect.