I am using Visual Studio 2008 to build an MSI install package. Within the install I have numerous custom actions. Within the OnAfterInstall custom action I attempt to start an exe which is deployed by the install. The exe starts ok, but runs within a security context of NT AUTHORITY\SYSTEM (i.e. under the elevated privileges granted to the Windows Installer process). I actually need the exe to run in the security context of the currently logged-on user who started the install in the first place. Does anyone know how to start the exe so it runs in this 'reduced' context. I really want to avoid having to ask the user for their login credentials if possible.
You need to use Remote Desktop Services API: http://msdn.microsoft.com/en-us/library/aa383464%28v=VS.85%29.aspx . It is available starting from WinXP.
This API allows you to run your application in context of any logged in user account. You need to be running as a SYSTEM to be able to use it. And you are.
For instance you may enumerate sessions using WTSEnumerateSessions, then take user token by WTSQueryUserToken and run application using this token.
Related
After installation of the program, can not make uac dialog box disappear when the program is run?
Can I grant administrator privileges to install and have it run automatically at install time?
You cannot bypass UAC, the user is supposed to be in control of their computer, that is the whole point of UAC! If you want to do machine wide changes that require administrator privileges there is no way around it, the user has to elevate with UAC at least once.
If you want the installed application to run elevated automatically then you must write a custom service that can be started on demand. When a administrator starts your application un-elevated the application must start your service and ask it to launch a elevated instance. The service must then call CreateProcessAsUser with the linked elevated token. This is too difficult for most developers and most applications just have to accept the fact that they must display a UAC prompt when they are started.
I've made a console application that is supposed to update some registry entries so that I can access 32 bit COM components from a 64 bit application. If I have admin rights, it works great, but I can't seem to get the application run with admin rights out of the box.
This is what I've done.
Create a Windows Console Application.
Add my code.
Right click on my project and select Properties.
Navigate to Configuration Properties > Linker > Manifest File > UAC Execution Level and set to requireAdministrator (/level='requireAdministrator').
It took a lot to figure out this because all of the info on the web is for Visual Studio 2010 or earlier which required manually creating an XML manifest file and conflicts with the auto generated one that this creates.
However, this doesn't seem to be enough to get it to run as an admin. It is a real PITA that this information isn't made easily findable. Is there some other step that I am missing? Something like a signing process?
Turns out it is how this mini application is run.
From my main programme, using ShellExecute() or ShellExecuteEx() with the "runas" verb will allow running of this executable with administrator privileges without popping up a UAC dialog.
Running this from the command line however, will result in this mini app being executed in the user's security context, which is what I was doing.
When working on a project that uses IIS (not IIS Express) for local development, what permissions are actually required under window 8? I don't want to run as admin all the time...the first error message I get when running using the Local User Account (LUA) was about Metabase (probably a misnomer, as changing the permissions on that gave the same error message until the config files in inetsrv/config were also available). Now it builds, but then gives an error message "Unable to start debugging on web server. IIS does not list a web site that matches the launched URL".
The blog https://blogs.msdn.microsoft.com/jaredpar/2005/02/04/myth-creating-web-applications-with-visual-studio-requires-admin-privileges/ while old, at least hints that it should be possible to manually give myself (or a group that I create) the right permissions. Just need to figure out what those permissions are...
To run VS against IIS you need to run VS elevated (the process needs admin permissions).
From a non-admin account you could run VS "As Administrator", you will also need to do this with the tools necessary to configure IIS.
However I've never tried that, rather I run with a non-elevated admin account so any file changes from within an elevated VS are fully accessible to non-elevated processes.
Additional: note, VS really only needs the Debug Any Process privilege, but giving that one privilege gives the ability to gain all others (with some effort) going through the work to limit the VS process to just that one difference seems pointless.
I have a windows application with user Interface that do some stuff...
Now my client wants that, when he pushes the power button MyApplication run before he forced to input the username and password!
comment: the system is multi user on windows XP or Seven.
Is it possible anyway?
I found the way to do this was to create a scheduled task with a trigger for "on startup". This starts the application before windows logon. This is particularly useful in a server type environment if you need to have something run that is not a service.
It is simple. The process is.
Run gpedit.msc
Go to computer Configuration -> Windows Setting -> Scripts(Startup/shutdown)
Go to Startup properties then you will get the new windows.
Now add the program that you want to run before login.
The right way to do this is to implement a Windows service.
I've used this article here as I run a Minecraft server which I need to have the console interactive so I can manage the server and running it as a service is not a good solution in such a case: https://www.tenforums.com/tutorials/138685-turn-off-automatically-restart-apps-after-sign-windows-10-a.html
What I did was edit the registry:
Go to HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Create a new DWORD value (if this DWORD doesn't exist already) and
call it RestartApps with the value of 1
This now starts apps that usually startup before you log in and starts the programs in shell:startup
You can not run an exe without first loading the operating system. You can, however, run the exe without logging in first. Just add copy and paste the shortcut for the exe into C:\Documents and Settings\Administrator[or other user name]\Start Menu\Programs\Startup. Then check msconfig to make sure your exe is checked to run on startup.
Folks,
I've got a strange issue at the moment with a visual studio 2010 built MSI...
When I run the msi, it performs a few tasks, then executes a tool we built - this tool then carries out some more advanced work we couldn't do within a custom task.
The issue here, is then when the msi starts my custom built tool, it doesn't execute it with the same credentials as I start the MSI with (i.e. my administrative login).
Is there a parameter I can pass to an MSI to enforece this? Or perhaps I can pass the credentials to the process when I start it?
My process is started using Process process = Process.Start(procInfo) nothing fancy. I've also noted the ability to pass in a parameterised username/password/domain, but this will vary depending on the user who is installing - can this be extracted from the installer somehow?
Any help (or questions) welcomed.
Dave
EDIT: for clarity... I'm running the MSI under my domain account, and I want my custom process to run under that 'context'. At present, it starts (regardless of whether I start as administrator or not) under the SYSTEM account (rather than mydomain\me). I'm using Windows Server DataCenter edition if that helps...
I should also add, I think this is a policy issue, but I've no idea what to check/where to check...
By default Windows Installer runs custom actions as the current user. If the MSI is elevated, custom actions will run as the elevated user.
Please note that if you are running the MSI as an Administrator, it doesn't mean your custom actions will have full Administrator privileges. On Vista or higher any user can gain Administrator privileges through elevation.
So if your custom actions need Administrator privileges, make sure they use the msidbCustomActionTypeNoImpersonate flag so they run under the local system account.
If this is not the problem and you just need access to the current user data, can you please give me more details?