1

I have an AppLocker policy that allows only scripts signed with a certificate from my company. This is the only script policy, no default created.

When I run a Windows PowerShell 5.1 or PowerShell 7 console (tried all this inside console and Terminal) on a Windows 11 machine, $ExecutionContext.SessionState.LanguageMode returns correctly ConstrainedLanguage (PowerShell 7 displays this information directly when launched)

I have got this very simple non signed script :

$ExecutionContext.SessionState.LanguageMode
[System.Console]::WriteLine("Hello")

When I type within the console the second line [System.Console]::WriteLine("Hello"), I got the expected error :

Cannot invoke method. Method invocation is supported only on core types in this language mode.
At line:1 char:1
+ [System.Console]::WriteLine("Hello")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : MethodInvocationNotSupportedInConstrainedLanguage

But, when I run the script, here is the output :

FullLanguage
Hello

If I test the AppLocker rule with

Get-AppLockerPolicy -Effective | 
    Test-AppLockerPolicy -Path C:\Tests\test.ps1 -User Install #("Install" is my test user)

It returns correctly :

FilePath           PolicyDecision MatchingRule
--------           -------------- ------------
C:\Tests\test.ps1 DeniedByDefault

If I add a new AppLocker rule which denies to everyone for all paths, it returns correctly :

FilePath          PolicyDecision MatchingRule
--------          -------------- ------------
C:\Tests\test.ps1         Denied *

and when I run the script, I have got the same result, the script is running in FullLanguage Mode.

If I call the script within another one (or even itself), despite the first script still executes into FullLanguage Mode, I got the expected behavior for the script call :

C:\Tests\test.ps1: C:\Tests\test.ps1:3
Line |
   3 |  C:\Tests\test.ps1
     |  ~~~~~~~~~~~~~~~~~
     | The term 'C:\Tests\test.ps1' is not recognized as a name of a cmdlet, function, script file, or executable
     | program. Check the spelling of the name, or if a path was included, verify that the path is correct and try
     | again.

If I apply a Device Guard UMCI Policy while keeping my AppLocker policy, the script is correctly running in ConstrainedLanguage. This complains with the Microsoft statement (the blocked scripts throw error 8007 in event log but run in constrained mode). Script files are not members of the Device Guard UMCI Policy, only the signer is, and signed scripts are running in ContrainedLanguage too... but they should run in FullLanguage...

Any idea why this script is running in FullLanguage mode despite it is not signed, and why with UMCI policy, signed script is running in ContrainedLanguage Mode despite the signer is part of both policies (UMCI and AppLocker) ?

Thanks

CFou
  • 81

1 Answers1

0

Update: This is fixed in PowerShell 7.4.10 and appears to be fixed in Windows PowerShell in Windows 11 24H2 by KB5058411 (May 2025).

The underlying issue is root-caused by MVP Rudy Ooms in: https://patchmypc.com/windows-11-24h2-applocker-powershell-constrained-language-broken

The root-causing shows why it affects Windows 11 23H2 for PowerShell 7.4, but not Windows PowerShell (the API-related changes are available in Windows 11 23H2 and so PowerShell 7.4 uses them, but Windows PowerShell only picked up the implementation changes with Windows 11 24H2.)

The fix for PowerShell 7 can be seen here:

There is no changelog/release notes item for Windows PowerShell. Test to verify.

I'm assuming you never got a proper resolution to this.

I have reproduced and verified the behaviour you're experiencing for Windows 11 24H2, as of the 2025-02 updates. It does not occur on Windows 11 23H2 with its 2025-02 updates - AppLocker functions as expected. (Both clean installs, no ADDS or Entra join, no policies applied, just create the default AppLocker script rules in gpedit and set it to Enforce)

Microsoft does not appear to have acknowledged it as an issue. I will open a support case with Microsoft. I don't have great experience with MS Support, but I'll update as appropriate.

davis
  • 1