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.
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.
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.
I am installing a per-machine .msi with elevated rights which runs a exe before install finalize. this exe changes a lot of different stuff and one of these requires to use the local user profile which I get using environment.specialfolder.userprofile enum. the problem is that my exe and msi needs to run with elevated rights so it is using the admin user profile.
this question is really similar to this one: Run unelevated custom action from a WiX elevated installer
any thoughts on how to solve this without pulling out the non-elevated actions of the exe and creating another custom action?
I have several thoughts. The first is out of process EXE's are generally a bad idea because you lose the declarative, transactional nature of MSI. MSI can't undo, monitor, repair what it doesn't know about. The administrator can't see or transform what is being done by the EXE.
The second is managing per-user data is a pain. However if you must do it, the best technique is to split the stuff that is per-machine and requires elevation into one custom action and the stuff that is per-user and doesn't require elevation into another. Then use the Active Setup registry key to detect when another user profile has come into scope and run the MSI in repair mode to apply the per user data to the new current user.
I would have to know what this EXE is doing to give you best practice suggestions to improve the overall quality of your installer.
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.