为什么服务器需要访问Kerberos? [英] Why does the Server need access to Kerberos?

查看:438
本文介绍了为什么服务器需要访问Kerberos?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试找出如何向远程服务器验证Active Directory用户的身份.

I am trying to find out how to authenticate Active Directory users to a remote server.

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

The goal is to use SPNEGO to receive a Kerberos ticket. The Kerberos ticket can then be decrypted and the identity of the user can be estabilished.

我不理解的是为什么需要在服务器和Kerberos之间进行访问.由于服务票证包含客户端身份并且由TGS私钥加密,因此服务器不需要访问Kerberos TGS.它可以解密票证并知道用户身份. 有人可以向我解释为什么有必要吗?

What I do not understand, is why access between server and Kerberos is required. Since the Service Ticket contains the client identity and is encrypted by the TGS private key, the Server does not need access to the Kerberos TGS. It can just decrypt the Ticket and know the user identity. Can anybody explain to me why it is necessary?

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

如果我想要的只是客户端身份,对我来说似乎不需要任何身份提供程序或WIF之类的方案.

Any schemes like Identity Providers or WIF does not seem necessary to me if all I want is a client identity.

推荐答案

事实证明,这个问题有很多答案……我什至不打算在这里介绍所有这些答案(部分原因是出于简短原因,部分原因是细节变得朦胧,我不记得所有的细节了. 我将介绍我想到的两个大问题,但是同样,还有更多.

It turns out there are a bunch of answers to this question...I won't even attempt to cover all of them here (partly for brevity reasons, partly because the details have become hazy and I don't remember them all :)). I'll cover the big two that come to mind, but again, there are more.

首先,您要说的是到DC的往返行程,因为DC是KDC,就好像全部与遏制有关.我想这是一种查看方式,但是整个Windows身份验证堆栈所做的远远不只是验证Curb票证.例如,需要进行SID解析之类的事情,才能使做出身份验证决定时所用到的票证不成问题.因此,出于多种原因并使用多种协议,通讯会发回DC(包括KDC等),其中一些协议支持authz堆栈,这对于大多数人来说通常是很有趣的.

First, you are speaking of round trips to the DC as if it is all about Kerb as the DC is the KDC. I guess that's one way to look at it, but the overall Windows auth stack does far more than just validate Kerb tickets. For example, things like SID resolution are required in order to make heads or tails out of tickets that come in when making authz decisions. So communication happens back to the DC (which is a KDC and more) for many reasons and using many protocols, some of which are supporting the authz stack which is what is typically interesting for most folks.

第二,特别是对于Curb ...协议的某些功能使返回KDC具有安全价值. PAC验证是第一个想到的.我建议您仔细阅读...以下是涵盖该内容的不计其数的帖子之一:

Second, for Kerb specifically...there are some features of the protocol where going back to the KDC has security value. PAC validation is the first that comes to mind. I'd suggest reading up on this...here's one of a zillion posts that cover it: http://blogs.msdn.com/b/openspecification/archive/2009/04/24/understanding-microsoft-kerberos-pac-validation.aspx I would note that in this case, there are things you can do to actually disable this downstream->KDC flow (like giving the principal TCB). These things are not to be done lightly though...ie, it's more than just a "perf fix" to consider. :)

这篇关于为什么服务器需要访问Kerberos?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆