Archive: Q: Does NSIS support RunAs credentials and Silent installs?


Q: Does NSIS support RunAs credentials and Silent installs?
Network admins (as me) working in MS domain environments almost always have users that aren't local administrators (for obvious reasons).

We normally handle installations and patch management through Active Directory or some other solution (SMS for example), with MSI/MSP packages.

Sometimes though, it is desired to have standalone installers that can be distributed with CD's etc. Since the users doesn't have local admin rights, does the NSIS support RunAs? Ie, can a designated user account be coded into the NSIS package so that it runs with a different accounts? And if so, how well is the provided credentials encrypted?

Also, can the installer be made totally silent, so it only displays a progress bar after a double-click?


There is no built-in support for such credentials. Personally, I think the risks of giving administrator access with one breakpoint by far exceed the gain of not having to type the password yourself. The only way I see of avoiding this problem is having a service ran by the system user which will verify the installer. I guess that's what MSIs with credentials do.

To run an installer silently, use the /S command line switch or the SilentInstall command in the script. To make it just show the progress bar, simply remove the unrequired pages from the script. You can also add a command line control switch that will cause every page pre function to call Abort to skip the page.


Agreed, providing credentials with a file isn't the safest way, even if encrypted.

But there are options to minimize the effects of this, for example, you can specify a domain account that times out after the installation, or a local account with administrative purposes (which you could centrally script the creation of for example). You can then have your own code within the script to delete that accout once done with the installation.

Most important is to have the option there ;) Almost every company - small as well as large - has come to terms with the fact that you shouldn't run your Windows-based PC with administrative rights unless you're installing software that requires elevated permissions (and not even then - use RunAs). Even many talented home-users have realized this fact. This realizes the need for installers that supports running under specified credentials :)


The effect of giving a user administrative access, even if temporarily, is too destructive. You are not only giving the user the option to control a fully granted process, you are also giving away the user name and the password. Even if you encrypt the user and the password, the key will have to be contained in the installer along with the encrypted data. It doesn't matter if the installer might be set to delete that user when it's done as the user doesn't even need to run the installer.


yes yes, I've already answered that. There's ways to control this fairly good, wtih time-limited, logon-count limited accounts for example. Main point is to have the option there. This is something wanted by thousands of network admins, and something only available in expensive packagers as WISE etc...

In other words, a really useful and wanted feature.


I have no intention of implementing such a flawed method. If you have a better idea, I'll consider it. But saving the user name and the password in the installer is unaccepted.

If you're willing to put up with the flaws, you can create a batch file that will execute runas.exe.


RunAs
There is always the application TQCrunas from the Quimeras Company (http://www.quimeras.com)...

However, we're having some challenges in getting it to work in a multi-installer package...