locked
Powershell Execution Policy keeps changing. RRS feed

  • Question

  • We're having a problem with Powershell Execution Policies - CurrentUser keeps getting set to Restricted, and it's torpedoing some of our basic admin stuff. It's easy enough to reset it back with a set-executionpolicy -scope, but it'll revert again after enough time, or if you reboot the system/server.

    I thought it must be a GPO, but I've dumped out both user and computers GPOs on an effected user/computer combination and I'm not seeing anything.  Does anyone know what would cuase this?

    Wednesday, July 6, 2016 8:49 PM

Answers

  • Also the GPO update time applies to getting new GPOs from Sysvol. An old GPO could exist as a registry setting or LPOL or something that was never undone, but it wouldn't update on the GPO update duration because it's not a GPO any more.

    All good arguments but none of it has anything to so with PowerShell.  So many companies use PowerShell and have for many years.  Ask yourself why you are the only one reporting this.  It has to be some sort of bug or malware in your systems.  I recommend contacting MS Support and having them help you track down the source. 

    You might first analyze the policy keys in the users hive as the setting has to be persisted in the registry to work.  Also analyze the "All Users/Public" hive and the "Default hive.  The setting must exist in one of these hives.

    Settings for the user are here for PS v3 and later: "HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds"

    They can be in the same location in the other hives and will affect the current user.

    Malware could use this as a DOS exploit.


    \_(ツ)_/

    Thursday, July 7, 2016 3:01 PM
  • THe "CurrentUser" Group Policy settings for PowerShell are here:

    \User Configuration\Windows Components\Windows PowerShell\Turn On Script Execution (settings for signing or other)

    The setting may persist if it is not disabled before it is deleted.  I do not know how the policy engine on the client deals with these settings. They may only be refreshed at logon or on a restart.  There are also cases where the current session gets refreshed in the background.  We do not know how these settings wil effect the users settings.  Microsoft support will have access to the resources that can track this down.

    Open a service ticket. If this is a bug you will not be charged for it.  MS will stick with the problem until it is resolved since it is a show stopper for management of your systems.  It is affecting production systems.  This raises the priority of the support ticket automatically.

    Post back here with your findings as I am sure others would like to know how this can happen.


    \_(ツ)_/

    Thursday, July 7, 2016 3:10 PM

All replies

  • It is a GPO or another admin having fun.

    \_(ツ)_/

    Wednesday, July 6, 2016 9:16 PM
  • Hi,

    well, it can't really be the GPO setting for ExecutionPolicy (that would configure UserPolicy, not CurrentUser). However other options exist ...

    • As jrv said, another admin is having fun (not too likely, too elaborate and small impact for high risk)
    • A poorly written script is messing with you. Search through your scripts for anything that might change the policy (so it very well could be a logon script distributed by GPO).
    • It may be something local on the computer. gwmi win32_startupcommand will show you all that is run at startup. Check those out as well.
    • Check out the locally scheduled tasks, something might be hidden there
    • The Logon script of the AD user might contain surprises, if you have one configured

    Cheers,
    Fred


    There's no place like 127.0.0.1

    Wednesday, July 6, 2016 10:07 PM
  • Hi,

    Below is an article which introduce “15 Ways to Bypass the PowerShell Execution Policy”, may be helpful for you to further identify your problem:
    https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/

    Best Regards,
    Eve Wang

    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 Support, contact tnmff@microsoft.com.

    Thursday, July 7, 2016 6:33 AM
  • I don't think it's a user doing it by hand as it's happening on literally every server and workstation.  We have no GPO logon scripts, all of our scripts are managed by AD, and I can see users that we have confirmed this issue for that have no logon script defined.  I can check local tasks, but they seem unlikely given that it's happening to every computer.  Bypassing the Powershell Execution Policy is all well and good, but doesn't help us with things like all the scripts required for basic Exchange administration.
    Thursday, July 7, 2016 1:55 PM
  • I should also mention - setting the policy and then doing a gpupdate /force doesn't reset it.  The definite trigger is a reboot, or waiting for "a while", where a while seems to be in the realm of 3-7 days.
    Thursday, July 7, 2016 1:58 PM
  • I have confirmed the behavior in Server 2012, Server 2012 R2, Server 2008 R2, Windows 7, and Windows 8.1.
    Thursday, July 7, 2016 1:59 PM
  • It is a GP that has been applied but not removed even if the GPO was deleted.  Some policies persist and must be selected for removal.  There is also a policy that can be used to block all scripts of any kind.  A GPO can also set a registry value directly and it will not appear to be part of PowerShell.

    I suspect that an admin set this at one time but failed to remove the policy before deleting the GPO.  Post in GP forum for help in how to reset this with a GPO.

    Proof: You say it resets with time.  On a DC this might be in 5 minutes and on a workstation 30 minutes.  This is the GP refresh interval.


    \_(ツ)_/


    • Edited by jrv Thursday, July 7, 2016 2:04 PM
    Thursday, July 7, 2016 2:02 PM
  • But as the person above stated (and I can't seem to find anything that contradicts it), you can't set CurrentUser from GPO since the GPO in question is a Computer Policy.  We'd have to do it by pushing a registry key delete.
    Thursday, July 7, 2016 2:48 PM
  • Also the GPO update time applies to getting new GPOs from Sysvol. An old GPO could exist as a registry setting or LPOL or something that was never undone, but it wouldn't update on the GPO update duration because it's not a GPO any more.
    Thursday, July 7, 2016 2:49 PM
  • Also the GPO update time applies to getting new GPOs from Sysvol. An old GPO could exist as a registry setting or LPOL or something that was never undone, but it wouldn't update on the GPO update duration because it's not a GPO any more.

    All good arguments but none of it has anything to so with PowerShell.  So many companies use PowerShell and have for many years.  Ask yourself why you are the only one reporting this.  It has to be some sort of bug or malware in your systems.  I recommend contacting MS Support and having them help you track down the source. 

    You might first analyze the policy keys in the users hive as the setting has to be persisted in the registry to work.  Also analyze the "All Users/Public" hive and the "Default hive.  The setting must exist in one of these hives.

    Settings for the user are here for PS v3 and later: "HKEY_CURRENT_USER\SOFTWARE\Microsoft\PowerShell\1\ShellIds"

    They can be in the same location in the other hives and will affect the current user.

    Malware could use this as a DOS exploit.


    \_(ツ)_/

    Thursday, July 7, 2016 3:01 PM
  • THe "CurrentUser" Group Policy settings for PowerShell are here:

    \User Configuration\Windows Components\Windows PowerShell\Turn On Script Execution (settings for signing or other)

    The setting may persist if it is not disabled before it is deleted.  I do not know how the policy engine on the client deals with these settings. They may only be refreshed at logon or on a restart.  There are also cases where the current session gets refreshed in the background.  We do not know how these settings wil effect the users settings.  Microsoft support will have access to the resources that can track this down.

    Open a service ticket. If this is a bug you will not be charged for it.  MS will stick with the problem until it is resolved since it is a show stopper for management of your systems.  It is affecting production systems.  This raises the priority of the support ticket automatically.

    Post back here with your findings as I am sure others would like to know how this can happen.


    \_(ツ)_/

    Thursday, July 7, 2016 3:10 PM