We have a ClickOnce application that starts an external process with
p = new Process();
p.StartInfo.WorkingDirectory = Path.GetDirectoryName(exe);
p.StartInfo.FileName = Path.GetFileName(exe);
p.StartInfo.Arguments = arguments;
p.Start();
Usually, people ask whether it is possible to start the process as administration. But in my case it is the opposite:
I would like to make sure that this application is started as the user that is logged on. By default, that happens - for example when I test it.
But some users (Windows 8.1) report that the exe is started as administrator. For some weird reason, Windows automatically wants to start it as admin, even if it would not be necessary at all. If they right click on the exe and check the Properties, the box Run this program as an administrator is not checked!
When checking the exe file in the folder, it shows a UAC icon (example below):
Now I am wondering if it is programmatically possible to prevent that behavior and start the process in non-elevated state, maybe with a StartInfo property?
If application requires UAC, there are two reasons:
There is a manifest (embedded into executable, or external one) which requires that.
Windows decided, based on certain conditions, that application needs evelated permissions.
Since as you say in your question, the same executable does not require UAC on certain machines while does require on others - most likely there is no embedded manifest and that is Windows who decides this application needs evelation.
Here you can find somewhat dated, but I hope still relevant architecture of UAC. Under "Installer detection technology" you will see that even simple things like "The file name includes keywords such as "install," "setup," or "update." might cause windows to force UAC on that executable. First check if this somehow helps you to solve your problem (like maybe on some machines executable matches some of those criterias).
If that does not help, and because embedded manifest is unlikely - you can try to create external manifest for that exe (you can do this automatically before starting process) in which you request requestedExecutionLevel asInvoker. Put that manifest (it should be named .exe.manifest) near problem exe (not your clickonce application) and see if that helps. Hope you know how to create manifest file, if not - you can easily find that on Google or ask here. Note that if executable has embedded manifest already - it will have a priority (but that is unlikely).
Maybe this will help you?
launch C# exe without prompting UAC on Windows 7
Add this to your manifest:
requestedExecutionLevel level="asInvoker" uiAccess="false"
"It could be that your third party DLL has to run in elevated mode, so your best option is to run as administrator. Bypassing the UAC prompt without running as administrator is a long complicated process"
You're doing it right by not specifying any account information when creating a new Process instance: that'll rely on the default behavior of using the same user account running current process.
As for some users getting the "Run As Administrator" prompt:
it may be that the security rules on the machine somehow identified the executable as not safe. Try to ask your customer to check whether in the properties page of the app they see an "Unblock" button. If so, let them click the "Unblock". That will eliminate that UAC prompt in the future.
Related
I have two application which is a main and a sub. both can also be opened separately and the main can also open the sub.Since the main application is in the administrative mode, the sub-application when opened from the main application is also opening in the same mode. Is there any possible way where can I open the sub-application in a normal but I need to have the base application running in the admin mode. The problem is I need to drag and drop files in the sub-application which cant be done when the application is in administrator mode.
Getting rid of Adminsitrative Privileges is surprisingly hard. It is nigh impossible to get rid of them, like starting a non-Elevated Process from a elevated one. It is a a vexing property of Windows.
There are ways but they usually involve unmanaged code (Windows API) and are not that stable.
It is possibly if you have the Application user/System Adminsitrator Specify a specific Windows User that he he maintains explicitly as one without Administrative Privileges. The way most non-elevated Services are started is by a explicit Windows User that is set in the Service Manager.
Most programmers eventualy settle to dodge this Problem entirely via an approach like this:
Have both Process A and B designed to always start non-Elevated (no Manifest or anything demand Elevation)
Modify Process A to detect that it is non-Elevated right now
Let Process A try to start a Elevated copy of itself via Runas with proper Options.
If the user is always Elevated (because the UAC is turned off or soemthing like that), it is out of your hands.
As I learned the hard way, there is also a chance that elevation might fail due to faulty Windows configuration. Again, this is out of your hands.
Of course there is the big question of why this is a Problem to begin with and if that is perhaps a XY Problem. Drag & Drop might have those limits. But do you have to use D&D for this? There are many ways to go about Interprocess Communicaiton. Most of them do not suffer such Limitations. D&D is just one of them.
I'm working on a small piece of software which is designed for some special Windows based kiosk devices. It listens for certain keystrokes/commands using a driver, intercepts them and performs certain actions.
At the minute, I've got my Proof of Concept working great. I can either run it as a console application in the background, or I've also built it as a Windows Service. The Windows Service is really effective and is working well, but a colleague has hinted that it'd be good to be able to do tasks based on what user application/window is active - something I can't do (legitimately) from a Windows service because it can't enumerate user applications.
The obvious solution would be to simply run it in the background - no drama there, except these kiosks use a custom Windows shell (Deployed using Group Policy). Because of this, the normal explorer Run keys don't initialise. I'm now at a loss on how to make my software autorun in this scenario?
Alternatively, if someone has a workaround for enumerating active windows and such for a specific user from a Windows service I'd be interested in that. NB: I don't need to actually do anything TO the desktop, just read data.
Windows Vista and above won't let a service interact with desktop apps at all, part of the new focus on security in the OS. I have something similar (in spirit) that I developed for an application system, which enumerates windows looking for a specific legacy app then sends some messages to it (all very much above-board, no other way to automate the creaky old app). I just launch it as a system-tray app when people log on, using Group Policy. But I don't have the issue of a custom Windows shell that you're apparently dealing with. Good luck!
So, userinit (HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\) probably isn't a particularly bad place to do this, but there should be an alternative or two. It's actually a little silly (if you ask me) how many Autorun locations have cropped up in Windows over the years.
The following is largely copied from http://www.bleepingcomputer.com/tutorials/windows-program-automatic-startup-locations/, with an update or two. I figured it might be handy here, too, and who knows what will remain live on the web forever (or not)?
Other Autorun locations include the following in order:
Boot device drivers
Hardware related.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
Windows does some housecleaning then starts Winlogon, which starts the service control manager, which starts services and drivers.
Services
The SCM launches services and drivers that are marked with a Start value of 2.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services
RunServicesOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
RunServices
HKLM/.../RunOnce entries won't run until these finish starting.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices
** The logon prompt is shown, user logs on, then auto-start processing continues.
Notify runs programs in response to events, including logon, logoff, startup, shutdown, startscreensaver, stopscreensaver. Malware often uses this key to start itself.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify
UserInit specifies programs that should be launched immediately after a user logs on, takes a comma-separated list of programs. The default userinit.exe program loads your profile. Also a common key for malware to use.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit
Shell contains a comma-separated list of programs that userinit.exe will launch. The default shell is explorer.exe. First the program(s) in HKCU are launched, then the ones in HKLM.
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
** The rest of the Autostart locations are processed now...
RunOnce (HKLM) Primarily intended for setup programs, deleted by the OS after the first run if the path is preceded by an exclamation point (!), else deleted before the program runs. These programs are started synchronously in an undefined order, so they must all complete before the HKLM/.../Run, HKCU/.../Run, HKCU/.../RunOnce and Startup folders can be loaded. These keys are ignored when booting in safe mode.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx
Run Most common startup locations for standard programs to autorun from, ignored in Safe Mode unless prefixed with an asterisk (*).
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
Startup Folder (All Users)
Win7 and up %ProgramData%\Microsoft\Windows\Start Menu
Win XP/2K C:\Documents and Settings\All Users\Start Menu\Programs\Startup
Startup Folder (Per User)
Win7 and up %USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
Win XP/2K %USERPROFILE%\Start Menu\Programs\Startup
RunOnce (HKCU) intended primarily for setup programs, same semantics as the HKLM RunOnce key (above).
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
Explorer Run generally used to run programs as per policy configuration.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
Load Key deprecated, not commonly used anymore.
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\load
AppInit_DLLs this registry value contains a list of dlls that will be loaded when user32.dll is loaded. Many programs load user32.dll, so anything listed here gets loaded into all of those programs, as well. Used by malware.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows
ShellServiceObjectDelayLoad similar to the Run key, but points to a registered CLSID InProcServer value. Files listed under this key are automatically loaded by Explorer when the computer starts, early in the startup process.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad
SharedTaskScheduler Files listed here run automatically when you start Windows.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\SharedTaskScheduler
Other potential autostart locations, depending on the OS:
c:\autoexec.bat
c:\config.sys
3 . %WINDIR%\wininit.ini - Usually used by setup programs to have a file run once and then get deleted.
%WINDIR%\winstart.bat
%WINDIR%\win.ini - [windows] "load"
%WINDIR%\win.ini - [windows] "run"
%WINDIR%\system.ini - [boot] "shell"
%WINDIR%\system.ini - [boot] "scrnsave.exe"
%WINDIR%\dosstart.bat - Used in Win95 or 98 when you select the "Restart in MS-DOS mode" in the shutdown menu.
%WINDIR%\system\autoexec.nt
%WINDIR%\system\config.nt
I've got the end result I want by adding my application to the UserInit registry key:
HKLM\Software\Microsoft\Windows NT\Current Version\Winlogon\
Userinit c:\windows\system32\userinit.exe,c:\myapp\myapp.exe
This works great, but does seem incredibly hacky and I'd love alternatives.
Using a Windows Service is the best option and since services are isolated in Session 0, you can have this service starts another exe upon user logon, by calling [CreateProcessAsUser][1]. In fact, the service executable can call itself with a parameter indicating that it is invoked as a user and therefore all User Interface parts (which normally won't work from Session 0), will be enabled.
I've got error message :
Requested registry access is denied
when trying to write into registery keys with turned on UAC :
RegistryKey.OpenRemoteBaseKey(Microsoft.Win32.RegistryHive.LocalMachine, "")
tawkey.OpenSubKey(x, true).SetValue(X, V, RegistryValueKind.DWord)
Must I run "subinacl /subkeyreg HKEY_LOCAL_MACHINE\PathToMyKeys... /grant=user=f" during My software installation ? Or there is some other way to have access to my registry keys ?
Thank you.
If you wish to write to keys under HKLM, you need an elevated process. This is achieved by setting requestedExecutionLevel to requireAdministrator in the application's manifest.
Making this change means that your application will present a UAC elevation dialog every time it runs. This will no doubt be irritating and so here are some options of avoiding that irritation:
Write to somewhere other than HLKM where standard users have write access.
Perform the writes to HLKM in your install program.
Arrange that you elevate on demand if writing to HLKM is only needed for occasionally used functionality in your program.
Option 3 needs a little elaboration. You can't elevate a process once it has started. You can only elevate at process start time. So in order to implement option 3, you need that functionality to exist in a separate process or out of process COM server. If you go down this route remember to include the shield icon on any UI element that results in a UAC dialog.
I'm writing a software for a call-center. It's somewhat like a ATM program: user can only interactive with it, not with underlying Windows. It takes controls when user logs in to Windows, and when user exits, it logs off Windows.
How can I do that in .NET? A demo will be much appreciated.
Thank you.
Replace the Windows Shell.
By that I mean Explorer.exe, by means of editing the Windows Registry. What this does for you is instead of logging on and the system running Explorer.exe which consists of the Start Menu, Taskbar and other similar features you are familiar with, it only runs your program. There is no desktop, no context menu, no taskbar, or start menu. Thus, making your application "The Shell" or the new "Explorer.exe".
However, by doing this the user still has access to Control+Alt+Delete, so they would still be able to access the Windows Task Manager, which mind you can also be disabled via a simple Registry Key Entry.
This is the most pain free, easiest solution because you don't even have to worry about things such as disabling the WindowsKey or other annoyances.
The registry key to this is as follows:
SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
The name of the value to modify is:
Shell
And you can simply enter the value to be the fully qualified path to your program's executable file. You will only want to do this under HKEY_CURRENT_USER and only for the account that is to run your shell program. So you will need two separate accounts.
Administrator account
This account will just be a normal password protected account that will be used to manage the system
Kiosk account
This account will be the account that is logged on at all times, which runs your custom shell (your application)
Additional Notes
To disable the Task Manager the registry path is as follows:
Software\Microsoft\Windows\CurrentVersion\Policies\System
The name of the value is:
DisableTaskMgr
This is a DWORD value which to enforce the policy must be set to '1'.
What I did was to use DirectX and just use full-screen and exclusive modes, which you can see a small example of here: http://www.directxtutorial.com/tutorial9/b-direct3dbasics/dx9B2.aspx.
This is more work, but it will allow you to do what you want.
Depending on what control you have, there are steps you can do with group policy to limit what people can do on the computer. You can look at how people set up a kiosk application on Windows for some ideas.
What you want to do is run the OS in "kiosk mode".
This entails using the Group Policy Management Console to apply the kiosk mode template - as part of this you register your application as the shell.
As such there is no taskbar, or explorer view to fall back on to. The only way to run the usual shell would be to connect a keyboard to the system - press ctl-alt-delete and run explorer from the taskmanager that pops up.
And you can disable even the standard task manager if users are going to have keyboard access to the console. You will want to implement some kind of launch explorer.exe interface otherwise the system might become a bit difficult to manage :P
You can set your applications window to be always on top and to cover the entire screen. If you exclude buttons that close the window the user must know that ALT+F4 closes the window in order to exit. This has been good enough for me those times I've needed it.
Has anyone managed to get administration rights through the UAC without restarting the application or embedding a manifest file?
I'd like to write to some files that only administrators can modify, without relying to another elevated application. Is it possible to impersonate an administrator previously calling with some native API the UAC prompt?
I guess this is not possible and I'll have to use an external tool with elevated rights, but I'm asking just in case.
EDIT: I know there are some other similar questions around, but since they do not cover the topic of impersonation (as fas as I've seen), nor some possible native call to the UAC prompt I decided to give a new thread a go...
As stated in this other question, it is not possible, you have can eleveate COM object or another process, but not the current process.
Request Windows Vista UAC elevation if path is protected?
I read that thread (along with a lot more heh), but you never know what other people has managed to do recently. And maybe the release of SP2 changed something, dunno.
Well, I guess there are no changes on how the UAC works nor any discovery on workarounds, so I'll mark the previous answer as the right one.
I'll make another application that performs the administrative tasks I need.
Thank you.
If all you want to do it get admin rights without a manifest (ie: im assuming you're not talking about cracking/hacking the UAC implementation), then just create a shortcut with the "Run As Admin" checkbox checked. You can programmatically generate this shortcut as long as you look up how short cuts are written (in terms of their fiel contents) and I'm sure there is some name/value pair you will need to include inside the shortcut to ensure that Run As Admin is checked by default. Now, when people run that shortcut instead of your exe, they will get prompted to run your exe in elevated mode (with admin rights), and this way you will not need to restart or use a manifest.
Excuse me if I have misunderstood your question.
Adding a manifest file in the same directory as the executable "works for me". Not actually getting the permissions, but it prompts for the permission.