Wcf 在NetNamedPipe服务终结点的endpointaddress上设置SPN

我得到了“在网络上没有端点监听”。pipe://localhost“其他地方描述的错误，但我似乎找不到真正的答案

这是问题的一个很好的标识：

使用WCF时，Windows身份验证 通过SSPI协商执行， 在大多数情况下会选择哪一种 Kerberos作为实际身份验证 机制。但是，如果目标SPN 传递给SSPI的是格式良好的SPN 对于本地计算机帐户（例如。 主机/[dns机器名]）然后 协商将使用NTLM（环回） 优化）和访问令牌 将不具有网络SID（和 因此，将可用于 网络名称管道）

但它没有告诉我如何解决这个问题。我正在以编程方式创建端点

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服务作为运行在NetworkService帐户下的Windows服务托管（我尝试了本地系统）。该服务是使用默认的NetNamedPipeBinding构造函数创建的：

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

我已创建使用此服务的SharePoint Web部件。更重要的是，如果SharePoint网站设置为基于表单的身份验证，或者仅在Windows身份验证下的url中使用机器名，则不会出现任何问题仅如果Windows身份验证下的url使用完全限定的计算机名，则我会收到上述错误

---

我很确定这与文章中描述的NTLM Kerberos问题有关，但我不确定如何解决它。

NamedPipe在硬化后在背后很痛苦：它实际上让我从NamedPipe更改为TCP，而我需要在同一台机器上进行通信

这并不意味着这是你的问题。如果您在一个帐户下运行并尝试在另一个帐户下连接，这通常会失败，因为命名管道不再创建为全局管道（除非它是LocalSys）

我的建议是：

1） 消除您服务中的所有安全性。毕竟，NamedPipe运行在同一台机器上，我相信通常不需要安全性。 2） 尝试连接。如果失败，请使用sysexplorer查看进程启动了哪些对象。如果它有一个命名管道，那么它就是硬化管道

---

如果您提供更多信息，我将能够为您提供更多帮助。

在客户端设置终结点标识对您没有帮助，因为问题在于执行客户端代码的安全上下文，而不是终结点的配置。因为，如果您使用计算机的完整域名访问SharePoint应用程序，则web服务器进程中的模拟令牌（在Windows身份验证下提供您的SharePoint用户身份）将通过Kerberos获得，并且具有网络用户组的成员资格。如果只使用机器名，Kenny引用的优化将通过NTLM向您获取登录令牌，该令牌不在网络用户组中，因此不会被WCF放置在管道和服务器发布实际管道名的共享内存对象上的ACL拒绝访问

---

错误

在网络上没有端点侦听。pipe://localhost...

不一定意味着没有WCF服务监听这样一个命名管道端点：它也可能（在本例中是这样）意味着尽管有一个，但您没有足够的访问权限来了解它，因为您有远程登录。

该服务托管在NT AUTHORITY\NetworkService下运行的Windows服务中。客户端是SharePoint Web部件，SharePoint运行网络服务帐户。如果我在本地访问机器，并且只使用机器名作为url，它就可以正常工作。如果我将完全限定的域名附加到url，那么它将不起作用。我知道这与该网站设置为windows安全有关，因为该代码对于其他设置为FBA的SharePoint网站来说没有问题。我最终使用Net Tcp working获得了一个退路，但我真的很想解开这个谜团。这个答案中有相当多的错误信息：（1）强化操作系统命名管道对于消除安全漏洞是很好和必要的；（2） WCF仍然在全局命名空间中创建命名管道：如果服务器没有足够的权限（在Vista和W7上），则是共享内存将管道名称发布到将进入本地（即登录会话的作用域）而不是全局命名空间的客户端。这里的问题与这两者都无关——这是因为WCF拒绝远程登录到命名管道端点的访问。是的，我几乎意识到Net Tcp是我唯一的解决方案（这很好，因为我们最终会将此服务移动到另一台机器）。感谢您的洞察力和链接。