I don’t have any special knowledge how to “fix” this, but I remember when this came up on the PS MVP lists.
MOST, but not all, PS MVPs disagreed with this decision. In the Spiceworks thread, they link to Vadim Podam’s blog articles on this topic. He is a PS MVP and I agree with his philosophy on these things. From: [email protected] [mailto:[email protected]] On Behalf Of Micheal Espinola Jr Sent: Friday, October 27, 2017 10:29 PM To: [email protected] Subject: Re: [NTSysADM] Application Whitelisting and PowerShell Constrained Language Mode - Problems With Trusted Login Scripts Hmm, I thought in the replies there were a couple of workaround options for types of whitelisting. Absolute path use seemed to have worked in the replies near the very end of the thread. The options seemed dangerous to me, but supposedly worked for those that tried. Sorry if there weren't that didn't apply to your situation. From what I've also read, there does appear to be some bugginess to its application between versions, but unfortunately, I don't have pervasive experience with it. -- Espi On Fri, Oct 27, 2017 at 5:27 PM, Aakash Shah <[email protected]<mailto:[email protected]>> wrote: Hello Espi! Thanks for your reply! That thread describes how to disable Constrained Language mode (CLM), which I had to do on Win7/Server 2008r2 last year (there is a bug with CLM in PSv5 on Win7/Server 2008r2 where no script would run). On Win10 though, it appears to be working more as it’s supposed to, but I’ve encountered at least one of my login scripts which continues to trigger CLM regardless of being whitelisted in AppLocker. Thanks, -Aakash Shah From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Micheal Espinola Jr Sent: Friday, October 27, 2017 4:58 PM To: [email protected]<mailto:[email protected]> Subject: Re: [NTSysADM] Application Whitelisting and PowerShell Constrained Language Mode - Problems With Trusted Login Scripts This discussion in the Spiceworks forums discusses the root cause and has a couple of workarounds: https://community.spiceworks.com/topic/1451109-srp-whitelist-causing-odd-behavior-in-powershell-v5 Unfortunately, I haven't seen anything more definitive. Maybe MBS has some insider knowledge on this. IIRC, you can bypass this issue completely by going back to an older version of PS. -- Espi On Fri, Oct 27, 2017 at 3:09 PM, Aakash Shah <[email protected]<mailto:[email protected]>> wrote: Hello! I was hoping to see if anyone else in the community has encountered this problem: Windows 10 includes PowerShell v5 which includes a new security feature called Constrained Language Mode. This feature is automatically activated when application whitelisting is enabled and prevents PowerShell from running “riskier” code. As I understand it based on everything I have read, as long as AppLocker has a whitelist rule for it, those whitelisted scripts should be exempt from Constrained Language. However, this does not appear to be working on our Windows 10 computers. One of my login scripts that is in a whitelisted folder path fails to run and gives the error “Cannot dot-source this command because it was defined in a different language mode” which I understand to mean it is being blocked by Constrained Language mode. I have other scripts in this whitelisted folder path that are working, but they don’t appear to be triggering Constrained Language. I have confirmed that the script is not being blocked by AppLocker since the logs confirm that the script was allowed to run by AppLocker. To rule out AppLocker path rules being the problem, I also signed the PowerShell script, whitelisted the cert and tried to run it and encountered the same problem. Has anyone else encountered this problem? If so have you found any workarounds for this? My goal is to avoid disabling Constrained Language mode entirely since I am looking to only allow trusted/whitelisted scripts to be exempt from Constrained Language mode. Thanks! -Aakash Shah
