LabVIEW
Elevated Console, MKLink Issues
Solved!
Okay so I have a LabVIEW program running in Windows Server 2012, and I want to call a command line program that can only be ran in an elevated command prompt. What I'd really like to do is use the mklink to create a symbolic link to a file. Now the user logged in is an Admin, and for testing I turned UAC all the way down, but no matter what I get an error saying I don't have the correct privileges.
So I created a batch file that I can double click and see that it is ran by default in a non-elevated command prompt, even though I am an administrator. If I right click the batch file and choose Run as Admin, it runs just fine, and only prompts me to continue if UAC is turned up.
So how in the world do I make this work without jumping through hoops? How can I make an elevated command prompt to be used in LabVIEW? The best I could come up with was to create a shortcut to cmd.exe and in the properties set it to run as an administrator. Then I think I can call this cmd.lnk from LabVIEW and pass the parameters into it.
I've done stuff like this on other OSs before and had no issue at all but for some reason when I go to Run and type cmd it opens a normal non elevated command prompt, and I assume this is the problem in LabVIEW.
I've also tried things like Runas and Psexec and while this allows me to run the program as any user, this still runs in a non-elevated command prompt. Any suggestions? Thanks.
Oh so sorry I didn't mention that to start. It is Windows Server 2012 x64, LabVIEW 2015 SP1 32-bit, and has worked on Windows 7 Pro SP1 x64. The server OS likely has something to do with the problems I'm having. I found through lots of online searching that if a user is not an administrator, and you have given them the group policy of Allow Create Symbolic Links then that user can use MKLink in a non elevated command prompt.
This does complicate things a bit because this user was an administrator and now I need to add other policies like allowing them to restart, and allowing remote desktop sessions, which previously just came with being an admin. Then there's lots of prompts saying I don't have permission and needing to enter the admin password for doing other work outside of my program. But for now I can now use mklink in non elevated command prompts, and in my LabVIEW program. I had also found that junction can be used without an elevated command prompt, but only maps symbolic folders, but not files and I needed both. I did already find the idea exchange and did kudo it. Still I'd prefer a method that didn't require the user to not be an admin, and for that I need LabVIEW to open an elevated command prompt, when by default a non-elevated one is opened. Or a Windows setting (which I haven't found) which opens an elevated one by default, if the user is an admin.
Well, first, Windows Server certainly is not meant to be used as a working desktop machine in the first place, so it's default security settings are all tweaked to provide maximum security and as little rights as absolutely necessary to do normal maintenance work.
Second, junctions can not link to files, only symbolic links can. Junctions can also only link to local directories, never to something that is considered a remote location.
I don't really think that there is a setting that would change Windows to open a process as elevated by default. Under normal Windows if the parent process is started as elevated any child process created without explicit security context should inherit that setting. This includes processes launched by System Exec in LabVIEW. But under Windows Server they may have changed that to not allow security escalation.
One possibility under desktop Windows, but not sure about Windows Server to run a process elevated is to cal the ShellExecute() function instead with the operation set to "runas" which will cause the Windows shell to attempt to run the process with elevated rights, which will cause an elevation dialog in all cases, possible together with password prompt if the current user is not part of the Administrator group.
@rolfk wrote:
Well, first, Windows Server certainly is not meant to be used as a working desktop machine in the first place
I never said I was intending on using it for that. And the OS selection wasn't something I was involved in.
Second, junctions can not link to files, only symbolic links can.
Yes I know I stated that in my second post, which is why junctions wasn't a solution for all of my use cases. Some of my issues were resolved by using this but not all of them.
@rolfk wrote:
I don't really think that there is a setting that would change Windows to open a process as elevated by default. Under normal Windows if the parent process is started as elevated any child process created without explicit security context should inherit that setting. This includes processes launched by System Exec in LabVIEW. But under Windows Server they may have changed that to not allow security escalation.
A different Windows 7 PC I have will open a command prompt as elevated by default when the user is an administrator. Just type cmd in run and it opens as elevated. I wasn't sure if this was a setting some where, or if this is a feature of the server OS being more locked down that it doesn't work that way. As a quick test I ran LabVIEW.exe as an administrator, then opened a system exec call in that. The command prompt that came up was not elevated.
One possibility under desktop Windows, but not sure about Windows Server to run a process elevated is to cal the ShellExecute() function instead with the operation set to "runas" which will cause the Windows shell to attempt to run the process with elevated rights, which will cause an elevation dialog in all cases, possible together with password prompt if the current user is not part of the Administrator group.
Borrowing the code from here I was able to perform a ShellExecute on a batch file that just pauses, and the command prompt that came up was not elevated even on my Windows 7 PC where if I just go to run and type cmd the prompt that comes up is.
@Hooovahh wrote:
Borrowing the code from here I was able to perform a ShellExecute on a batch file that just pauses, and the command prompt that came up was not elevated even on my Windows 7 PC where if I just go to run and type cmd the prompt that comes up is.
Did you change the lpOperation to runas instead of open?
As to creating a shortcut that opens a command elevated that is basically just a setting in the shortcut properties. Quite possible that your Windows installation has that changed. On my Windows 10 system I have to explicitly right click the link and select "Run as Administrator"
I did find the option to run a shortcut as an admin, but I couldn't change the cmd.exe to run that way. I thought if I could just change that file then all calls to open it might be defaulted to elevated. I also tested on several other computers that I know didn't come from the same image and in 7 they behave the same. If the user is an administrator (and UAC turned down), going to run cmd opens it as elevated without prompting.
@rolfk wrote:
Did you change the lpOperation to runas instead of open?
I did not, how would I do that? Looking at this post it seemed all that as needed was to add runas to the lpOperation which I did and it didn't run as elevated. I'm guessing there is more to it since I never specified what user to run it as.
