PS ConstrainedLanguage mode on Windows 10 with SRP

Article
2016-04-01

Question

_{Friday, April 1, 2016 1:33 PM}

We have Windows 10 computers (PS version 5) with SRP (Software Restriction Policy) enabled.

-We realized that when we have PS Version 5 and SRP enabled, the system will put PowerShell into ConstrainedLanguage mode, which prevents some of our PS scripts to run in the user context.

If we try other combinations we can see that things works:
-If we start the PS with elevated admin rights, then PS in admin context run in FullLanguage mode.
-If we disable SRP, then PS in user context will run in FullLanguage mode.
-If we run PS Version 4 (Win 7 or 8) with SRP enabled, then PS in user context will run in FullLanguage mode.

How can we get PS Version 5 with SRP enabled to run in FullLanguage mode under the user context?

/Andreas

All replies (10)

_{Monday, April 4, 2016 6:52 AM ✅Answered | 3 votes}

Hi Andreas,

this is possible. We encountered the same issue when starting to deploy SRP and there is a workaround:

ConstrainedLanguageMode is enabled the moment you block %temp%. That's annoying, as it is the one most important path to block. The workaround works like this:

Whitelist %temp%
Blacklist all subfolders of %temp% ("%temp%\\)
Create a separate block-rule for each extension in %temp% (eg: "%temp%\.exe")

With this WMF5 is tricked and will not enforce ConstrainedLanguageMode.

Cheers,
Fred

PS: In case you are currently in the process of developing an SRP Deployment strategy, you may find this article helpful (it's in German, use a translation software if you need to). It covers many pitfalls (though not the WMF5-Language bug) and has been rather helpful to us when doing the same.

There's no place like 127.0.0.1

_{Monday, April 4, 2016 5:55 AM}

Hi Andreas,

Thanks for the post, generally we would recommend run powershell script with elevated admin rights. Regarding your issue above, I did some searching, but failed to got a solution. You could check the below links for some reference:

https://social.technet.microsoft.com/Forums/en-US/44445864-ee91-4073-9f21-50ab36ec781b/powershell-5-limited-to-constrainedlanguage-language-mode?forum=winserverpowershell

https://technet.microsoft.com/en-us/library/dn433292.aspx?f=255&MSPPError=-2147217396

Or you could post youe issue on the microsoft connect:

https://connect.microsoft.com/

Hope it helps.

Best Regards,

Elaine

Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Monday, April 11, 2016 6:31 AM}

Hi Fred,

Thank you for your answer. This seems to be a solution for our problem.
I would though like to find another solution where we don't have to whitelist %temp%.

I'll continue to look for a solution, so please update me if you find another way to do this.

Thanks,
Andreas

_{Monday, April 25, 2016 7:22 AM}

Hi Andreas,

currently there is no way around this - it's the very thing powershell checks for - however when you implement the third bullet-point (a blacklist rule for each extension) you have an equivalent result as if you had blacklisted %temp%, without affecting powershell.

Cheers,
Fred

There's no place like 127.0.0.1

_{Monday, July 18, 2016 5:46 AM | 4 votes}

I would strongly recommend to NOT create path rule for %temp%, because it makes SRP pretty useless. Instead, you should create a hash rule. Create a .txt file with the following content:

and save the file. Create a hash rule with Unrestricted level against this file and PowerShell will run in full language mode.

Vadims Podāns, aka PowerShell CryptoGuy
My weblog: www.sysadmins.lv
PowerShell PKI Module: PSPKI
Check out new: SSL Certificate Verifier
Check out new: PowerShell File Checksum Integrity Verifier tool.

_{Monday, September 5, 2016 1:32 PM}

I would strongly recommend to NOT create path rule for %temp%, because it makes SRP pretty useless. Instead, you should create a hash rule. Create a .txt file with the following content:
1
and save the file. Create a hash rule with Unrestricted level against this file and PowerShell will run in full language mode.

Vadims Podāns, aka PowerShell CryptoGuy
My weblog: www.sysadmins.lv
PowerShell PKI Module: PSPKI
Check out new: SSL Certificate Verifier
Check out new: PowerShell File Checksum Integrity Verifier tool.

This is the correct answer. Thank you very much for this workaround.

_{Tuesday, December 6, 2016 3:28 PM}

Does not this solution basically say, block everything except for .ps1 files in %temp%? I get that what you proposed greatly reduces the risk exposure but I would say also make sure your execution policy is All Signed, so it should only allow your scripts to run.

_{Tuesday, December 6, 2016 3:39 PM}

Hi Ryan,

actually, no, it doesn't say that. I never made an exception for .ps1. It's all about the path itself. By now, the whole thing is a moot point, since Vadims found a vastly superior solution.

This entire issue has nothing to do with ExecutionPolicy, which is an entirely different issue.

Cheers,
Fred

There's no place like 127.0.0.1

_{Monday, July 30, 2018 5:25 PM}

Where do we save the file? And do we need to restart or anything else special?

Thanks

_{Monday, July 30, 2018 5:33 PM}

Starting with May updates, this workaround is no longer working. Unfortunately, the only way to get full language mode in interactive session with enforced Applocker is to exclude *.ps* files (by adding them in exclusions).

Share via

PS ConstrainedLanguage mode on Windows 10 with SRP

Question

All replies (10)

Additional resources