I've a app embeded with manifest *.exe.manifest. When I launch executable it shows UAC prompt every time. How can I avoid this? I have element requireAdministrator with attrubute level equal to requireAdministrator. Is that possible at all?
You are seeing the UAC elevation prompt because you asked for it. The operative word here is require. If the user isn't currently running elevated then that's always going to invoke the elevation prompt.
If you don't want that to happen then you do have to replace requireAdministrator with asInvoker. With the side-effect that your program won't run with the elevated privileges or course. And no, you cannot elevate silently, that would defeat the point of UAC. The point of UAC is not to stop you from doing something, it is to let the user know.
Related
Is there a way to mark a .EXE to request it be run as admin? So that:
If UAC is set to runas admin with no prompt - it runs as admin.
If user cannot runas admin (reqires different login), runs as user.
If prompts, prompts user. If accepted, runs as admin.
If prompt declined, runs as user.
I know how to do this with 2 .exe programs. But I'd like to do it with one. This program enters the user's license key. In HKLM if the app has admin rights (so all users have the key). In HKCU if no admin rights.
There is no way to mark an executable so that it will continue to run without admin privilege if the user rejects the elevation prompt. However, a process can attempt to launch a second copy of itself from the same executable with elevated privileges, and either pass the work to the new process (if it launches successfully) or continue the work itself (if not).
See this answer for an example of how to elevate yourself.
You can get 1 and 2 by requesting highestAvailable instead of requireAdmin. I don't like it, though, because throughout the rest of the app you may need to test to see if you're elevated or not.
You can't get #4. If an app tries to launch, shows a UAC dialog, and the user rejects the UAC, the app does not launch. If you have just part of your application that needs elevation, you are best to move that part to a separate exe and put a manifest on that exe that requires elevation, then leave the main app not requiring it.
I used "highestAvailable" in my exe's manifest. But in standard user and UAC ON its not elevating the exe.
Is this the behavior of "highestAvailable"?
I referred this MSDN link but its not clear whether "highestavailable" will elevate the exe or not. My requirement is to elevate the exe if UAC is on.
I changed to "requireAdministrator" and my exe is getting elevated in standard user with UAC ON.
Can someone explain me in detail about the elevation behavior of these two options "highestAvailabe" and "requireAdministrator"?
highestAvailable will elevate if the current user is an administrator. Which is consistent with what you have observed. When a standard user runs the process, no UAC dialog is shown and the process runs with the standard token. When an admin user executes, the UAC consent dialog is shown and the process will then run elevated.
If your program requires admin rights to function then you need to use requireAdministrator. When a standard user starts such a process, the over-the-shoulder UAC dialog is shown. That gives the user an opportunity to ask an admin to supply their credentials.
You should only use highestAvailable if your program is capable of running with a limited functionality in case the user is not able to elevate. This is what is meant by mixed-mode in the MSDN topic linked by your question.
Basically I either need to Click the UAC button with my program(which i don't believe is possible) or somehow make it so I don't need to click the button to install the software. I will also need to click buttons during the install with my program but I know how to do that. I am only concerned with the UAC things.
One way or the other, the user is going to have to click that button to give you permission to proceed. That's the whole point of UAC, if there were a way to work around it, it would serve absolutely no purpose.
You can either ask for permission sooner (at the beginning of your installation) or later (at the point in the installation when the privileges are first actually required), but you have to do it one of those times.
The standard course of action is to embed a manifest in your application that indicates you require administrative privileges. The applicable line looks like this:
<requestedExecutionLevel level="requireAdministrator" />
Alternatively, you could choose to rely on UAC's "Installer Detection" functionality:
The first application compatibility technology that is part of UAC is called Installer Detection. Because most installers write binaries to the Program Files directory, they overwhelmingly need administrator privileges. Installer Detection is designed to scan the name and the resources of the EXE to determine whether an application is an installer. For example, an executable would be marked as an installer if the executable name or description contained the strings "install" or "setup". So an application named setup.exe, without an application manifest, would trigger a UAC elevation if launched by a token without administrator privileges.
Clicking buttons during your install isn't a very good idea, either. If this is an installer that you're writing, code in some "silent install" flags that you can specify when executing the installer app. If this is a third-party installer that you're using, check the documentation; chances are such flags already exist. The point of these flags is that interactive UI is not displayed at all during setup, meaning that no one has to bother clicking any buttons (which is very hard to get right).
you can install your program in the user's home directory or any other directories which is writable without administrator privilege.
if you're writing an installer wrapper, you can ask for UAC on the wrapper and the wrapper can start the real installer(s) with administrator privilege. Most installers also provides command line options for unattended installations, so you might want to check those instead of scripting button clicks.
You can't click button on UAC consent dialog.
Your other options depend on what you really try to achieve. So give us more details on the your task: there could be better design choices than clicking installer buttons from an application.
To avoid UAC, you can install a service which will start the installation. But user has to consent when you install the service.
When a normal user runs a WiX installer which requires elevation, there appears to be a delay of 30 seconds or more between the user clicks the "Install" button and the UAC prompt comes up. This happens even though the install button is marked with the UAC shield, suggesting the installer "knows" that elevation will be required.
Is there a way to IMMEDIATELY throw up the UAC when the user 1) runs the installer or 2) clicks that "Install" button?
The length of time for the UAC prompt to come up depends on the size of the exe. (Try it yourself by right-click run as admin various exes of various sizes.) Therefore I have heard it suggested that you make a teeny launcher exe that will bring the prompt up quickly, and have it launch everything else. Anything launched from an elevated process is elevated.
Be sure to name your launcher well, for the 1% of users who actually read the UAC prompts.
How big is your MSI file? I don't know for a fact, but I think splitting your files into a separate .cab file and possibly digitally signing it might make the validation of the MSI file go faster.
Otherwise, there really isn't anything you can do about it to my knowledge. I hope someone proves me wrong. :-)
I've read several questions regarding UAC and privilege elevation but I've not found a satisfactory/comprehensive answer.
I have this scenario: on Windows 6 or above, when the user opens a configuration window I have to show the shield (BCM_SETSHIELD) on the OK button only if privilege elevation will be required to complete the task. -- I do know that in the Windows UI the shield is always visualized for "administrative tasks", even if UAC is disabled, but the customer had this specific request.
I have draft this condition in order to show the icon:
The user has not administrative rightsOR
The current process has TOKEN_ELEVATION_TYPE == TokenElevationTypeLimited
The condition #1 is simple: if the user hasn't administrative rights elevation is always required regardless of UAC. The #2 implies that the user has administrative rights, and any other value of TOKEN_ELEVATION_TYPE means that elevation is not needed.
Is really that simple? I am missing something? And - there's a documented or well-known pattern regarding this topic?
You are right. Most people just put the shield on if the button will be running elevated, but the right thing to do is to put the shield on if the button will cause elevation (ie suppress it if you are already elevated, since everything you launch will remain elevated unless you go to some trouble to launch a non elevated process, and suppress it if UAC is off.)
The good news is that if someone in the Administrators group runs (under UAC) an application non-elevated, you'll get back false when you ask if they are an admin or not. So I think you might be ok with just that one test.
I see that there is a lot of confusion about this topic and the answer from Kate here is not correct and incomplete.
Since Vista an Admin may be logged in but his processes do not run elevated automatically. An Admin has a so called "Split Token". This means that there may be processes running for the SAME admin user, and some of them run elevated and other do NOT run elevated. When an Admin runs a not elevated process, some of the privileges of his token have been removed. It is not anymore as in XP where ALL processes run either elevated or not elevated.
Install Process Explorer from www.sysinternals.com and enable the column "Integrity Level". If you see there "Medium" this process does not run elevated. If you see there "High" the process runs elevated. If the process runs with Integrity level "High" no UAC prompt is required to start another process elevated.
When UAC is completely turned off, ALL processes run "High", so no elevation is required never. UAC can be turned off under
HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System
setting the key "EnableLUA". Changing this setting requires reboot.
But there is another point that was not yet mentioned here.
In Control panel it is possible to configure "Elevate without prompting". And in this case an Admin user can start an elevated process from another not elevated process and NO UAC prompt will show up.
This setting is stored under the same registry path in the key "ConsentPromptBehaviorAdmin" for admin users.
For all non-admin users there is the key "ConsentPromptBehaviorUser" but this changes only the bahavior, but elevation cannot be turned off. Non-admins will always get an UAC prompt. (if UAC is not completely off)
How do you know if your process runs elevated:
Call OpenProcess(), then OpenProcessToken(), then GetTokenInformation(TokenElevation).
And to get the Integrity Level call GetTokenInformation(TokenIntegrityLevel) and then GetSidSubAuthority()
So if you want to show your icon only if elevation is really required you must check if your process runs elevated and additionally check these registry keys and you must know if the user is an admin or not. This involes several lines of code and I would consider to show this icon always when elevation may be required to keep it simple.
Please note that the API IsUserAnAdmin() is deprecated. It must not be used anymore since Vista. Checking if a user belongs to the administrators group is much more code now.