I am looking forward for an example for using a user defined control code in services. I want to send a user defined command to my windows service. At this command windows service will create a named-pipe for client process, and client will establish a connection with this named-pipe by CreateFile function. My custom control sometimes works well but later it shows error for invalidation.
So how can I establish information exchange between a service and various clients?
SERVICE_USER_DEFINED_CONTROL is rarely used. When it is used, it is generally to prompt the service to re-read its configuration file. (On unix SIGHUP is generally used for the same purpose).
In your case the correct answer is to simply create the named pipe on startup and keep listening, and wait for someone to connect if they ever do.
Related
When a named pipe client connects to a server and writes some data, the server can call ImpersonateNamedPipeClient() to impersonate the client. (The server does need to read the data before calling ImpersonateNamedPipeClient()).
As we can see at this link, this can lead to a privilege escalation security vulnerability.
Is possible to prevent/disable/deny this impersonation, so that a client can connect to the named pipe but not allow the server to impersonate?
Note 1: I know that the client needs to write on the named pipe first. But in some cases, the client will need to write first, so I need to prevent this security flaw.
Note 2: A solution that applies to Windows XP and above is appreciated.
When calling CreateFile() to open the client end of the named pipe, pass SECURITY_IDENTIFICATION in the dwFlagsAndAttributes parameter. This allows the server to identify the user and to determine the client's privileges, but prevents the server from impersonating the client's security context.
You can use SECURITY_ANONYMOUS instead if you also want to prevent the server from identifying the user.
Note that the server can still successfully call ImpersonateNamedPipeClient() but any attempt to make use of the impersonation token will be restricted by the specified impersonation level. For example, if the server attempts to open a file while impersonating the client at identification or anonymous level, the operation will fail.
For more information, see the Impersonation Levels page on MSDN.
It should also be noted that as of Windows XP service pack 2, the server cannot impersonate the client unless it holds the SeImpersonatePrivilege privilege. (See ImpersonateNamedPipeClient on MSDN.) In the default configuration, only system services and administrators have this privilege. This effectively mitigates many (though not all) of the risks described in the article you link to.
I have a solution that acts as client service and does some background work. This application requires some settings (that are read from an xml file) to be done at installation time and which are periodically revised. For convenience (as this service is installed on multiple machines) I wanted to control these settings remotely from a central server application. This works fine if the server and client are inside the LAN but I would like to control these settings even if the client is outside the network or the server is behind a firewall. What could be the solutions to do this?
Clearly, the solution depends on exactly what you want to achieve. But if I understand it right, the reason you have "problems" with a firewall is that you simply access the file that contains the XML over the network using standard network file access. Which is typically (for good reason) blocked by the firewall.
So, the solution then would be to use a standard protocol and a "non-standard service". For example, if the machine is allowed incomming HTTP requests, you could use HTTP-based post messages to update the XML content, either send the entire file as a file upload, or make up your own remote access protocol. If HTTP is not allowed, then you have to look at what other "holes" there are in the firewall, and do something similar with another of the "holes".
The other, less obscure solution, is of course to simply use a remote-desktop or secure shell connection to remotely access the machine. Of course, again, assuming this sort of connection is allowed.
There is no magical "bypass firewall" solution - you have to work within the rules of the firewall in some way.
I have written a windows service and I want to communicate(IPC) it with a win32 application(Desktop), can anyone tell me what should I exactly do for making this communication. In my case my Service is server and other process is client. Process should establish connection with the service whenever a user launches it on his machine.
I have written services which support named pipes like you describe. I do not have to do anything special to set permissions for the client to open & read/write the named pipe. I found the following Microsoft articles useful when developing my code:
"The Complete Service Sample":
http://msdn2.microsoft.com/en-us/library/bb540476(VS.85).aspx
"Named Pipe Server Using Completion Routines" :
http://msdn.microsoft.com/en-us/library/aa365601(VS.85).aspx
Following is a list of options for inter-process communication on Windows:
1. Component Object Model (COM)
2. Remote Procedure Call (RPC)
3. Windows Sockets
You can set service type as Automatic, mean it will start once the machine up& running
Please refer.
https://www.codeguru.com/cpp/w-p/system/sharedmemory/article.php/c2879/Shared-Memory-Inter-Process-Communication-IPC.htm
I was wondering, what is the best way to do the following using C++/WinAPIs on a Windows system?
I have a local service application along with running client applications (that run on each logged on user session account.) The service application needs to notify all client applications to perform a one time operation (say, read data from registry and process it.) How do you implement this mechanism of notifying all client apps of a one-time event?
Service could send a broadcast windows message for which all client apps would listen. Of course, client apps need to have a message loop. Have you looked at SendNotifyMessage function?
You could use an event with a particular name that all the apps agree on. Then reset it after a period of time.
There are different ways of shutting down a computer remotely.
Here are three I know of:
Invoking the Shutdown method of the Win32_OperatingSystem class through a remote WMI connection
Using the Microsoft Windows shutdown.exe
Letting your (whatever).exe copy itself to the systemfolder on the target machine, register itself as a service and start it remotely with parameters so that it initiates a local shutdown.
Number 3 is why sysinternals does, e.g. However, it requires that you have file & printer sharing active so that it is able to copy itself to the target and invoke the service.
Number 2 works almost everywhere... but also needs to have file & printer sharing being enabled. Because: This activates the RPC service which is needed for remotely invoking the shutdown.
As far as I can tell, even Number 1, the WMI solution, not only needs WMI installed on the target, but also the RPC service enabled.
My problem is:
I need a solution that allows me to shutdown a remote computer without RPC being enabled on it.
Is there a way?
Note: A way within a context of a business solution ;-)
I believe that you can use IPMI for such tasks. It requires hardware support though. We used it for lights-out management over a serial port in a solution a few years ago. We had some issues with the hardware support for soft shutdown since it requires some integration with the OS. From what I remember, you can mimic the hardware reaction to pressing the power button using a network packet sent by an IPMI utility. HTH.