I am a Citrix administrator and would like to restrict the general user population on our servers from using PowerShell to run their own scripts, or to use it interactively. We are already disallowing the use of the command prompt via GPO, but with PowerShell available, that's basically useless.

I've found that Powershell.exe has a command-line option of -NoInteractive which will allow a user to run a script, but it does not provide them an interactive command prompt. The problem is that I have not found a way to force powershell to operate this way. I even went so far as to create a C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 launch script that would check for the -NoInteractive parameter, but users can bypass that by simply launching Powershell.exe with the -NoProfile parameter.

The other problem is that we do use a lot of PowerShell scripts to launch applications for users and portions of the login script are written in PowerShell and need to run under the user context, so I can't simple ACL the EXE file. I need them to be able to use PowerShell, just not interactively. Ultimately, we want to enforce the AllSigned execution policy and sign all scripts so the only thing a user can run is a script that we (the admins) have created and/or signed off on.

I've tried googling for this answer and found many people using -NoInteractive, but I haven't found an instance where someone has tried to force it. Any ideas?

  • I think you already have part of the solution. Signing the scripts and enforcing a policy to prevent unsigned scripts from running sounds like a good plan. You still need to cover interactive use though. – Dominic Cronin Sep 9 '16 at 19:16

I think you are misunderstanding the use of the -NonInteractive switch; you can still run powershell -noninteractive and get an interactive prompt. The noninteractive switch is intended for automated scripting scenarios, where you don't want powershell to send a prompt to the user and wait for a response. For example, in a non-interactive PowerShell window, if you run Get-Credential without any parameters it will immediately fail instead of prompting for a username and password. Noninteractive will NOT act as a security mechanism.

A better method is to secure what you're trying to protect, not the tools a user might use to access it.

| improve this answer | |
  • Thank you for pointing that out. I was testing this out by running "powershell.exe -nointeractive" from the Run box and it would disappear immediately, so I assumed that was the behavior. It turns out that it was failing because I was using -NoInteractive instead of -NonInteractive. facepalm – SalamanderMN Nov 7 '14 at 20:26
  • Although my problem remains. I still need to find a way to restrict Powershell the same way that Microsoft designed the restriction of the Command Prompt. In a multi-user environment, it's a relatively common practice to protect users from harming themselves. (particularly those that aren't IT-savvy) My users have no reason to use PowerShell so I'd like to lock it down. – SalamanderMN Nov 7 '14 at 20:30
  • 2
    Well, I don't know of a way, especially if you want to use powershell for login scripts. Don't make your users local Admins, set proper ACLs on files/folders, and I don't see where the problem is. Then, IF you have an IT-savvy user, they can maybe use PowerShell to speed up their work. If a user has permission to delete a file, they can do it whether or not they can access PowerShell. If you MUST block it, then I think you'll have to ACL the file and then find another way to launch your ps1 scripts (host the PS runtime in a C# app?). – jbsmith Nov 7 '14 at 20:38

I believe I have a solution that will work, although it's not particularly pretty. User jbsmith was on the right track. If I end up ACLing the powershell.exe to remove Execute permissions from the Users group, that stops them from running an interactive window. For those PowerShell scripts that the users DO need to run via the login script, we can compile those scripts into an EXE using PowerGUI and that allows the scripts to run, since that does not call the PowerShell executable.

We're debating over whether we want to take this another step further and use an AppLocker GPO to restrict PowerShell scripts to only those that we have blessed. Of course, we can put these restrictions only on the average non-IT user and allow our administrators to continue to use PowerShell as normal. This will involve some administrative overhead to maintain, so the AppLocker part may not come to fruition.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.