locked
Help with Powershell run execution RRS feed

  • Question

  • We are attempting to run PowerShell through XenApp (streaming just applications to a thinclient without having to stream an entire OS).  I know that is you want to run PowerShell scripts without signing, you should run 

    Set-executionpolicy RemoteSigned

    and it will run it without warnings or issues.  It also ran script located on a network drive the same way.  I also know if you wish to do it with all users on the machine you run:

    Set-executionpolicy RemoteSigned –scope LocalMachine

    and you should have the same result.  When I run the scripts with my account via remote desktop (from my normal workstation), the scripts run just fine.  When I attempt to use another username (from the XenApp machine) that has access to the machine (I even tried elevating the user to admin and got the same results) I get complaints on the script located on the network drive.  It errors out saying the script is not digitally signed.  Why are they different and how can I fix it?

    Monday, April 1, 2013 2:30 PM

Answers

  • The Xen environment mimics that of the server so the execution policy is the same both from remote desktop and that of the vitalized environment.  XenApp just allows the thin client to just access the application it needs, terminal service.  .

    For XeNApp enthusiasts - An App is what used to be called a borderless terminal session or a terminal session with no frame.  ONly th emain WIndow sof the applicaion is visble so it looks like the appis running locally when it is, in fact, a remote terminal session.  Everrything is a terminal session except the look of the Window and the fact that the user is locked into that apps window. No desktop.

    As you noted it should behave exactly like a full terminal server session as far as everything else is concerned. 

    There is one difference. We can choose where to get the profile from.  If we are runniong of of teh calling machines user profile then the settings for PowerSHell, if set, will take precedence over the remote machine settings as long as the user settings are more restrictive. You would need to create a specisl POwerSHell script to check the 'CurrentUser' setting.  If it is set to AllSigned then you will not be able to run scripts.

    Note also that a script donloaded from the Internet may be fully blocked event if RemoteSigned is chosen.  You need to remove the blocking flag.  If you do not know how to do this then copy the contents of the script to a new file created on the UNC machine and test.

    You may also have to use Group POlicy RSOP to determine what settings are being accumulated by both the machine and the user.

    Signing scripts eliminates these issues and using GP to set the policy prevents inconsistency across the network.  Not using GP or setting Allsigned locally will not help you in the future.


    ¯\_(ツ)_/¯

    • Marked as answer by Treyb Monday, April 1, 2013 6:21 PM
    Monday, April 1, 2013 4:54 PM
  • You need to set machine policy in Group Policy to be sure that the policy is not overwriting your local setting.

    Group Polcy has settings for POwerSHell.  This is where we need to set the network default.  It may be set to AllSigned and you are just overriding that on your account.

    Use Group Policy.

    You can also validate the settings with this comamnd:

    Get-ExecutionPolicy -List

    Pay attention to MachinePolicy and UserPolicy

            Scope ExecutionPolicy
            ----- ---------------
    MachinePolicy       Undefined
       UserPolicy       Undefined
          Process       Undefined
      CurrentUser       Undefined
     LocalMachine    RemoteSigned

    Also see:

    help set-executionpolicy -full

    Note the following:

     C:\PS>set-executionpolicy -scope CurrentUser -executionPolicy Undefined
     Description
     -----------
     This command uses an execution policy value of Undefined to effectively remove the execution policy that is set for
     the current user scope. As a result, the execution policy that is set in Group Policy or in the LocalMachine (all
     users) scope is effective.
     If you set the execution policy in all scopes to Undefined and the Group Policy is not set, the default execution p
     olicy, Restricted, is effective for all users of the computer.


    ¯\_(ツ)_/¯

    • Marked as answer by Treyb Monday, April 1, 2013 6:21 PM
    Monday, April 1, 2013 4:33 PM

All replies

  • Just to double-check...what do you get from Get-ExecutionPolicy on the XenApp virtual instance?

    Joshua Honig
    Learn more about data programming at bytecomb.com

    Monday, April 1, 2013 2:47 PM
  • First, the two examples you gave are effectively the same - setting Execution policy and Setting of for the local host are effectively the same.

    Secondly, you run RemoteSigned when you want any script obtained from the network be digitally signed. You should read the online help around the implications of this (ie what it allows to run and what it doesn't).

    Personally, I am not a strong advocate of Digital signing of scripts, unless you do it as part of a much wider PKI in Admin initiative complete with smartcards, etc. Remember turning on script signing does not really stop that code being run - one just cuts/pastes the code into ISE, and runs it directly from the Editor window. Or you copy the script locally, then run it. So it's not really much of a deterrent. It also has the byproduct of probably requiring you to have a PKI infrastructure (ie to sign scripts) in place - and that is no simple matter. By all means do it, but if so, then do it well and do it right! 

    Most places I see do NOT require signing at all - they view it as a less than helpful overhead and rely instead on admins always doing the right thing. Where the extra layer of security is needed, or perceived to be needed, I'd invest in a smart card system and ACLing scripts that require it to only run based on smart-card logins. And making running that code any other way a sackable on-the-spot offence. And I'd definatly want to make sure the 3:00 AM scenario is covered (I.e. the script breaks, it's 3:00 AM and we need to fix it and get it run NOW). Again - this is all doable but it may not be easy. You need to ensure the security system is actually helping not hindering real security. But I diverge from the question at hand.

    As to your error, I can only guess that with the XEN environment, PowerShell is seeing those scripts are remote and therefore needing a signature that they do not have. I do not have a XEN environment to test or diagnose this in - and you've not provided any output to examine. Sorry I can't give you a better answer.

    Out of curiosity, try using unblock-file on the files and see if that makes a difference. It probably won't but it's a thought.


    Thomas Lee <DoctorDNS@Gmail.Com>


    • Edited by Thomas Lee Monday, April 1, 2013 3:44 PM
    • Proposed as answer by jrv Monday, April 1, 2013 3:57 PM
    Monday, April 1, 2013 3:42 PM
  • My contrary view is that "AllSigned" and block users from running PowerShell at the GUI prevents users from playing.  There are many big games now written in PowerShell and users will get into the habit of downloading scripts and running them.  We use Group Policy to block this. 

    Signing scripts is trivial and, along with the restrictions, prevents scripts from being altered that are used in production.  Much of the altering is by accident because an admin is in a hurry and makes a mistake while editing a script.  By forcing signing this can be tracked and slows down the wild men that are hired as Admins.  (Don't most Admins seem like they are from Mars and dink too much caffeine?)

    Other than that Thomas has pretty much covered the issue and his take is not unusual.  PowerShell is as secure as the network and systems it runs on.  Signed scripts will not prevent problems on badly secured networks.


    ¯\_(ツ)_/¯


    • Edited by Thomas Lee Monday, April 1, 2013 5:36 PM typos
    Monday, April 1, 2013 3:57 PM
  • I did not know that the two commands were on and the same.  Is that something that just changed?  We had another set of servers that ran PowerShell scripts to set up the environment, that would not work with any other user until we added the -scope localmachine

    The Xen environment mimics that of the server so the execution policy is the same both from remote desktop and that of the vitalized environment.  XenApp just allows the thin client to just access the application it needs, terminal service. 

    If it runs well on one machine the way I describe, and all the settings are the same (The XenApp is running from the server) should it not work on the other?  Personally I would love to leave it at Bypass, but I am required by my higher ups to use remotesigned.

    Monday, April 1, 2013 4:13 PM
  • You need to set machine policy in Group Policy to be sure that the policy is not overwriting your local setting.

    Group Polcy has settings for POwerSHell.  This is where we need to set the network default.  It may be set to AllSigned and you are just overriding that on your account.

    Use Group Policy.

    You can also validate the settings with this comamnd:

    Get-ExecutionPolicy -List

    Pay attention to MachinePolicy and UserPolicy

            Scope ExecutionPolicy
            ----- ---------------
    MachinePolicy       Undefined
       UserPolicy       Undefined
          Process       Undefined
      CurrentUser       Undefined
     LocalMachine    RemoteSigned

    Also see:

    help set-executionpolicy -full

    Note the following:

     C:\PS>set-executionpolicy -scope CurrentUser -executionPolicy Undefined
     Description
     -----------
     This command uses an execution policy value of Undefined to effectively remove the execution policy that is set for
     the current user scope. As a result, the execution policy that is set in Group Policy or in the LocalMachine (all
     users) scope is effective.
     If you set the execution policy in all scopes to Undefined and the Group Policy is not set, the default execution p
     olicy, Restricted, is effective for all users of the computer.


    ¯\_(ツ)_/¯

    • Marked as answer by Treyb Monday, April 1, 2013 6:21 PM
    Monday, April 1, 2013 4:33 PM
  • Also be aware of the following:

     MANAGE SIGNED AND UNSIGNED SCRIPTS
     ----------------------------------
        If your Windows PowerShell execution policy is RemoteSigned,
        Windows PowerShell will not run unsigned scripts that are
        downloaded from the Internet (including e-mail and instant
        messaging programs).

        You can sign the script or elect to run an unsigned script
        without changing the execution policy.

        For more information, see about_Signing.


    ¯\_(ツ)_/¯

    Monday, April 1, 2013 4:39 PM
  • The Xen environment mimics that of the server so the execution policy is the same both from remote desktop and that of the vitalized environment.  XenApp just allows the thin client to just access the application it needs, terminal service.  .

    For XeNApp enthusiasts - An App is what used to be called a borderless terminal session or a terminal session with no frame.  ONly th emain WIndow sof the applicaion is visble so it looks like the appis running locally when it is, in fact, a remote terminal session.  Everrything is a terminal session except the look of the Window and the fact that the user is locked into that apps window. No desktop.

    As you noted it should behave exactly like a full terminal server session as far as everything else is concerned. 

    There is one difference. We can choose where to get the profile from.  If we are runniong of of teh calling machines user profile then the settings for PowerSHell, if set, will take precedence over the remote machine settings as long as the user settings are more restrictive. You would need to create a specisl POwerSHell script to check the 'CurrentUser' setting.  If it is set to AllSigned then you will not be able to run scripts.

    Note also that a script donloaded from the Internet may be fully blocked event if RemoteSigned is chosen.  You need to remove the blocking flag.  If you do not know how to do this then copy the contents of the script to a new file created on the UNC machine and test.

    You may also have to use Group POlicy RSOP to determine what settings are being accumulated by both the machine and the user.

    Signing scripts eliminates these issues and using GP to set the policy prevents inconsistency across the network.  Not using GP or setting Allsigned locally will not help you in the future.


    ¯\_(ツ)_/¯

    • Marked as answer by Treyb Monday, April 1, 2013 6:21 PM
    Monday, April 1, 2013 4:54 PM
  • Re the signing of scripts.

    I agree, it can be made relatively trivial, although there are other ways, IMHO, to impact and influence user habits!

    The cost of setting up a signing infrastructure is non-zero and there must be budget for maintenance of it. Another issue to consider, especially in an AllSigned environment, is who has the signing key? In places I know of that use digital signing, the key is tied to a smartcard-only login, with the key saved in the safe. That makes it very hard to change scripts. If you distribute the signing key more widely, abuse can happen. In the allSigned envorinment, there could be a lot of scripts that need signing - that all takes time and effort to manage.

    I'm not saying not to do it, I'm just saying that there can be better ways for most users.And if you do decide to go down that route, make sure you budget the time to do it right, or it could grind your automation efforts straight down to Zero!

    Thomas


    Thomas Lee <DoctorDNS@Gmail.Com>

    Monday, April 1, 2013 5:44 PM
  • Don't miss the point of RemoteSigned.  This says that scripts from untrusted locations will not run.  Any trusted script will run without signing.  It is a simple layer of protection that is totally transparent once it is set up correctly.

    ¯\_(ツ)_/¯

    Monday, April 1, 2013 5:49 PM