I have a non-interactive service running as a the privileged SYSTEM user on Windows machines, and I need it to launch a given executable as an elevated process.
I have managed to launch a child process as SYSTEM, using WTSGetActiveConsoleSessionId(), finding a system process and duplicating it's token. Similarly, I can launch a non-elevated process as a regular user. But I need to launch the process as the regular user, but with elevated privileges - so that I don't have to show UAC, but the process is running as the appropriate user.
I am not trying to bypass UAC - since the user already agreed to installing the service. I am trying to mitigate an inconvenience. I have found a similar, unanswered question - but asked again in hope of maybe getting an answer.
If you have a filtered token for the interactive user - for example, one retrieved via WTSQueryUserToken() - you can retrieve the unfiltered ("elevated") token by using the GetTokenInformation function with the TokenLinkedToken option.
Related
Objective:
As the title indicates, I would like to retrieve the command-line arguments of processes running on a Microsoft Windows server in the context of a monitoring tool.
Since the tool is used to monitor a critical system, there are some constraints (let's not argue about them, they can't be changed):
The protocol used for monitoring has to be WMI.
The monitoring tool has to use a dedicated user mon-user.
This user will under no circumstances get (complete) Admin rights on the machine; however specific, individual permissions might be granted if necessary.
The tool shall retrieve the command-line arguments of (java)processes launched by any user, not only mon-user.
Progress: When I log on to the monitored system as mon-user, I am able to retrieve the process names and command-line arguments for processes launched by mon-user using the PowerShell command Get-WmiObject Win32_Process | Select Name,CommandLine. This shows the names for all processes (including those launched by other users) but only shows the command-line argument for processes launched by mon-user itself.
When I use the same command from the user account which launches the processes, I see the command-line arguments for processes of this user, but not for mon-user.
I do not have access to an admin account so I cannot verify if the admin is able to see the command-line arguments for processes launched by both users.
Question: From the observations above, I conclude that retrieving the command-line argument is linked to process-ownership (or admin rights as suggested by various other forum discussions). I would like to know, if there is some privilege, permission or user right that I could grant mon-user in order to get the required information.
Thanks in advance for your replies.
After some (administrative) effort I managed to work out a solution:
As part of the start-up of the processes I am interested in (my team has access to the source code), we implemented a change to the DACL by the process itself giving mon-user the additional permissions PROCESS_VM_READ and PROCESS_QUERY_INFORMATION.
Many thanks and a +1 to eryksun for the helpful comments.
I want to execute two files after installation is finished but i don't want them to shows UAC dialogs. I have tried to use maximum execution level but its not working.
I am assuming that the executables are launched outside of the "Install Execute" sequence. I am guessing you are trying to launch these executables when the user clicks on the "Finish" button on the Installation Finished dialog.
With UAC, applications and tasks always run in the security context of a non-administrator account, unless an administrator specifically authorizes administrator-level access to the system. i.e even if you are logged in as an administrator, any application that you run does not run with full administrative privileges. Each application that requires the administrator access token must prompt the administrator for consent. When an administrator logs on, two separate access tokens are created for the user: a standard user access token and an administrator access token.
The standard user access token contains the same user-specific information as the administrator access token, but the administrative Windows privileges and SIDs are removed. The standard user access token is used to start applications. The standard user access token is then used to display the desktop (Explorer.exe). Explorer.exe is the parent process from which all other user-initiated processes inherit their access token. As a result, all applications run as a standard user unless a user provides consent or credentials to approve an application to use a full administrative access token.
In your case, I am assuming that the msi package is being installed from a non elevated command prompt. Hence, the msi package is being run with standard user privileges. So, any child processes which are spawned from this msi package outside of the InstallExecute sequence will run with standard user privileges.
For an application to be UAC compliant, the application needs to specify the "requested execution level" in the application manifest. Requested execution levels specify the privileges required for an application.
What is the requested execution level in the application manifest for your executables? You can verify the requested execution level specified in the embedded manifest of your exectuable by making use of a tool from the Sysinternals suite called "sigcheck.exe".
Verify the requested execution level. I am thinking that its set to "requireAdministrator" because of which you are being prompted for elevation. Change this to "asInvoker" and then your problem should be solved.
You can read more about UAC at the below location:
https://technet.microsoft.com/en-us/library/jj574202.aspx
Delphi XE app running on Windows 2012 Server. How do I limit the user's permissions when they open Adobe Viewer using ShellExecute. As it stands now, the uses are not permitted to see the drivers on the server. However, when the user opens a pdf from the application, the permissions revert back to admin, which allows them to see and access the drives.
Are there settings within ShellExecute that can apply the proper permissions based on the user login credentials?
When you create a process using ShellExecute, the new process runs under the credentials of the parent process. So it would seem that the process with is calling ShellExecute has more rights than you wish to grant to the process that is started by ShellExecute.
One way to solve the problem would be to call ShellExecute from a process running under the desired credentials. There may be other ways to solve it, but without any knowledge of your network security configuration, it's unlikely that we can give you much more specific advice.
I have a process that runs as LocalSystem on Windows XP and following. I am trying to find a way to have it start another process impersonating another user without having to provide the user password.
In principle this should be possible as LocalSystem has the privilege "Act as part of the operating system". But I am unable to find the correct API.
Can somebody tell me how to do this either:
with an API, or
from a batch file?
You can do it by first getting the token of the user via WTSQueryUserToken, then calling CreateProcessAsUser to start the process. Note that you can only do this for a user who is currently logged-in in the system.
Operating system is Windows 7 or higher with UAC enabled. Calling process has admin rights, already confirmed by the UAC box.
I want to spawn a new Console window (cmd.exe) under user SYSTEM (don't ask why). I can do this interactively by using PsExec tool from Sysinternals or something similar, but I don't have the source code and I need to understand how this works.
I understand that I have to call CreateProcessAsUser() and that works fine with the first parameter (hToken) set to NULL, but now I need to know how to get the hToken. I understand that I can get such a token by calling LogonUser() - but not for SYSTEM. How would I get the token for SYSTEM?
I thought of using DuplicateTokenEx(), but that requires an original token, that I don't have.
Would I have to query the process list, find any SYSTEM process and try to get that token duplicated or something? I don't want to reverse engineer the PsExec tool or one of the others doing exactly this.
Typically you would install and launch a service, configured to log in as SYSTEM. You can then use OpenProcessToken and DuplicateTokenEx to make a copy of the token.
You will probably need to use SetTokenInformation to change the session ID for the token to match that of the interactive user. You need Act As Part Of the Operating System privilege to do that, so you should do this from inside the service itself. Once the duplicate token is ready to use, you can use DuplicateHandle to copy the handle into the administrative process, or (with the right options) you could launch the command shell directly from the service too.
alternative open the winlogon process with maximum permitted access, try to open the process token, (also with maximum permitted) and then try to duplicate this winlogon handle with impersonate rights. On win8.1 this will succeed. On others, you will need to temporary change the token dacl, with either a null or your own admin process token