Use Powershell to grant LabVIEW executable (application) higher-level user or admin credentials

[StuffedBearCoder]

I had a need to grant a LV executable (EXE) and elevate its network credentials from a generic user logon to a higher-level user privilege (like mine) or admin that has the privilege to access the network share.

I came up on forum discussions in StackOverflow or StackExchange that Windows Powershell (came preinstalled with Win 7 and up) can do the job. Checkout: https://stackoverflow.com/questions/55188729/how-to-use-powershell-to-grant-windows-application-or-e...

After several forum discussions I was given a sample code to try in PS console:

$App = "c:\path\to\[app.exe]"
$Credentials = Get-Credential
$WorkingDir = Split-Path $app
$Exe = Split-Path $app -Leaf
Start-Process -FilePath $Exe -WorkingDirectory $WorkingDir -credential $Credentials

This worked inside the PS console. The LV app inherited my credentials.

But how to integrate this programmatically in LV so you won't have to be a console nerd every time and a lowly user happy with just the GUI? Solution is below LV code snip:

Use PowerShell console in VI via System Exec Node

Note: I added the case structure to detect if I am running an EXE or VI as I needed to debug the code before building EXE. It is optional if you hard-link to your app-kind and already know in advance where it is located.

Also, make sure you use "cmd /k" and not "cmd /c" to keep the CMD window open when executing/passing the PS arguments - but you can try both for fun.

I also found out that for the "-Message" switch for [Get-Credential] cmdlet to work without error, your PS version must be 5.0 or higher. PS version 3.0 supported the "-UserName" switch.

Enjoy!

[matt.baker]

Ooops wrong purpose. Ignore

This may also be of use: https://forums.ni.com/t5/Example-Program-Drafts/Run-as-administrator-elevated-user-in-Windows-using-...

[StuffedBearCoder]

Thanks for the recommendation. I did try this (or one VI I got from this board) like the one below to elevate the permission of another VI using Win32 API:

I didn't like this method as it can be prone to attack and it didn't work quite as well as the Powershell method. Another, the said Windows DLL may become deprecated, renamed and unsupported in the future. Having the user logon with his higher privileged logon from the generic logon is much more robust and secure, to me.

Whatever case may be, using Powershell, as is now the administrator scripting language baked in .Net frameworks from Win7 to Win10. Powershell is also now an open source and available for Linux and Mac. There is so much to learn from it. Thank goodness I discovered its use. Now if NI will create a Powershell-native node instead of using the System Exec node to invoking it.