I would like to enumerate child windows of a given process to check for dialog windows. For reasons I won't go into here, if it finds any, I'd like to subsequently kill that application.
Running a standalone application to do this works without any issues. The application has access (via some P/Invoke calls) to a process's windows and I can subsequently kill that application.
Running the same code as a service, however, does not work as expected. It seems that the user running the service is not able to interact with the desktop (which is a setting I can only see for the LOCAL system account).
Does anyone know of any workarounds to this? Is it possible for me to enumerate a process's windows from a windows service?
FYI -- the code (at least an adaptation of) I'm using is available here: https://stackoverflow.com/a/1405088/2115261
You're probably running Windows 7 (or 8 or Vista), because the ability for Windows Servcies to interact with the desktop was last supported in Windows XP.
There is a white paper on MSDN that describes the changes made for Vista and upwards. Basically, it is now not possible to interact with the desktop in any way.
However, there is an example on CodeProject that demonstrates how to interact with the Task Scheduler from a Windows Service, and the process executed by the Task Scheduler can interact with the desktop. Perhaps this would be a suitable workaround for you.
You can only enumerate windows on the same terminal services session (aka Remote Desktop session) as your process. However, given appropriate privilege, you can launch a subprocess in another terminal services session to do the work on your behalf, although you need to be aware of the potential security issues depending on how you do this.
Assuming that you've already got a handle to the target process, the simplest approach would be to use OpenProcessToken to get a token in the target session, DuplicateTokenEx to duplicate it, and CreateProcessAsUser to launch the subprocess. Since all you need is a yes/no answer, you can use the process exit code rather than needing an IPC mechanism.
Security implications: since your subprocess is running in the user's context, a knowledgeable user could prevent it from running properly. Also, if you do use an IPC mechanism, you'd have to treat the input from the subprocess as untrusted (check for buffer overruns, etc.).
An alternative approach would be to launch a subprocess in your own context but in the target session. IIRC, you can do this by duplicating your own token and using SetTokenInformation on the duplicate to change TokenSessionId before launching the subprocess with CreateProcessAsUser.
Security implications: the subprocess, and through it the service process and the service account, could be subject to shatter attacks (malicious window messages) and other risks, although the integrity level mechanism may mitigate this to some extent. It is my understanding that creating a separate window station and desktop (with appropriate ACLs) eliminates these risks, but I'm not sure offhand of the impact on the code you want to run. Another mitigation would be to use CreateRestrictedToken to remove all groups and privileges from the token before launching the subprocess.
Unless it is absolutely essential that the user not be able to subvert your ability to detect the existence of the dialog window, I strongly recommend the first approach.
If you give the service a local system account to log on with, you will be able to tick the "Allow service to interact with desktop" checkbox in the service's properties (from Service Control Manager).
See the "Log On" tab of the Service's Property Pages.
That might work for you. But unfortunately, it probably won't. Still worth a quick try?
Related
I've been asked to write a C# application to run on a Windows 7 machine to display the time of day, weather, etc.. That I can do. What I'm looking for is guidance to run the application on a Windows7 machine without logging as a user. In essence the machine would simply be a CPU with a screen. No keyboard or mouse. I've seen deployments done on MS-PixelSense (use to be MS-Surface) using a service ID.
If I need to signin, user policies kick in, screen savers enable, etc.. I'm assuming if I use an automatic Service ID, I can let the application override most of the settings keeping the screen on and needed privileges assigned / locked down to the service ID.
Any information / suggestions are appreciated....
First, some background informations:
Accessing a network share
If a process running on your client wants to access a (CIFS) share, it has to be run under a user account (or "Service ID") which has access rights to this share. There is a way (if the client is a member of Active Directory) that the machine name appended with $ (which is in fact the machine account’s name in AD) has to be entered in the ACL (Share / NTFS), but this is not a very "usual" way.
See also https://serverfault.com/questions/41130/network-service-account-accessing-a-folder-share
Windows Service running under a user account (aka technical account or Service ID)
A service running under a user account cannot access the GUI. There are some tricks, and some years ago I wrote a tool which allows a service to start another GUI program, where the GUI is displayed above the Ctrl-Alt-Del dialog. But this does not work under Windows 7 anymore.
But even a service which runs under local system cannot display a GUI on the logon screen.
You would have to write a Credential Provider.
See
Windows service showing a GUI when no user is logged in
https://stackoverflow.com/a/3074040/4547223
Another very deep technically article. It says it is possible to display a GUI on the secure desktop / logon screen. I have not yet tested this myself:
http://calebdelnay.com/blog/2012/01/displaying-a-program-on-the-windows-secure-desktop
Autologon
The most well known way is still the "classic" autologin.
See https://security.stackexchange.com/questions/10170/how-secure-is-windows-auto-logon for some explanations and links.
The medium secure way is to store the password as LSA secret (can be done in C# with P/Invoke or with some tools).
If I need to signin, user policies kick in, screen savers enable, etc.
Yes, but this can be handled, you probably have to create an own AD OU with an own policy for that.
I'm assuming if I use an automatic Service ID, I can let the application override most of the settings keeping the screen on and needed privileges assigned / locked down to the service ID.
A service ID /technical account is basically the same as a normal personal user account.
In some Active Directory enterprise environments a technical account has restrictions that it cannot log on interactively and other restrictions. But it still IS a "user account"
Logonexpert (http://www.logonexpert.com/)
I tested this (trial version). It is a nice, small tool which does it’s job. It is more safe than "normal autologon", however in the end, it is not much different from normal classic autologon. One benefit: it stores the password more recurely, but in theory, some hacker may still decompile the program and find out a way to decrypt it. And more important for you: Beside the more safe password store, it does not gain you much. You still have a user login same as normal autologon.
A few suggestions
Probably you can use a local user account on the client system and use normal autologon mechanism. And then you should consider that the client system does not poll for new data on a network share, but instead another server program (implemented as a service, running under a technical domain account) pushes data on a network share on the client.
Doing it this way, the client code does not need to access network shares, with the benefit, that a malicious attacker also has no access to network shares.
If you really need to access a network share from the local user context, you can probably logon to the server, as explained in my answer here:
https://stackoverflow.com/a/28749093/4547223
You have to to change the registry code part with the access to the CIFS share.
But doing it this way, you again have a password, which you have to encrypt and store. I do not recommend this.
In the end...
Windows does not make it easy what you want to do. If you are not strictly bound to Windows, you can consider using a Raspberry Pi with Raspbian (a Debian derived Linux). You can install Chromium browser, which displays a web page on the server and updates automatically. We use this with great success for some time.
My problem: Can I run an exe (a Windows Forms application) from a Windows service? If so, how?
You should be able to use System.Diagnostics.Process.Start http://msdn.microsoft.com/en-us/library/system.diagnostics.process.start.aspx to start an executable process.
But please keep in mind that services are expected (and most often does) run in their own context. For example the service would start running as soon as windows startes and even before any user is logged on. If your service decides to start the exe when no one is logged in, you will not see the UI of the form
First for all you should say what versions of windows, for vista and later here there article, for xp you should check "allow desktop interaction" in service property, but anyway it's considered as bad and insecure practice, so by any chance you should try to avoid that.
I am working on a console application that I want to run in the background of machines from the moment they boot to shutdown. Now I know that it would be optimum to create a Windows Service, but in this case I need to be able to intetact with certificate stores and I do not believe that a local service account certificate store will do.
I am looking at System.Timers for keeping the application running rather than bludgening in to death with an infinite while statement, is this a logical way to handle this or is there a better way in which to keep the application open? The application will be checking into a SQL database frequently to see if there is any work to do.
You can run Windows Services under any user with appropriate privileges. You are not required to run it under Local Service account.
Alternatively, you could use a tray icon to keep you application running, see here for a sample.
Although, you can run the application as a windows service it requires additional installation overhead. Also = as far as I understand the OP - the application should close when the user logs out, this does not hold true for windows services. So you will have close it explicitly when this behaviour is required.
You could create a windows service and impersonate the user to access the necessary certificate stores. See this question: SO Question
Now I know that it would be optimum to create a Windows Service, but in this case I need to be able to intetact with certificate stores and I do not believe that a local service account certificate store will do.
In Windows XP:
Start->Settings->Control Panel->Administrative Tools->Services
Right click on your service->Properties->Log On tab->This Account->Specify account to run as
It's something similar for Windows Vista and Windows 7 but I'm on an XP machine right now.
I am looking at System.Timers for keeping the application running rather than bludgening in to death with an infinite while statement, is this a logical way to handle this or is there a better way in which to keep the application open?
A System.Timers is fine for periodically doing something. Again, you can implement this in a Windows service though.
At my company we have a product which pretty much interacts with everything you can imagine... registry, databases, devices, etc... it is composed of many parts but the entire application is launched by a single executable (start.exe) which is responsbile for launching everything else - this is all legacy code and run under a USER account.
Currently this is launched as a STARTUP item (or by double-clicking on the desktop icon) in Windows, meaning when the user logins into the USER account the application (start.exe) automatically kicks off, under this account it has all the permissions it needs to run and everything has been fine for years...
Now comes the change - I have written a service (Serv.exe) that is running as LocalSystem - this service is responsible for updating the various software components of our product and works as follows:
- when the product detects an update it signals the LocalSystem service (Serv.exe) and then terminates itself
- Serv.exe will then perform all the updating
Now, after everything is done, the product (via start.exe) needs to be launched again automatically ... and this is where I need some advice ... what is the best way to restart the product (start.exe)?
Right now I use the LocalSystem Service (Serv.exe) and impersonate the USER account as follows:
- CreateEnvironmentBlock for the USER
- CreateProcessAsUser(start.exe) as the USER with the corresponding EnvBlock
- DestroyEnvironmentBlock
But is this really 100% equivalent to double-clicking on the icon in the USER account context? I need to ensure that everything is identical when it is either launched on STARTUP of USER or by Impersonation from Serv.exe (LocalSystem) - is there a risk involved? Will I still have the same rights/abilities with all databases? registry? device interaction? etc..
By loading the EnvBlock I seem to get everything I need but ... is this not a good way to do it...?
Kind of hoping for some guidance and advice from the pro's out there ...
Any help or hints would be much appreciated.
Thanks,
Update: Here is a post named: Launching an interactive process from Windows Service in Windows Vista and later. Which is exactly what you are looking for. It starts with:
The first thing you should do about it is that; don't do it. There are many limitations and bad implications and restrictions involved.
So first test if your current solution works. That depend on what the process is doing. If it is not involving user interaction. Or manipulating the current user session. Then you don't need this complex solution. If you need it, than good luck!
Before update: Its not 100% equivalent. Except authorization there are, in windows, sessions and, in each session, there are desktops. The process that is lunched from the service will run on the service session and desktop ( if the service has it). Depending on what the start.exe does, it may be important or not.
Look at the SetTokenInformation function.
Instead of launching the application directly as a "startup item" you could start a "launcher.exe" that then would launch your application. The service could then signal "launcher.exe" that another instance of the application should start after an update. Using this method you can't use the service to update "launcher.exe", but this executable should be very simple and hopefully not require any updates. Using this method would avoid all the pitfalls of trying to start an interactive application from a service.
We have to run a process from a windows service and get a screenshot from it.
We tried the BitBlt and PrintWindow Win32 calls, but both give blank (black) bitmaps.
If we run our code from a normal user process, it works just fine.
Is this something that is even possible? Or could there be another method to try?
Things we tried:
Windows service running as Local System, runs process as Local System -> screenshot fails
Windows service running as Administrator, runs process as Administrator -> screenshot fails.
Windows application running as user XYZ, runs a process as XYZ -> screenshot works with both BitBlt or PrintWindow.
Tried checking "Allow service to interact with desktop" from Local System
We also noticed that PrintWindow works better for our case, it works if the window is behind another window.
For other requirements, both the parent and child processes must be under the same user. We can't really use impersonation from one process to another.
Currently i can't find the corresponding links, but the problem is, that a windows service runs in another session than a normal user application.
In XP this was not fully true. Here are all services started in Session 0 and the first user who logs into the system will also run in Session 0. So in that case, tricks like Allow service to interact with desktop work. But if you fast switch to another user he gets the Session 1 and has no chance to interact with the service directly. This is also true if you connect through RDP to a server version (like 2003 or 2008). These logins will also start in a session higher than 0.
Last but not least there is another drawback by using the interaction with the desktop:
If you enable this option and your service is running under the (default) SYSTEM account it won't be able to create a network connection anymore.
The correct way to get a custom GUI that works with a service is to separate them into two processes and do some kind of IPC (inter process communication). So the service will startup when the machine comes up and a GUI application will be started in the user session. In that case the GUI can create a screenshot, send it to the service and the service can do with it, whatever you like.
Have you tried to run as Local System with the "Allow service to interact with desktop" checked?
I don't think this is possible.
We had to change our scenario where our application wasn't started from a service, but was a standard windows program that has a NotifyIcon in the corner.
If someone still finds a real answer, let me know.
It works using Local System with the "Allow service to interact with desktop"
You can set it programatically using this sample code:
http://www.vbforums.com/showthread.php?t=367177 (it's vb.net but very simple)