I need to be able to use "Shift + Right Click" on a PS1 file and select "Run as different user" to execute the script as though I were that user. I cannot store credentials, and I do not want to use "Shift + Right Click" to execute PowerShell and then navigate to my scripts via the console. How do I accomplish this? I have been unable to find anything that doesn't require me to launch a separate window or store credentials.
-
Check this out, start-process or invoke-command will take alt creds https://stackoverflow.com/questions/28989750/running-powershell-as-another-user-and-launching-a-script – Eric Weintraub Jan 03 '19 at 19:31
1 Answers
Right click or shift right click, run as another user is a Windows standard for executables. This right click runas is controlled by the OS.
By design you cannot double-click or right click a .ps1 file and have it run. .ps1 is set to kick off notepad by default or other text editor you may have assigned it to, i.e, VSCode, Notepad++, etc.
.ps1, is not .bat, .cmd, .vbs that will run from a double click.
If you want to double click a .ps1 and have it run, then you have to at least set the file type using Windows Explorer and assign it to PowerShell.exe. This is not recommended by MS or anyone, BTW, but it can be done. The reason for not recommending this is, all about risk / security management.
What you need to do to get close to this, is create a PowerShell shortcut set with the startup settings you want. Specifically setting the RunAs option. Pin that shortcut to your Windows SendTo menu (in the Windows Explorer bar, simply type shell:SendTo to open that folder to put that shortcut in), or you need to edit the registry for the default right click 'run with PowerShell' option, after making the adjustment of adding the RunAs parameter.
Using a PowerShell script to run as a different user & elevate the process.
Otherwise, you may want to consider this, with that RunAS setting as well.
Drag and Drop to a Powershell script
All that being said, that still may not going get you all you are after, but it will get you close.
Update for the OP on the question
Do you feel that group policy which restricts the use of powershell And other scripting languages to domain Admins only to be a sufficient security control or do you see that as problematic as well?
Principal of leaste privilege is always a solid practice, but there is more to be done. There are some really decent articles on PowerShell secure operations / configurations.
Restricting / blocking the use of powershell.exe, push.exe does not prevent the use of PowerShell. Those are just hosts, and I can use any dev tool to create my own PowerShell host and run commands. I can even create my own PowerShell editor or even extend other Editors.
PowerShell Editor Services PowerShell Editor Services provides common functionality that is needed to enable a consistent and robust PowerShell development experience across multiple editors.
Getting Started with Editor Commands
Extending the Host Editor PowerShell Editor Services exposes a common extensibility model which allows you to write extension code in PowerShell that works across any editor that uses PowerShell Editor Services.
PowerShellEditorServices A common platform for PowerShell development support in any editor or application!
Join us for the PowerShell Editor Services Hack Week, Dec 6-13!
I can do virtually all PowerShell stuff using WMIC or VBS (yet, I've never seen any enterprise really address these as deeply as they could either). Yes, it's more code and ugly, but doable. So, auditing, constrained / delegation, etc. are a must have for controls and incident response. So, when thing end to end risk / security management, here are a few things to read up on.
PowerShell Security at Enterprise Customers https://blogs.msdn.microsoft.com/daviddasneves/2017/05/25/powershell-security-at-enterprise-customers https://acsc.gov.au/publications/protect/Securing_PowerShell.pdf
PowerShell logging boosts security in the enterprise
Practical PowerShell Security: Enable Auditing and Logging with DSC
More New Stuff in PowerShell V5: Extra PowerShell Auditing
PowerShell Injection Hunter: Security Auditing for PowerShell Scripts
15 Ways to Bypass the PowerShell Execution Policy
Introduction to PowerShell Endpoints
Build Constrained PowerShell Endpoint Using Configuration File

- 15,138
- 2
- 14
- 25
-
Do you feel that group policy which restricts the use of powershell And other scripting languages to domain Admins only to be a sufficient security control or do you see that as problematic as well? If it’s problematic can you elaborate on why Group policy would not be sufficient? – Aaron Martin Jan 04 '19 at 22:21