Starting exe as another user

[Wiebe@CARYA]

Hi,

Perhaps someone else dealt with this. I tried a lot of things, but haven't
succeeded jet.

I need to start a (LabVIEW) application, running as another user. From the
command line, runas works perfectly. But from LabVIEW, runas doesn't work.
This is documented, runas checks if it's called from the command line, and
doesn't start if it's not called from the command line. For start, there is
no commandline option for the password.

I did try to open pipes to runas, so I can pipe the password to runas, but
this doesn't work either. Runas seems to check from where it's called...

There is a tool called Sanur.exe, that can be used to pipe a password to
runas, so you can enter the password on the command line (like runas
/user:user "program.exe" | sanur password). This also doesn't work with
LabVIEW, since runas is still checking from where it is started...

So I tried some API's... CreateProcessWithTokenW with LogonUserA,
CreateProcessWithUserA with LogonUserA and CreateProcessWithLogonW... It
doesn't help that some of them are Unicode, but with MultiByteToWideChar,
that is easy to solve.

CreateProcessWithTokenW and CreateProcessWithUserA only work when the
client applications has few rights, so I got some errors about that. I
haven't tried to obtain those rights, since that is rather difficult.

The last one (CreateProcessWithLogonW) works on my PC, but gives error 6
(Invalid token) on the real environment. The API doesn't have a token input,
so something must be wrong. Nothing on internet about this either...

Anybody done this before?

Regards,

Wiebe.

[dan_u]

Hi Wiebe,

There's a tool called pcwrunas, it's basically the same as the built in runas but supports passing the password in the command line.

The tool is available on PCWelt (german only...): pcwrunas

I didn't try, but I hope this should work with system exec.

Hope this helps,

Daniel

[Wiebe@CARYA]

Daniel,

Thanks, I'll also try that. The German won't be a big issue.

I found more alternative "runas" applications, But I thought it would be
nicer to require no external programs. I also did not see any reason to use
them at first, so I kept it as a last resort.

I am now evaluating CPAU.exe (from www.joeware.net). I still have to see if
this doesn't create the same error. It sure does a lot more then a simple
CreateProcessWithLogonW. I can't find anything about why this should be
needed though. It's command line format is almost the same as pcwrunas, so
it shouldn't be much work to adapt.

The nice thing about pcwrunas, is that it's source is available. So if it
works, I am going to examine it, and see if I can make a native LabVIEW
program from it!

I'll let you all know the results.

Regards,

Wiebe.

[Wiebe@CARYA]

OK, I've checked out pcwrunas. It uses an installer, which makes it less
practical (compared to simple stand alone command line-applications). Only
one exe and one dll are usefull, so I simply copy them...

Also, it seems to be GNU-GPL, so you can't (aren't allowed to) use it in
propriatairy applications. Also, if you distribute it, you have to provide
reference to the source code, but the source code is nowhere to be found!

Another minor disadvantage is that the code is compressed, so it's hard to
tell how it works... Usually, this is done to protect IP, which is weird for
a GPL project. (Perhaps they really did it to shrink size, but cpau.exe is 7
kb, while (compressed) pcwrunas is still 70 kb...).

I'll still check if it works though...

Regards,

Wiebe.

[dan_u]

This doesn't sound that nice...

Probably there are other tools around that can do the same?

A quick search also returned vbs script. This just programmatically enters the password in the runas dialog box.

Daniel

[waldemar.hersacher]

I use an organizational solution provided in the issue 15 2004 of the c't magazine. Some games will only run in admin mode on W2K SP4 and XP SP2 and I don't want my children to login as admins. Additionally I didn't want to spent the time to analyze with regmon and filemon where to set any rights.

Today I have Win XP Prof. SP2 running on my machine and I  use the following solution.

If only user X will run your app and needs to start another program as admin you need to do the following thing during installation. Install the program (you are logged in as admin so you know the password). Then login as user X. Open cmd.exe and type:

runas /user:admin /savecred <theapp>

You will be asked for the admin password. Give it and stop the application.

Next time the password  is not needed.

Now create a small cmd file containing the line above and call the cmd file from your app with the system exec vi.

[F._Schubert]

Waldemar, that sounds to be a greate issue. I run into the problem once, that a device needed the app to be run in an admin account. but the operators should be normal useres by factory policy. I refactored the code to have the device driver VIs run as system service, called via Open VI ref. But it really comlicates the code. And it took me three days to have all running, while every time the program was quit or crashed, I had to run to the floor to login for the 'run as' command. And the operators went crazy, when I left for the weekend on 19:30 on friday....

Felix

[Wiebe@CARYA]

Here's my situation:

The program runs in a company network. So, any user might login. The program
uses network shares. I first used network mapping to get access under
another account. But this is very problematic (it fails under a lot of
circumstances), and also very unsafe (the net share shows up in explorer).
So, each net share has to be deleted immediately after the network operation
is completed. Hopefully, no one figures out that the share remains open when
the application is terminated with taskmanager...

Another problem is that the program uses a ODBC data source. The database
connection will fail if the files aren't accessable by the user. So, I have
to give the user R/W rights, but the user can also delete the files becuase
of those rights.

Al this is solved by starting the application with runas...

But runas can't be runned by an application...

What also complicates things, is that the system administration requires
that all passwords are changed every 4 weeks. My plan was to simply have a
list of, say, 10 passwords, and store the last correct password. If login
fails, try the next one. If you login this to often, the account will block,
so it should not simply try all passwords from the beginning.

[waldemar.hersacher]

Wiebe wrote: But runas can't be runned by an application...

Not directly but as part of a command file. I have an app named Drive Snapshot which requires admin rights and checks this during startup. As a restricted user I created a command file named DriveSnapshot.cmd with the following line:

runas /user:admin /savcred F:\Programme\SnapShot\snapshot.exe

Double clicking in Windows Explorer  requires the password entered. The next time time it will simply start without a prompt.

Next I created the following VI:

Running the VI will start the commandfile and therefore start DriveSnapShot.

Next I logout and  login as admin and changed the password. Then I login as the previous restricted user. Running the VI DriveSnapShot will not start. You need to provide the password again.

For the permanent change of passwords this is not a solution for Wiebe.

Talking to system administrators they maybe make the following solution possible:

Creating a special user in the domain with admin rights. This user wil never change his password and is only known to the application programmer and the admins.

Message Edited by waldemar.hersacher on 02-03-2009 08:12 PM

[Wiebe@CARYA]

>line:runas /user:admin /savcred
>F:\Programme\SnapShot\snapshot.exe&nbsp;Double clicking in Windows
>Explorer&nbsp; requires the password entered.

Wouldn't it be easy to change the started program? For instance, change
snapshot.exe to explorer.exe? Or is this restricted by the credential
mechanism?

>Talking to system administrators they maybe make
>the following solution possible:Creating a special user in the domain with
>admin rights. This user will never change his password and is only known to
>the application programmer and the admins. Message Edited by

That would be the easy way. But my client is a multinational, and creating
such a special user would be near impossible. More for financial and
managment reasons then technical reasons.

Regards,

Wiebe.