In this blog I will show how you can fix Fix Local Security Authority protection bug with active remediations. Since the KB5007651 Microsoft Defender Antivirus update, many people are experiencing problems with LSA Protection on Windows 11 (21&22h2). A message appears that Local Security Authority protection is supposedly off when in reality it is working.

Update 07-07-2023: This issue has finally been fixed with a new release (July the 5th 2023) of update for Windows Security platform antimalware platform KB5007651 (Version 1.0.2306.10002). After the update the error disappears.

 

Several attempts have since been made to fix this, but it is still not resolved. Meanwhile, the option to enable and disable Local Security Authority protection has been removed from Windows Security.

Verifying that LSA works

Before fixing the problem, make sure everything is configured properly. To do this, I use the instructions described here by Microsoft. First, check if LSA protection is enabled on the computer. We do this by looking at the registry key

 "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Lsa"

According to the documentation, the value of RunAsPPL should be 1 or 2 to configure LSA with or without UEFI variable.

Next, we need to see if LSA is started in protected mode. You do this by going to Windows Logs in the event viewer and then selecting the system log. Apply a filter in the system log for Event ID “12.” Next, look for the Source “Wininit.” If LSA was started in protected mode there should be an event “LSASS.exe was started as a protected process with level: 4”.

Now that we know LSA is running in protected mode, we can continue with the fix Local Security Authority protection error. Should LSA not be running, check your settings and reboot the computer to apply them.

Fix Local Security Authority protection error

Since it is basically waiting for Microsoft to fix this issue, we have to fall back on a workaround. Fortunately, there are several workarounds. One workaround to fix this message is to dismiss the error message, but to do this you need local admin rights.

Dismiss Local Security Authority protection error.

Another option is by disabling the Device Security UI through Intune. This will ensure that the exclamation point near the Windows Security Icon in the system tray is no longer displayed.

Disable Device Security UI

But what can you do if you don’t want to hide the Device Security UI, but also don’t want to make users local admin. There is a third solution and that is by adding a the registry value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Lsa\
RunAsPPLBoot - DWORD - 2

You can do this manually, but also using a proactive remediation. This way you can automate it, but also easily undo it when it is no longer needed.

Proactive Remediation

With proactive remediation, you work with two scripts. A detection and a remediation script. The detection script is used to see if certain parameters are set correctly. If the parameters are not correct, then a remediation script is run to correct them. In this case, I use the detection script to see if LSA protection is configured and then to see if the “RunAsPPLBoot” DWORD value 2 is configured.

$Path = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
$Name1 = "RunAsPPL"
$Name2 = "RunAsPPLBoot"
$Type = "DWORD"
$Value1 = 1
$Value2 = 2

Try {
$Registry = Get-ItemProperty -Path $Path -Name $Name1 -ErrorAction Stop | Select-Object -ExpandProperty $Name1
If ($Registry -eq $Value1){
$RunasPPLBoot = Get-ItemProperty -Path $Path -Name $Name2 -ErrorAction Stop | Select-Object -ExpandProperty $Name2
if($RunasPPLBoot -eq $Value2){
Write-Output "Compliant"
Exit 0
}}
elseIf ($Registry -eq $Value2){
$RunasPPLBoot = Get-ItemProperty -Path $Path -Name $Name2 -ErrorAction Stop | Select-Object -ExpandProperty $Name2
if($RunasPPLBoot -eq $Value2){
Write-Output "Compliant"
Exit 0
}} 
Write-Warning "Not Compliant"
Exit 1
} 
Catch {
Write-Warning "Not Compliant"
Exit 1
}

else {
Write-Output "Compliant"
Exit 0}

If it is configured correctly an “Exit 0” is generated and nothing else happens. If something needs to be corrected an “Exit 1” is generated which triggers the Remediation script. In the remediation script, the value is changed to “RunAsPPLBoot” DWORD value 2.

$Path = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
$Name = "RunAsPPLBoot"
$Type = "DWORD"
$Value = 2

Set-ItemProperty -Path $Path -Name $Name -Type $Type -Value $Value

Create a new script package in proactive remediations. Select the detection and remediation script. Leave all settings as they are except “Run script in 64-bit PowerShell” here you should select “yes” and assign the policy to a group. Change the schedule after how often you want the script to run. In this example I select every hour.

Wait for the proactive remediation to be performed. After the Proactive Remediation is executed, reboot the computer (If you want, you could add this to the remediation script). After the reboot, the message disappears.

 

Use of the scripts listed above is at your own risk. Always test the scripts yourself before using them. I hope you benefit from this blog post. If you have any comments please leave a comment.