Let's say app.exe has been built with requireAdministrator manifest as detailed here (this is really needed for a reason that would be out of topic here). When launching the app, when Windows UAC is enabled, there is a normal prompt:
Now this application needs to run on Windows startup: in an Options dialog, there is a "Launch at Windows startup" checkbox that can be checked or not. When checked, it adds a key in the registry in
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
to enable this "launch on Windows startup feature".
Problem: At Windows startup, when app.exe is (automatically) launched in background, there is this UAC dialog box (see screenshot before), which is annoying for the user.
Question: How to make that app.exe can be launched 1. with requireAdminstrator 2. silently at Windows startup ?
What is the clean way to do this? Lots of software do this (indexing software that both run on background since Windows startup, and don't show such a dialog box).
Note: I would like to avoid TaskScheduler method if possible: https://www.sevenforums.com/tutorials/11949-elevated-program-shortcut-without-uac-prompt-create.html
The indexing software "Everything" does show such a dlalog.
The others you are thinking of run only services with admin rights, not UI.
Running a service requires the software to be architected with that intent, ordinary user applications can be started with the service rules with the help of the "at" service, which you already know how to do (Task Scheduler).
You can substitute some other service for Task Scheduler, at the risk of annoying the user through needless duplication, waste of resources, and likely new security flaws.
Set aside your preference, and use Task Scheduler.
Or remove the background parts of your app and write a service to do those instead.
And be very careful when giving your code administrator rights. Any bug can result in subverting the entire security infrastructure. With great power comes great responsibility.
Related
Recently, I once again came across the problem of having to run my Windows app on startup and wondered which of the options is the most usual one and causing least trouble long term.
Registry
Add string value of the path to your exe to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run or \HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run for x86 applications running on a x64 Windows.
Feels the most natural
Fairly easy, especially when using frameworks simplifying registry entry creation
When uninstalling an application, you could end up with a dead registry entry
User won't be able to edit this entry
Autostart
Create a .lnk inside the user or system wide autostart folder (shell:startup).
Able to do it programmatically
Very easy to create, add arguments and modify
User is able to edit entries in his usual environment
Task scheduler
Create a 'When the computer starts' or 'When I log on' run entry in the Task Scheduler.
Able to do it programmatically
There is a GUI, but I would assume the average user won't find it
So what are further considerations when selecting an option?
Registry is always being used by production software, since that's the most controlled way and Windows suggests it.
Pros:
No need to enter the users personal space (powershell:startup)
Option to autostart the software only once (windows cleans up the registry)
Decide if the software should autostart for the whole local machine or the current user
Can be executed even when the machine is started in safe mode by using RunOnce with an exclamation point (!)
Here you can read more information about using Run and RunOnce Registry Keys.
shell:startup(not recommended) is the personal startup folder of the user, where shortcuts are being stored, that have been created & copied over by the user. The user will also experience an error prompt, if the application has been deleted, but the shortcut still remains. [BAD USER EXPERIENCE]
Task Sheduler is great for scripting, conditional event triggering and mostly used by Administrators. This option would be overkill, since Registry is much simpler and doesn't leave a Task Event, that the user has to disable on his own.
There is a GUI, but I would assume the average user won't find it
Task Manager [Startup tab] will display applications that will be automatically executed by Windows (registry & startup), which allows the user to enable/disable the software from doing that, so that's not an issue.
TLDR: Registry is by far the most used and best option to automatically run software.
The registry and start-menu are pretty similar. The registry gives you zero control over the execution, the only setting is the command line arguments. The start-menu uses shortcuts so that gives you the ability to control the working directory and initial window state.
The task scheduler is not the traditional way to launch startup applications. It feels like overkill and that you are trying to be obscure on purpose.
I'm developing a Windows application that must execute other GUI programs with privileges (executed as administrator).
Scope
My application is a "daemon", a long-running process that it will be launched with no user action;
My application must be executed as administrator (privileges elevation);
Processes executed by my application must be executed as administrator and must display on the screen.
Approach
Firstly, I developed my application as Windows service. I thought that it was the best way to run programs with privileges but services can't run programs that use the GUI session.
This restriction has been introduced by Microsoft with Windows Vista. An article from Microsoft - Impact of Session 0 Isolation on Services and Drivers in Windows - explains these changes. I tried to change the user who runs my service but this isolation appears to apply for all services.
Purpose
So my question is "What's the best way to run a program that it will launch another program with elevation of privileges (executed as administrator) with no action from user ?"
Currently, the only once idea to solve my problem is to register my application into Task Scheduler but I think that it probably exists a best way.
Windows Services have not been designed to interact in current session (user session). Services are running into Session 0 since the deployment of Windows Vista.
Explanations about this changes can be found in "Impact of Session 0 Isolation on Services and Drivers in Windows".
I have found another Microsoft post "Launching an interactive process from Windows Service in Windows Vista and later" but we can read at the beginning:
The first thing you should do about it is that, don't do it. There are many limitations, bad implications and restrictions involved into it.
Windows Services are definitely a wrong solution for this use case. The unique solution that I can found is the Task Scheduler.
I am developing a program for Windows which consists of two components:
A kernel driver (signed with an EV certificate)
A user-level GUI component, the .exe file (written in Delphi).
The .exe requires to be run elevated, in order to start the driver and perform other elevated tasks.
How can such a program be automatically run on Windows startup without displaying UAC prompt?
I saw that many similar applications, such as Anti-Malware programs, are able to startup elevated, without UAC prompt.
I am considering the following options, and would be grateful if you can point to the right direction:
1. Set driver startup as automatic, launch .exe from kernel service
However, my research indicates that there is no documented way to start a user-level process from the kernel.
2. Create a separate user-level service which will start the .exe
I read that user-level services are exempt from UAC.
A possible approach would be to create an automatic startup user-level service, which just runs the .exe process (using CreateProcessAsUser()) and then terminates itself.
3. Convert the .exe program from a Delphi GUI application to a user-level service
Similar to option 2, but instead of creating a separate .exe for the service, we are converting the current GUI application to work also as a service.
I found some documentation about this on this StackOverflow thread.
However, this approach seems more complicated then creating a separate dedicated service.
4. Does an EV certificate provide some advantage to allow this task?
5. Is there any better way other then the above mentioned ones?
As it was pointed out by Sertac Akyuz in his comment you should use windows Task Schedluer for this.
With Task Scheduler you can create a task that will run at user logon and run your EXE with highest privileges available.
And when I say highest privilege available I mean the highest privilege of current user when you specify a group of users in When running the task, use the following user account field provided that current user is a member of that group. So if current user does not have sufficient right to execute programs with elevated privileges the task will execute your application with standard privileges.
But as field name suggest you can also specify that this task will always run your application using a specific user account meaning that it will use that account privilege levels instead of of the current user account.
Any way using task scheduler to execute GUI application that comes with some drivers is quite popular. For instance ASUS uses such approach to launch their AI Suite program that allows monitoring and tweaking various settings of their motherboards. Here is how such task is configured on my computer.
PS: I have purposely chose to show you task properties for ASUS AI Suite as it is actually made with Delphi
Firstly I want to emphasize that I'm not trying to do anything "nasty" or "hackerish", nor am I trying to hide anything from user here.
During installations (using InstallShield LE) of my application user is prompted by Windows UAC to allow it to run in Administrator mode; If user accepts it - installation continues (standard behavior) and user again can check the option to add this program to autorun list (by adding a registry key to HKLM/../Run). All is fine and normal. But after every Windows restart, when this application starts, UAC kicks in and asks for user permission. Question is, how to avoid it, since it's a bit annoying (yet my app needs Administrator privileges to run)?
I mean user already granted such permissions on installation, so I cannot see a reason why it needs to be prompted on every startup? Moreover, I believe most antivirus software and such, also require elevated permissions to operate, but UAC doesn't prompt for it at Windows Startup.
Thank you for any advises, information, comments or solutions.
Does your application really need to start elevated? Or will it need to elevated access later when the user uses it to perform an action? If you can, drop the later admin task into a separate exe, allowing the main exe to start with no elevation - when you shellexecute the worker process later it will UAC on demand.
At install time, as you have noted, you have elevated the installer. If you want to run elevated code on subsequent runs, automatically, this is the point to install a service - which is what all those other apps you mentioned do.
You can't get around UAC for a process started in an interactive session. You could use a service running as a privileged user but you would be far better off finding a way to do whatever you do without requiring admin rights.
It's not possible for a program to run elevated without prompting. What you want to do is factor those portions of your application that need elevation into a windows service that runs as system. Then your autostarting application can make remoting calls to the service to delgate those activities that the user can't do without elevating.
Not done it but I found this article Selectively disable UAC for your trusted Vista applications that says use 'Application Compatibility Toolkit' from microsoft.
The Compatibility Administrator allows you to create a database of
compatibility fixes that will allow you to run certain applications
without an accompanying UAC.
Run the Compatibility Administrator as admin
select a new database template
Click the Fix button on the toolbar. When you see the Create New Application Fix wizard ... enter details about your app
Select a Compatibility Level
Select RunAsInvoker as the fix
It seems that the last one
Selecting the RunAsInvoker option will allow the application to launch
without requiring the UAC prompt.
Should do what you want provided that the invoker is admin and I think you can do this at start up using the scheduler : Create Administrator Mode Shortcuts Without UAC Prompts in Windows 7 or Vista
As you can see it runs your app in the compatibility mode which may or may not be acceptable for you.
A colleague has a batch script program which needs to to run on a Windows Server in console mode, so that it has access to a Windows interactive session. The server is rebooted at regular intervals automatically (there's an unrelated closed-source application that runs on this machine that we have no control over). After a reboot he wants to automatically start a Windows interactive session and have this script run, plus the service needs to also have access to network resources (CIFS drives, in particular).
Here's what we've tried so far:
Start as Windows service. This failed, since a Windows service can either have access to interactive session or to network resources, but never both.
Used Microsoft management console to add the script to run at startup, however this did not work.
Used an HKLM registry key to start to run this script, however it only gets started when we manually open a remote desktop session on the server.
Creating a scheduled task. The program invoked did not have access to interactive windows session.
Any other suggestions? (Or maybe he missed something when he set up one of these suggestions?)
In case "Interact with desktop" on the service is not enough (I have seen a handful of cases where it is not), you can combine it with AutoAdminLogon. Create three (or four for a domain) REG_SZ values under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon:
DefaultUsername
DefaultPassword
DefaultDomain
AutoAdminLogon
AutoAdminLogon should be set to the string "1", the others are self-explanatory.
Obviously this has security issues big enough to fly Jupiter through.
Have you tried having your script run as a Windows service, but allowing it to interact with the desktop?
Specifically:
Go to the service properties page
Click on the "Log On" tab
Select "Local System account"
Check "Allow service to interact with desktop"
See my similar question and real answer to it: How to start a process from windows service into currently logged in user's session
NOTE: "Interact with desktop" checkbox is not enough at all.
I recommend going about this another way. You could build another Windows app that communicates via IPC to the Windows Service and that could be what deals with the closed souorce application. But if you must, you can specify an option in the service (you can do this through MMC, registry, etc). Basically, you can see this option by going to Computer Management->Services and Applications->Services->Right click your service->Change account to Local System and check "Allow system to interact with desktop."
However, again, I recommend choosing another path.
I had to do something similar recently; a route that I found but discarded due to security concerns is to have the interactive service set self as running in interactive mode and then run the ImpersonateUser function in the win32 API, which I think will provide the benefits of both a user and the interactive session available from the LocalSystem.
Needless to say, if someone broke into a service that did that, they would have total control of the machine.