Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Thursday, July 26, 2018 6:25 PM
Hi All,
AD Environment, DC is 2012, Desktop is Win10, PS version:
Name Value
PSVersion 5.1.14393.2248
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.2248
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
When I launch PowerShell as a non-admin user, I am placed in Constrained Language Mode, despite SRP and AppLocker being disabled. When run as an administrator, this behavior does not appear.
Previously, I had SRP and AppLocker enabled through GPO for testing. It worked as expected so I pulled my computer back into the 'normal' AD group, and disabled Application Identity service. This was probably 3-4 days ago, so it's not just GP being slow to deploy.
I have tried deploying a local SRP - didn't work. Tried deleting that policy. Didn't work. Near as I can tell, this computer is in the same configuration as every other computer, yet PS continues to insist that it must run in Constrained Language mode.
Any ideas or input would be greatly appreciated.
All replies (3)
Thursday, July 26, 2018 8:14 PM
I've also tried applying a 'negative' policy where everything is allowed for everyone, in case the old policy "tattoos" itself until over written, but I didn't seems to get any success doing this either.
Friday, July 27, 2018 2:31 AM
Hi,
You can place a PowerShell session into Full Language mode simply by setting a property:
A value of 0 will result in FullLanguage and value of 4 will shift it to ConstrainedLanguage.
More information in this Microsoft blog
https://blogs.msdn.microsoft.com/powershell/2017/11/02/powershell-constrained-language-mode/
Also, you can Simple Bypass for PowerShell Constrained Language Mode
https://pentestn00b.wordpress.com/2017/03/20/simple-bypass-for-powershell-constrained-language-mode/
Please Note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
Regards
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Friday, July 27, 2018 12:40 PM
The global variable of __PSLockdownPolicy does not exist for me, nor does the corresponding registry key. Creating it as a system variable did not fix the problem, and I did not test creating a user environmental variable as that is not a reasonable fix for 500 accounts across 500 endpoints.
Additionally, while it's great to have a workaround by running an old version of Powershell, I am only interested in a solution that restores my machine to its original configuration. I also already have the work around of launching the PS script as an administrator. I believe I can also sign PS scripts to allow them to run properly, although I haven't tried that.
I am not going to roll out a global GPO that irreversibly breaks any scheduled Powershell script that requires v3, 4 or 5 features and non-core modules and runs as a non-administrative user. I don't know what PS automation we'll be using in the future, but I am not going to be the guy that says "I knew this was a huge flaw in rolling out those GPOs but I did it anyways cause there were hacky workarounds."
I am really looking for a way to reliably revert any changes to the system, so that Powershell:
1) launched as a non-admin
2) with no special switches or arguments
runs in Full Control mode.