I have created a Service in C# in which I am performing two tasks.
Task-1: Extracting Windows Event Logs.
Task-2: Sending the desired log (if present) to a Database that reside on another system.
If I run this Service under LocalSystem Account, it successfully performs Task-1 because its System related, but not Task-2 because LocalSystem Account does not have access to Network.
If I run this Service under NetworkService Account to access the Database on other Machine, it does not perform Task-1 because NetworkService Account has Limited access over System resources. Due to this, it is unable to extract Windows Event Logs.
I know that my code is correct because I have tested the whole code in Console Application and it performs both Tasks correctly.
I need the solution through which I can perform both Tasks through a Service.
"If I run this Service under LocalSystem Account, it successfully performs Task-1 because its System related, but not Task-2 because LocalSystem Account does not have access to Network."
This is not true. The LocalSystem account has access to everything on the system, as far as I know, including the ability to interact with the network. I can speak to this from personal experience because I've had a Windows service in the project I work on for almost a decade now, and it interacts with the network all the time. Check out the accepted answer here for more info.
It's very likely that an exception is occurring when your code is running from the Windows service, but does not occur when running from the Console app. Have you tried debugging your service? Have you checked the Windows event log for errors?
I wanted to run local desktop applications which are installed in Program Files and Program File (x86) folders only, the application should run with administrator privileges as logged in user context. I have googled and got to know some.
Required as per my idea:-
File Explorer GUI with Socket Client
A Service
Local Application Launching Executable with Socket Server ( console application)
Note: The communication between File Explorer will happen using socket client and server. The service will launch the local application server in system context.
Imagine that File Explorer, Service and Application Launching server are installed.
Using File explorer the app will be selected and selected application information will be sent to the server. The server will do check on the requested path whether it is from trusted path or not.
If it is from trusted path, the server will get handle from "winlogon.exe" and get the handle to the access token, then duplicate the access token and adjust its privileges (default system privilege will be there and i don't want that as system will have full privileges) then use CreateProcessAsUser to launch the application.
Once launched bring the UI to the foreground. The application need to be run in user context with administrator privileges.
My questions are stated below:-
To achieve this do i need to enable the interactive process in the
service ?
If interactive is necessary, the communication between the
user and local server is happening using socket and user do not
interact with service directly, just wanted to know whether am i
following the Microsoft safety measures as stated in below
documentation or am i breaching it?.
https://learn.microsoft.com/en-us/windows/win32/services/interactive-services
Do we have any other way to launch an application with admin
privileges in logged on user context without actual administrator privilege ?
The targeted OS is Windows 10 1803 and 1809.
Have a look for the tools psexec or paexec (they're mostly identical, the major difference being that the later is open-source).
These tools allow you to start a process as another user and/or on another computer. This should work from a service as well.
Goal:
I periodically upload new .exe file to windows server 2003 via FTP and I want to run it manually by hitting Url of a web site on same server. Exe needs to be run under an Admin account, and not the NETWORK SERVICE account.
What I achieved so far:
I have been able to successfully run applications like notepad under the Admin account on the server via a web request by using any of these:
PsExec,
.net process.Start() with credentials supplied to process.StartInfo and even
by impersonating admin and then using process.Start without credentials (http://www.f4cio.com/programmatically-impersonate-in-csharp)
The problem:
The above methods run my exe but Task Manager, or a call to System.Security.Principal.WindowsIdentity.GetCurrent().Name shows me that it is running under NETWORK SERVICE.
I suspect that this file has added security constraints because it arrived from ftp link. Checking run-as-administrator in properties of file is not an option because file will be replaced periodically and all needs to be automated. Also manual server configuration should be minimal or ideally non-existent. Code-only single-web-page solution is ideal. Editing both that asp.net web page and exe is ok. (I tried something with exe self-restarting).
Not sure about this, but I suspect this has to do with you website running under the NETWORK SERVICE user. Whatever privileges your website-user has, the same are probably granted / passed on as you try to run your executable.
Is this server on an internal network or protected in some other way? (I should hope so!). If so, you might try changing App Pool that the website is running under to an admin account (in IIS, right click the App Pool running the site, select Advanced Settings, and look for the Identity setting). If I'm right, that will allow you to run your executable as an admin too.
Be aware however, that this may increase the security risk of your setup: Allowing your site to run under an admin account means easier access to your entire server if anyone is able to penetrate whatever security measures you have in place. Make sure access to this server is tightly limited, and preferably, that it in turn does not have access to other systems, since that would in turn make them vulnerable by extension.
I have written a Windows service that allows me to remotely run and stop applications. These applications are run using CreateProcess, and this works for me because most of them only perform backend processing. Recently, I need to run applications that present GUI to the current log in user. How do I code in C++ to allow my service to locate the currently active desktop and run the GUI on it?
Roger Lipscombe's answer, to use WTSEnumerateSessions to find the right desktop, then CreateProcessAsUser to start the application on that desktop (you pass it the handle of the desktop as part of the STARTUPINFO structure) is correct.
However, I would strongly recommend against doing this. In some environments, such as Terminal Server hosts with many active users, determining which desktop is the 'active' one isn't easy, and may not even be possible.
But most importantly, if an application will suddenly appear on a user's desktop, this may very well occur at a bad time (either because the user simply isn't expecting it, or because you're trying to launch the app when the session isn't quite initialized yet, in the process of shutting down, or whatever).
A more conventional approach would be to put a shortcut to a small client app for your service in the global startup group. This app will then launch along with every user session, and can be used start other apps (if so desired) without any juggling of user credentials, sessions and/or desktops.
Also, this shortcut can be moved/disabled by administrators as desired, which will make deployment of your application much easier, since it doesn't deviate from the standards used by other Windows apps...
The short answer is "You don't", as opening a GUI program running under another user context is a security vulnerability commonly known as a Shatter Attack.
Take a look at this MSDN article: Interactive Services. It gives some options for a service to interact with a user.
In short you have these options:
Display a dialog box in the user's session using the WTSSendMessage function.
Create a separate hidden GUI application and use the CreateProcessAsUser function to run the application within the context of the interactive user. Design the GUI application to communicate with the service through some method of interprocess communication (IPC), for example, named pipes. The service communicates with the GUI application to tell it when to display the GUI. The application communicates the results of the user interaction back to the service so that the service can take the appropriate action. Note that IPC can expose your service interfaces over the network unless you use an appropriate access control list (ACL).
If this service runs on a multiuser system, add the application to the following key so that it is run in each session: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. If the application uses named pipes for IPC, the server can distinguish between multiple user processes by giving each pipe a unique name based on the session ID.
WTSEnumerateSessions and CreateProcessAsUser.
Several people suggested WTSEnumerateSessions and CreateProcessAsUser. I wonder why no one suggested WTSGetActiveConsoleSessionId, since you said you only want to target one logged in user.
Several people sure are right to suggest CreateProcessAsUser though. If you call plain old CreateProcess the way you said, then the application's GUI will run with your service's privileges instead of the user's privileges.
That problems Session 0 , Interactive Services ,
Windows Service Allow Service To Interact With Desktop
on Windows 7 or Windows Vista
You can read this article
http://www.codeproject.com/KB/vista-security/SubvertingVistaUAC.aspx
I try explained here it's working on Windows 7
On Win2K, XP and Win2K3 the console user is logged on in Session 0, the same session the services live in. If a service is configured as interactive, it'll be able to show the UI on the user's desktop.
However, on Vista, no user can be logged on in Session 0. Showing UI from a service there is a bit trickier. You need to enumerate the active sessions using WTSEnumerateSessions API, find the console session and create the process as that user. Of course, you need also a token or user credentials to be able to do that. You can read more details about this process here.
I think as long as you have only one user logged in, it will automatically display on that user's desktop.
Anyway, be very careful when having a service start an exe.
If the write access to the folder with the exe is not restricted, any user can replace that exe with any other program, which will then be run with sytem rights. Take for example cmd.exe (available on all windows sytems). The next time the service tries to start your exe, you get a command shell with system rights...
If you launch a GUI from your service it will show up on the currently active desktop.
But only if you adjusted the service permissions: You need to allow it to interact with the desktop.
Important Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code.
This is taken from : http://msdn.microsoft.com/en-us/library/ms683502(VS.85).aspx
I wrote a C# application using RESTful web services. This application should interact periodically with our server application. I want this program to keep running in the background even if the user logs out of the computer. How can I do this in C#?
If you don't want your application to stop when the user logs out, then the application can't be running in the user's session (really a WinStation). That implies your app needs to run in a different session. The sessions that don't logout are service sessions. Run Task Manager and add the Session ID column, and view all processes, and you'll see what I mean.
So your application needs to run as, or be launched by, a service.
In addition to the first answer don't keep the service running under the specific user account. If you do so then also it won't work if you logged off.