在 NetNamedPipe 服务端点的端点地址上设置 SPN
我收到“net.pipe://localhost 没有端点监听”错误，如其他地方所述，但我似乎找不到真正的答案。
这是问题的一个很好的标识： http://kennyw.com/indigo/102
使用 WCF、Windows 身份验证时 通过 SSPI-Negotiate 执行， 大多数情况下会选择 Kerberos 作为实际身份验证 机制。但是，如果目标 SPN 传递给 SSPI 的是格式良好的 SPN 对于本地计算机帐户（例如 主机/[dns 机器名称]) 然后 协商将使用NTLM（环回 优化）和访问令牌 将没有网络 SID（并且 因此可以与 NetNamedPipes）。
但它没有告诉我如何解决这个问题。我正在以编程方式创建端点。
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);
我猜我的问题出在 CreateSpnIdentity 中，但我不确定要使用什么值。
其他信息： 详细说明这一点以获得更多背景。 Wcf 服务作为 Windows 服务托管在 NetworkService 帐户下运行（我尝试过本地系统）。该服务是使用默认的 NetNamedPipeBinding 构造函数创建的：
host.AddServiceEndpoint(typeof(IService), new NetNamedPipeBinding(), "ServiceName");
我创建了一个使用此服务的 SharePoint Web 部件。更重要的是，如果 SharePoint 站点设置为基于表单的身份验证，或者在 Windows 身份验证下的 URL 中仅使用计算机名称，则不会出现任何问题。 仅如果 Windows 身份验证下的 url 使用完全限定的计算机名称，我会收到上述错误。
我很确定这与本文中描述的 NTLM Kerberos 问题有关，但我不确定如何解决它。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在客户端设置端点标识对您没有帮助，因为问题在于执行客户端代码的安全上下文，而不是端点的配置。正如 KennyW 所解释的，如果您使用计算机的完整域名访问 SharePoint 应用程序，则模拟令牌Web 服务器进程（在 Windows 身份验证下提供您的 SharePoint 用户身份）中的用户名将通过 Kerberos 获得，并具有 NETWORK USERS 组的成员身份。如果您仅使用计算机名称，Kenny 提到的优化会通过 NTLM 为您获取登录令牌，该令牌不在 NETWORK USERS 组中，因此不会被 WCF 放置在管道和共享内存对象上的 ACL 拒绝访问服务器在其中发布实际的管道名称。
错误
There was no endpoint Listening at net.pipe://localhost...并不一定意味着没有 WCF 服务在这样的命名管道端点上进行侦听：它也可以（并且在此示例中）情况确实）意味着虽然有一个，但您没有足够的访问权限来了解它，因为您有远程登录。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.强化后，NamedPipe 变得令人头疼：http://msdn. microsoft.com/en-us/library/bb757001.aspx 它实际上让我从 NamedPipe 更改为 TCP，而我需要在同一台计算机上进行通信。
现在这并不意味着这是你的问题。如果您在一个帐户下运行并尝试在另一帐户下进行连接，这通常会失败，因为命名管道不再创建为全局的（除非它是 LocalSys）。
我的建议是：
1）消除服务中的所有安全性。毕竟，NamedPipe 在同一台机器上运行，我相信通常不需要安全性。
2) 尝试连接。如果失败，请使用 SysInternals ProcExplorer 查看启动了哪些对象进程。如果它有命名管道，那么它就是硬化。
如果您提供更多信息，我应该能够为您提供更多帮助。
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.