Setting SPN on endpointaddress for NetNamedPipe service endpoint

Question

I'm getting the "There was no endpoint listening at net.pipe://localhost" error as described in other places but I cannot seem to find a real answer.

This is a great identifier of the problem: http://kennyw.com/indigo/102

When using WCF, Windows authentication is performed through SSPI-Negotiate, which in most cases will select Kerberos as the actual authentication mechanism. However, if the target SPN passed to SSPI is a well formed SPN for the local computer account (e.g. host/[dns machine name]) then Negotiate will use NTLM (loopback optimization) and the access token will not have the Network SID (and therefore will be usable with NetNamedPipes).

But it doesn't tell me how to resolve the issue. I am creating my endpoint programmatically.

var binding = new NetNamedPipeBinding();
binding.Security.Mode = NetNamedPipeSecurityMode.Transport;
binding.Security.Transport.ProtectionLevel = ProtectionLevel.EncryptAndSign;

var id = EndpointIdentity.CreateSpnIdentity("host/" + Environment.MachineName);
var endpointAddress = new EndpointAddress(new Uri(serviceClientUrl), id);

var client = new ServiceClient(binding, endpointAddress);

I'm guessing that my issue is in the CreateSpnIdentity but I'm not sure what value to use.

Additional Info: To elaborate on this for more context. The Wcf service is hosted as a Windows Service running under the NetworkService account (I've tried Local System). The service is created using the default NetNamedPipeBinding constructor:

host.AddServiceEndpoint(typeof(IService), new NetNamedPipeBinding(), "ServiceName");

I've created a SharePoint webpart that uses this service. The kicker is that if the SharePoint site is set to forms based authentication or just the machine name is used in the url under Windows Authentication then there are no issues. ONLY if the fully qualified machine name is used for the url under Windows authentication do I get the above error.

I'm pretty sure this has to do with the NTLM Kerberos issues descibed in the article but I'm not sure how to get around it.

Aviv

Answer 1

Setting the endpoint identity on the client side will not help you, as the issue is the security context in which your client code is executing, not the configuration of the endpoint. As KennyW explains, if you access the SharePoint application using the full domain name of the machine, the impersonation token in the web server process (which provides your SharePoint user identity under Windows authentication) will be obtained via Kerberos and have membership of the NETWORK USERS group. If you use just the machine name, the optimization Kenny refers to gets you a logon token via NTLM which is not in the NETWORK USERS group and is therefore not denied access by the ACLs which WCF puts both on the pipe and on the shared memory object where the server publishes the actual pipe name.

The error There was no endpoint listening at net.pipe://localhost... does not necessarily mean that there is no WCF service listening on such a named pipe endpoint: it can also (and in this case does) mean that although there is one, you don't have sufficient access rights to know about it, because you have a remote logon.

Alcheringa

Yeah, I pretty much came to the realization that Net Tcp was really my only solution (which is fine because we will ultimately move this service to a different machine). Thanks for the insight and link. – Aviv

Answer 2

NamedPipe has been made a pain in the backside after Hardening: http://msdn.microsoft.com/en-us/library/bb757001.aspx It actually made me change from NamedPipe to TCP while I needed to communicate on the same machine.

Now this does not mean this is your problem. If you are running under one account and trying to connect under a different account, this will usually fail since named pipes are no longer created as global (unless it is LocalSys).

My suggestion is:

1) Eliminate all security from your service. After all, NamedPipe runs on the same machine and I believe normally no security should be needed. 2) Try connecting. if it fails, use SysInternals ProcExplorer to see what objects process has started. If it has a named pipe then it is the hardening.

If you give more info I should be able to help you more.

Pneumodynamics

The service is hosted in a Windows Service running under NT AUTHORITY\NetworkService. The client is a SharePoint WebPart with SharePoint running a Network service account. If I access the machine locally and only use the machine name as the url it works fine. If I append the fully qualified domain name to the url then it doesn't work. I know this has to do with the fact that the site is set to windows security because this code works without issue for other SharePoint sites that are set to FBA. – Aviv

I ended up getting a fall back using Net Tcp working but I would really like to solve this riddle. – Aviv

There is a fair amount of misinformation in this answer: (1) Hardening of OS named pipes is good & necessary to remove security vulnerabilities; (2) WCF still creates named pipes in the global namespace: it is the shared memory which publishes the pipe name to clients which will go into Local (i.e. scoped by logon session) rather than Global namespace if server is not sufficiently privileged (on Vista and W7). The issue here is nothing to do with either of these - it is due to WCF denying access to named pipe endpoints to remote logons. – Alcheringa