Why does named pipe WCF service reject Windows service clients?

Question

On Windows 7 and .NET 4 I'm getting some very weird effects from the WCF named pipe transport when my WCF client is a Windows service.

My WCF service is hosted in a user mode app and exposed over the named pipe binding.

My WCF client is a Windows service, running as Network Service (I get the same result if it runs as Local System).

If my user mode app (ie WCF service) is running as a domain admin then it works fine, but if the user mode app is an ordinary user (or local admin) then the connection is rejected with a CommunicationObjectFaultedException.

I saw some questions on here relating to UAC being involved, but I haven't seen an actual solution anywhere which just makes the named pipe transport work properly. Is this just an inescapable framework bug?

Lindeman

What's the inner exception? And, no, it isn't a bug in the framework. – Bria

Answer 1

From Christian Weyer's blog entry Dealing with OS privilege 'issues' in WCF Named Pipes scenarios:

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.

Seems to be that 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.

Problem is that this isn't a particularly unusual scenario, for a .NET service to want to talk to a .NET tray app to provide user notifications. A polling mechanism from the tray app to the servide will work... but polling is slow and resource intensive and I'd like to have avoided it.

Anyone know of a better custom IPC transport?

Tim

Lindeman