I'm working on an issue at the moment where a WCF application creates a named pipe, which is then to be accessed by an asp.net application running in IIS. I didn't write the WCF application, I'm just trying to support it.
The application runs in Local System context, while the IIS Application runs in the context of a local windows account which is a member of the local Administrators group. When the asp.net application attempts to access the named pipe, it will hit an Access Denied exception (AddressAccessDeniedException), and I've no idea where :-( Here's what I've done so far to debug the issue:
- Confirmed in Process Explorer that the named pipe does exist and is getting created when the WCF application starts.
- I done this by searching for BaseNamedObjects in Process Explorer, and eventually identified \BaseNamedObjects\net.pipe:Exxxxx== ... which I was able to confirm is the named pipe I'm interested in
- As the pipe exists, I concentrated on IIS and figured it must be a permissions issue. So, I changed the asp.net application to run as local system instead ... the problem went away
- Switched back to using the local windows account, the problem came back again
- Compared the working (Local System) vs non-working (local user account) tokens in PE ... non-working was missing SeAssignPrimarytokenPrivilege
- I thought we'd found the cause of the problem here, but even after modifying the local policy (and confirming the right was in the token after restarting) the problem still persisted
- Compared all other user rights and security options against a working machine, there was nothing different between them
- Confirmed that the instance of w3wp is running Elevated and UAC is disabled (Elevated=Yes and UAC Virtualization=Not Allowed in Task Manager)
- Used AccessChk to compare the permissions on the named pipe in the non-working machine, they're identical to those on a working machine
- Checked the manifest file for the WCF application and compared it against a working one, but there's no difference there either
And so, here I am ... I know that the pipe exists, I know that it's a permission issue of some sort, yet all of the permissions check out just fine. What am I missing ? Is there some general setting on Windows that might prevent a user from accessing all named pipes ?
I know that I could change the "Access Named Pipes Anonymously" setting, but I don't want to change this as it's not configured on a working machine, so it's not really going to get me to the root cause. I've also seen a few mentions of "Access Named Pipes Remotely" on google, but I don't know if this is a typo ... aren't named pipes local by their very definition ??
Obviously I've done some research of my own on this, and found a few SO posts and other blog posts, including the ones below, but none of them have helped me find the root cause.