How to force PowerShell to not allow an interactive command window

Question

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?

Answer 1

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.

Answer 2

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.