Is it possible to run handle.exe (from sysinternals) from a service (in windows7) without having to turn off UAC?
The service is a custom c-app that needs to find out which process is locking a file it tries to access and handle.exe seems to be a good way to solve it but i can't get it to work with UAC turned on. This app runs all the time so i can't have a UAC prompt while its running but its fine if it shows up at startup.
Handle.exe works fine from an admin commandprompt but fails when trying to run from a normal prompt.
I call handle.exe from CreateProcess() and get the output from pipes. I guess there should be a way to solve this but i can't figure it out. Setting up the service to log in from an admin account does not seem to work.
UAC does not affect services (it only affects interactive sessions) so that should work.
However, if you don't want to move your entire program into a service then there are better ways to do this which don't require creating, installing and managing a separate service process in addition to your main program.
If your program requires admin rights to work at all, and this isn't the only place it will require them, then you could flag your program (via its embedded manifest resource) as requiring administrator rights. It will then trigger one UAC prompt whenever it is run and be run with full admin rights, including the ability to run Handle.exe.
On the other hand, if this is the only place where your program needs admin rights, it may make sense to create a COM DLL which wraps your Handle.exe call (or any other admin work) so that you can use UAC to make elevated calls to that function from your non-elevated app. You will then trigger a UAC prompt each time you create (an elevated version of) that COM object. You can keep the COM object open as long as you want, and create it whenever you want, so when and how often the UAC prompt(s) appear are still up to you.
Both 1 & 2 are standard uses of UAC so any good documentation or tutorial on UAC will describe how to do them in detail.
You may want to look at the Win32 API method CreateProcessWithLogonW.
There is also an elevate VBS script here you may learn from: http://technet.microsoft.com/en-us/magazine/2007.06.utilityspotlight.aspx
Related
I am wrote a .Net Windows C# Application:
I have add a manifest application file (Visual Studio template)
Have changed requestedExecutionLevel to "requireAdministrator" level:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false">
The application contains a basic Console.WriteLine("hello world") code.
When I run the application by double-clicking on the .exe icon, I get an UAC popup confirmation.
But if I run this application through ssh shell, I get non confirmation and the application is running ! How can I do to forbidden application to run if UAC is not confirm by user ?
Thanks
UAC prompts are actually manually launched by the program starting a new process. Windows Explorer does this, and so does cmd for example, but not necesarily any other program.
Another consideration is that a SSH server is often running as a service, and services aren't affected by UAC (by the simple fact that services have no UI at all). A remote command line would have no way to present the user a prompt so it's expectable to not to be presented one.
How can I do to forbidden application to run if UAC is not confirm by user ?
You can't.
Administrator manifest are a convenience feature intended for programs explicitly looking for them, but not mandatory at all. For instance, UAC can be disabled altogether or configured to never ask, and programs may still not run with full admin access, but with whatever privileges the user has.
If your program really requires admin access to operate, be sure that your own code checks for them and exits gracefully in such case.
I have a console application written in c#, which downloads a file to program files. So of course it needs to run as admin. This program gets called from a Win32 C++ application which almost certainly is not running as administrator
What are my options. How can I get this to work on UAC and non UAC enabled boxes ( I don't know if there needs to be separate solution in each case )
Oh and the console app is in .NET 2.0
On a machine with UAC you need to include a manifest resource to specify that you want the process to run as administrator.
On a machine without UAC you will simply have to instruct your users that they need to run it as a user in the administrators group. Almost all users of XP (the version that you will most commonly encounter without UAC) are in the administrators group so you won't encounter many problems.
I never tried it, but this can probably be done using the
CreateProcessAsUser Function.
I have a program, which users sometimes want to restart with administrative privileges to perform administrative tasks.
Currently, it has a menu item, which does the following call:
Process.Start(new ProcessStartInfo("self.exe") { Verb = "runas" })
That works if program is installed with MSI. It displays a usual UAC prompt, which lets user to elevate the program.
However, when converted using Desktop Bridge converter, and installed the Store way, this call crashes due to insufficient privileges. Is there another way for me to (re-)start self with UAC prompt?
Alternatively, is it possible to perform elevation using COM?
I am on release branch, Creators Update btw
Is there another way for me to (re-)start self with UAC prompt?
No. According to this page (https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-prepare, look for Your app requires UIAccess), it seems that requesting the UAC prompt from your app is not currently supported.
Remember, as a UWP app, it needs to work while running as the interactive user.
There is a one-year-old post from MSDN that answers a similar question: https://social.msdn.microsoft.com/Forums/en-US/a35b4c70-5fc6-4f1a-b80a-b11ee90105eb/uwpdesktop-bridgeproject-centennial-appconverter-convert-admin-apps?forum=wpdevelop
Alternatively, is it possible to perform elevation using COM?
Given the findings above, the answer is probably no.
If I were in your position, I would rethink these Administrative tasks. They might even be something that you would not be able to run as a UWP app anyways. For instance, any attempt to create an HKLM key will fail.
I dont know if this has to do with how the program is programmed or how it is set up or how it is started.
But I created a program in WPF and I would like to make sure that none of he regular users on the computer shut it down.
The regular users need to be able to interact with it but they should not be able to close it.
The correct approach would be to run the application as a service with permissions set by the administrator to not let the user manipulate the service. Otherwise you will run into trouble with user-initiated shutdown and with preventing the application from being terminated.
If it is the case that the OP wants to prevent visibility of the OS, creating a terminal like experience. The best way to do this is to create a shell replacement.
Then the user wouldn't see the OS as windows directly.
I am having an issue with UAC and executing a non interactive process as a different user (APIs such as CreateProcessAsUser or CreateProcessWithLogonW).
My program is intended to do the following:
1) Create a new windows user account (check, works correctly)
2) Create a non interactive child process as new user account (fails when UAC is enabled)
My application includes a administrator manifest, and elevates correct when UAC is enabled in order to complete step 1.
But step 2 is failing to execute correctly. I suspect this is because the child process which executes as another user is not inheriting the elevated rights of my main process (which executes as the interactive user).
I would like to know how to resolve this issue. When UAC is off my program works correctly. How can I deal with UAC or required elevated rights in this situation?
If it helps any, the child process needs to run as another user in order to setup file encryption for the new user account.
The reason why the spawned process has no admin rights when using CreateProcessWithLogon and CreateProcessAsUser is explained in this blog post:
http://blogs.msdn.com/cjacks/archive/2010/02/01/why-can-t-i-elevate-my-application-to-run-as-administrator-while-using-createprocesswithlogonw.aspx
Long story short: CreateProcess is such a low layer in windows it doesn't know about elevation. ShellExecute(Ex) does. So you have to create and start a bootstrapper application with CreateProcessWithLogon/CreateProcessAsUser which in turn (now acting as the other user) starts your final application with ShellExecute(Ex) which will ask for admin rights (if you specify "runas" as lpVerb or provide a manifest for your app). And because this is such an easy and fun task to do there is no ShellExecuteWithLogon function provided by Windows.
Hope this helps.
Just faced a similar issue on Windows 7 under maxed UAC.
When UAC is turned ON, CreateProcessWithLogon creates a restricted token, just like LogonUser with LOGON32_LOGON_INTERACTIVE would do. This token prevents elevation.
Solution is to first call LogonUser with LOGON32_LOGON_BATCH, which returns a full-access token. Once obtained, just call CreateProcessWithToken.