为什么服务器需要访问 Kerberos？答案

【问题标题】：Why does the Server need access to Kerberos?为什么服务器需要访问 Kerberos？
【发布时间】：2012-09-25 11:10:14
【问题描述】：

我正在尝试了解如何向远程服务器验证 Active Directory 用户。

目标是使用 SPNEGO 接收 Kerberos 票证。然后可以解密 Kerberos 票证并确定用户的身份。

我不明白，为什么需要服务器和 Kerberos 之间的访问。由于服务票证包含客户端身份并由 TGS 私钥加密，因此服务器不需要访问 Kerberos TGS。它可以只解密票证并知道用户身份。谁能向我解释为什么有必要？

http://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/16/1054.aspx

如果我想要的只是客户身份，我似乎不需要像身份提供者或 WIF 这样的方案。

【问题讨论】：

您是否在 Wireshark 会话中验证了您的假设？
@Michael-O：这是为潜在客户设计的架构；由于系统还不存在，我无法使用wireshark。
虽然如此 :-d 您是否查看了 Wikipedia 和其他资料以了解 Kerberos 的工作原理？通常，服务票证由 KDC 使用服务的密钥进行加密。该服务不需要联系 KDC 来解密传入的票证。 RFC 记录了这个过程：tools.ietf.org/html/rfc4120#section-3.2
想一想：在很多身份联合系统中，客户端 ID 实际上是一个随机的随机数，只有 IdentityProvider 知道。这样，用户可以选择不将他的身份提供给服务器，同时仍然证明他是特定组织的成员。 Active Directory 中是否会发生类似的情况？
其实有一个nonce，但是客户端请求包含了principal name。 Kerberos 是关于主体的。考虑到 Kerberos 是企业 ID 管理的事实标准。

标签： active-directory kerberos spnego

【解决方案1】：

事实证明这个问题有很多答案...我什至不会尝试在这里涵盖所有答案（部分原因是简洁，部分原因是细节变得模糊，我不记得它们了全部：））。我将介绍我想到的两大类，但同样，还有更多。

首先，您说的是到 DC 的往返行程，就好像这完全是关于 Curb 的，因为 DC 就是 KDC。我想这是看待它的一种方式，但整个 Windows 身份验证堆栈不仅仅是验证 Curb 票证。例如，需要 SID 解析之类的东西，以便在做出 authz 决策时对进来的票进行正面或反面。因此，出于多种原因并使用多种协议，通信会返回到 DC（这是一个 KDC 等等），其中一些协议支持 authz 堆栈，这通常是大多数人感兴趣的。

其次，特别是对于 Curb……协议的某些特性中，返回 KDC 具有安全价值。 PAC 验证是首先想到的。我建议阅读此内容...这是涵盖它的无数帖子之一：http://blogs.msdn.com/b/openspecification/archive/2009/04/24/understanding-microsoft-kerberos-pac-validation.aspx 我会注意到，在这种情况下，您可以做一些事情来实际禁用此下游-> KDC 流（例如提供主体 TCB）。但是，这些事情不能轻易完成......即，它不仅仅是要考虑的“性能修复”。 :)

【讨论】：

感谢您的回复。在您的回复中，我很难将身份验证和授权分开。联系远程 AD 的所有原因都是为了验证与票证关联的权限（或验证模拟）。在我的用例中，我只想验证身份，仅此而已。
是的，这个堆栈真的是为同时做 IMO 的人设计的。像 PAC 验证之类的东西可能对你没有用，但堆栈却在幕后完成了它们。
也许我可以调整一个开源实现来删除所有授权并希望它有效。无论如何，这个信息是响亮而清晰的：不适合有头脑的人，要小心安全问题。
如果您想更深入地聊天，请随时通过电子邮件联系我（我的个人资料有我的网站，而我的网站也有我的电子邮件地址），我很乐意多聊。如果你愿意写一堆原生代码，你可以让它在任何地方工作。但这需要控制客户的行为。
我应该补充一点，其中一些行为，如 PAC 验证，确实有配置旋钮。因此，也许您可以配置足够多的 API 并使用恰到好处的 API 以使其正常工作……但这需要一些真正的调查……