我正在尝试设置WCF委派，但没有成功（该方案是客户端＆gt;前端服务器＆gt;后端服务器）。
理论上，这应该是直接使用Kerberos（我确实有一个Windows域），但实际上我遇到了像SSPI甚至基本消息安全这样的奇怪错误。
我找到了无数浅薄的资源，以及人们遇到问题的论坛帖子，基本上只是通过反复试验来猜测解决方案。我在一些所谓的“专业”和“专家”WCF书籍中查看了目录，但是代表团似乎没有人愿意报道（事实上，其中一个例外中有一个错误.net抛出这让我觉得甚至连微软都不喜欢它。）
无论如何，是否存在任何资源，其中有人真正有线索并有信心解释整个过程AZ，使用方法论方法与实际解释，而不仅仅是无效的代码块不起作用，从未解释过？< / p>
答案 0 :(得分：1)
这是一个Kerberos问题，而不是WCF问题。
基本思想是客户端在安全上下文中向前端服务器发出请求，然后将此安全上下文发送到后端服务器。
这不能只在代码中修复。必须信任转发kerberos令牌的计算机才能这样做。还必须信任运行代码的帐户以转发安全令牌。
对于一般Kerberos：http://support.microsoft.com/kb/907272
这是Kerberos for SharePoint，但有很多共同之处：http://blogs.msdn.com/b/martinkearn/archive/2007/04/23/configuring-kerberos-for-sharepoint-2007-part-1-base-configuration-for-sharepoint.aspx
答案 1 :(得分：1)
这方面的WCF代码实际上非常简单。配置服务帐户并且Kerberos的行为非常困难。
你很难找到例子的原因是因为实际上很少有人这样做。执行委派的过程必须在Active Directory中（在域控制器上）“受委托”的帐户下运行。这种能力非常强大，许多IT部门都有明确的政策来对抗它。
“约束委派”的概念定义了可以访问哪些资源，但这又是在Active Directory中定义的，而不是您的代码。在继续编码之前，我建议您确保能够对Active Directory进行必要的更改。启用一个授权帐户是我在一家公司失去的一场战斗。
我建议参考：
是的，这些参考文献都有点陈旧，但它们都适用。 “如何”中列出的所有约束委派步骤都适用于Active Directory，而不依赖于ASP。