Home » .Net Framework

WCF named pipes non-admin account

I have build windows service that use local system account and i have got tray app that shows information to user and is running normal user account. Service and tray app communicates by using WCF and named pipes. The problem is that if tray add is running non admin account, windows service could not communicate with it. Tray app open pipe but service could't use it to message sending to the tray app.

This problem occurs only with windows 7 and probably vista. I think i could make some local policy setting rule that allows named pipe using with normal user accounts, but there is a change that domain group policy may override my settings and application stops working. And secondly pipe that tray app uses has every time different name so it would be difficult to make exception with specific pipe name. Does anybody know how i could use named pipes with normal user account with windows 7? And how i could name the pipe that i make in WCF?



5 Answers Found


Answer 1

Hi rmez,

From your description, your WCF service  uses named  pipe binding and is hosted in a windows  service which will communicate  with some client consumers through tray  app. I'm wondering how do you implement the communication between the windows service and the tray app, is the tray app  itself also a WCF service or if it is just a client which use WCF proxy class to call operations from the WCF service hosted in windows service?

If your tray application  is just a WCF client, it should not require admin privilege since you will not need to open  a service endpoint listening on any port or pipe  but access an existing port or type. Also, you can try change  the service to use other binding to see whether the problem  is also specific  to named pipe based binding.


Answer 2

Thank for answer. Windows service  and tray  app both hosts wcf  services and used named  pipes. Tray app  could use WCF service that is hosted by win service in every case.  There is no need to use admin account  with tray app when connecting to wcf service that is hosted by win service. But when win service try to use WCF service that tray app is hosted there is the problem. If tray app is started with non admin  account win service failed to connect to the tray app.

So tray app host WCF service endpoint that uses named pipes. If we use some other protocol and port which is listen connections we should open  the port using netsh. problem  is that we're not sure what port are available in client systems.


Answer 3

Hi rmez,

I suppose the tray  app hosts its WCF service  to be able to receive status notifications from the windows  service, am I right?

If this is true, could a duplex-enabled binding do the trick for you?

Unfortunately, WCF has no WSDualNamedPipeBinding out of the box but since the name pipe  channel is two-way, it should be possible to configure a duplex binding with named  pipe transport as a custom binding.

@Steven Cheng: What du you think? Do have an example for a duplex-enabled custom binding that uses a named pipe transport?





Answer 4

I am also experiencing the same problem  (System.ServiceModel.EndpointNotFoundException). The code works perfectly if I run it as a console app  but does not work inside a windows  service. It seems that "Named Pipe Hardening" has made it really hard and secure since you cannot use it anymore!

Any ideas how to get round it?




Answer 5

From Christian Weyer's blog (http://weblogs.thinktecture.com/cweyer/2007/12/dealing-with-os-privilege-issues-in-wcf-named-pipes-scenarios.html):

"If my wcf  server process using a named  Pipe-based endpoint doesn't have privileges to create a Global kernel object it silently fails and creates a local  one which will not be visible to processes outside of its session."

So no named pipe  based communication mechanism (WCF or otherwise) opened by a process without the privilege to create a global kernel object will ever be able to receive messages from outside its own session.

Sucks.  This is an example of the law of unintended consequences, where clamping down on security actually results in people opening more security loopholes by being forced to use network visible transports instead of a local machine IPC mechanism.  MS should really provide a proper IPC channel for WCF because the current named pipe transport doesn't cut it.




<< Previous      Next >>

Microsoft   |   Windows   |   Visual Studio   |   Sharepoint   |   Azure