匿名、身份验证、模拟和委托之间有什么区别,为什么委托需要 Kerberos?

发布于 2024-07-22 18:03:43 字数 271 浏览 7 评论 0原文

当我们的客户安装我们的软件时,他们通常选择“拆分安装”,其中服务在一个机器上运行,数据库在另一个机器上。 这些服务可能与其他服务通信,或者数据库可能包含需要与另一个数据库通信的存储过程。

这将我们带入了 Kerberos 和 SetSPN 的黑暗世界。

我正打算向支持人员发送一封电子邮件,详细说明 Windows 支持的各种身份验证级别之间的差异,但我意识到我对模拟和委托之间的差异的了解有点模糊,而且当它出现时我真的很粗略到 Kerberos。

谁能启发我吗?

When our customers install our software, they often opt for a "split install", where the services run on one box and the database is on another box. The services might talk to other services, or the database might contain stored procedures that need to talk to another database.

This leads us into the murky world of Kerberos and SetSPN.

I was about to send the support guys an email breaking down the difference between the various authentication levels supported by Windows, but I realised that my knowledge gets a bit vague about the difference between impersonate and delegate, and I'm really sketchy when it comes to Kerberos.

Can anyone enlighten me?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

恬淡成诗 2024-07-29 18:03:43

身份验证(authn)意味着识别用户。 授权(authz)意味着确定经过身份验证的用户拥有哪些权限。 匿名用户尚未经过身份验证,但可能拥有系统的某些权限(“访客”)。 模拟和委托是同一枚硬币的两个方面。 如果我使用您的身份进行某项操作,即构成冒充您; 您授予我冒充您并采取某些行动的权利。

Kerberos(或“Kerb”)是一种基于令牌的身份验证方案。 也就是说,它是一种让用户登录并在系统中被正确识别(authn)和赋予权限(authz)的方法。

根据评论:您不需要 Curb 进行委派,但它内置于 Server 2003 中。您还可以使用 NTLM、SSL 证书映射或摘要式身份验证。 但这些都不像 Kerb 那样强大和灵活。 您还可以选择进行约束委派,仅允许委派某些服务。 原因是您需要一个可信的第三方来验证您的令牌。 基本上,流程是这样的......

  1. 我对我的域进行身份验证。
  2. 该域向我颁发了证书。 该证书对我做出了声明。
  3. 我获取该证书并将其交给服务 我希望允许我做某事
  4. 该服务获取该证书并通过受信任的证书颁发机构 Valida 进行
  5. 该服务根据与证书颁发机构的通信来授予或拒绝访问权限

这是一个很深的主题,因为您知道。 :) 这是一篇关于上述某些选项的好文章。 另外,请查看此 网络广播——它是关于 ADFS 的,但它在可能有帮助的概念上做得很好。

Authenticate (authn) means to identify a user. Authorize (authz) means to determine what rights an authenticated user has. An Anonymous user has not been authenticated but may have some rights on the system (a "guest"). Impersonate and delegate are two sides of the same coin. I impersonate you if I use your identity to do an action; you delegate me the right to impersonate you and take some action.

Kerberos (or "Kerb") is a token-based authentication scheme. That is, it's a way to let users log in and be properly identified (authn) and given rights (authz) in system.

Per comments: You don't need Kerb for delegation, but it's built in to Server 2003. You can also use NTLM, SSL Certificate Mapping or Digest Authentication. But none of those is as robust and flexible as Kerb. You also have the option to do constrained delegation which allows a delegation only to a certain services. The reason is that you need a trusted 3rd party to validate your token. Basically, the flow goes like this ...

  1. I authenticate to my domain.
  2. That domain issues a certificate to me. That cert makes claims about me.
  3. I take that cert and give it to the service I want to allow me to do something
  4. The service takes that cert and Valida's it with a trusted certificate authority
  5. The service gives or denies access based on communication with the certificate authority

It's a deep subject as you know. :) Here is a good article on some of the above options. Also, check out this web cast -- it's about ADFS, but it does a good job on the concepts that might help.

断肠人 2024-07-29 18:03:43

您可能想在 Ken Schaefer 的 网站上温习一下 Kerberos。 他的 Kerberos 常见问题解答非常棒。

添加到上面的答案,委托是让一台服务器使用客户端的原始身份验证向另一台服务器进行身份验证。 使用 Kereberos,这相对容易完成 - 您只需允许第一个服务器“重新颁发”客户端的身份验证令牌即可。 替代方案(NTLM)不允许轻松/安全地进行委派,因为它是质询/响应身份验证 - 服务器向辅助服务器进行身份验证的唯一方法是它是否可以响应质询/响应,并做到这一点需要客户的密码。

我有一个 ServerFault 关于 Kerberos 委派的回答可能很有趣。

You might want to brush up on Kerberos on Ken Schaefer's web site. His Kerberos FAQ rocks.

Adding to the above answer, delegation is having one server authenticate to another server using the client's original authentication. With Kereberos, this is relatively easy to accomplish - you just allow the first server to "re-issue" the client's authentication token. The alternative (NTLM) doesn't allow for delegation easily/securely since its a challenge/response authentication - the only way for the server to authenticate to the secondary server is if it can respond to the challenge/response, and to do that it would need the client's password.

I've got a ServerFault answer regarding Kerberos Delegation that might be interesting.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文