📄 203002.htm
字号:
<html><body><span id=Layer1><a name=203002><font color=#3e70d7 face=arial size=5><b>了解Kerberos</span><span id=Layer2></b></font><p><font size=2 color=#3c3c3c face=arial>以取代原来守卫地狱王的叁头犬（three-headed dog）之命名函义，Kerberos由麻省理工学院（Massachusetts Institute of Technology （MIT））在1980年代前期发展完成。现在的版本是第五版，已经被IETF刊载为RFC 1510，而Windows 2000依照这标准所描述的实作这个协定。即使发展已经有些年代，Kerberos技术并未被广泛地使用。然而藉由使得Kerberos成为Windows 2000安全性的核心协定，Microsoft肯定了Kerberos的黯淡岁月已经结束。考虑到Microsoft技术的普及程度，Kerberos似乎注定要成为许多分散式环境不可或缺的部分。</span><span id=Layer3></font></p><p><font size=2 color=#3c3c3c face=arial>Kerberos是一项成熟的技术</span><span id=Layer4></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Kerberos是一项成熟的技术</span><span id=Layer5></font></p><hr><p><font size=2 color=#3c3c3c face=arial>虽然Kerberos协定确实会传递做授权决定的资讯，授权一般以先前提过的做法执行－Kerberos不提供这项服务。然而，它提供先前提过的叁项安全性服务：验证、资料完整性、以及资料私密性。提供这叁项服务的基础机制完全依赖秘密金钥加密（secret key encryption）技术，因此在说明Kerberos之前必须先概述秘密金钥技术工作的基本原理。</span><span id=Layer6></font></p><font color=#3e72d7 face=arial size=4><b>秘密金钥加密</span><span id=Layer7></b></font><p><font size=2 color=#3c3c3c face=arial>在秘密金钥加密，使用相同的金钥加密与解密。例如，假设你想送私人讯息告诉我QwickBank公司已经被卖掉了。如图3-4所示，你使用某些金钥值加密讯息。然後你可以送给我这加密过的资讯，有时称为ciphertext，而不必担心其他人读取它（假设你选用了强固的加密演算法以及适当的金钥）。要将讯息解密的话，我必须使用你用来加密的相同金钥。</span><span id=Layer8></font></p><p><font size=2 color=#3c3c3c face=arial>秘密金钥加密要求双方使用单一金钥</span><span id=Layer9></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>秘密金钥加密要求双方使用单一金钥</span><span id=Layer10></font></p><hr><br><center><a target=_new href=imagesh/3-4.gif><img border=0 src='imagesl/3-4.gif'></a></center></span><span id=Layer11><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图3-4</span><span id=Layer12> </b></font>在秘密金钥加密，使用相同的金钥加密与解密。</span><span id=Layer13></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>秘密金钥加密有一些很棒的的特色。最重要的也许是金钥长度可以很短－常见的长度是56位元以及128位元－而且加密/解密的速度比较快。但是秘密金钥加密也有一个重大缺陷：金钥散布的问题。如果你和我想要交换加密过的讯息，我们必须都拥有相同的金钥－它是我们共享的。但假设你产生这个秘密金钥，你如何安全地把它传送给我呢？你随时可以用电子邮件寄给我，但是跨越Internet传送未加密的金钥十分不安全。解决金钥散布问题或许是使用秘密金钥演算法时最困难的课题，Kerberos如何解决将在本章稍後再做说明。</span><span id=Layer14></font></p><p><font size=2 color=#3c3c3c face=arial>散布秘密金钥是一个难题</span><span id=Layer15></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>散布秘密金钥是一个难题</span><span id=Layer16></font></p><hr><p><font size=2 color=#3c3c3c face=arial>现今，有许多不同的秘密金钥演算法正被使用着。最常见的演算法之一还是Data Encryption Standard （DES），它使用8位元组的金钥。DES始於1970年代，而且有些过时了。今天，差不多没有人会把DES看做安全性演算法。反而是其他的秘密金钥演算法更被广泛地使用，包括Triple-DES（就像它的名字所暗示的，是原始DES的加强版）、RC2、以及RC4。</span><span id=Layer17></font></p><p><font size=2 color=#3c3c3c face=arial>"RC"代表"Ron's Code"，依照这两个演算法的创造者Ron Rivest的名字而来。）</span><span id=Layer18></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>"RC"代表"Ron's Code"，依照这两个演算法的创造者Ron Rivest的名字而来。）</span><span id=Layer19></font></p><hr><font color=#3e72d7 face=arial size=4><b>Kerberos基础概念</span><span id=Layer20></b></font><p><font size=2 color=#3c3c3c face=arial>Kerberos总是会提供验证，而且如果应用程式要求的话它也能提供资料完整性以及资料私密性。执行这叁项服务都会利用到秘密金钥加密，因此加密金钥是Kerberos技术的重要部份。Kerberos能由平常的密码衍生出加密金钥，而不需要使用者自行创造专用的金钥。但是那些密码不可以用来加密在客户端与伺服端之间传送的实际资料。代替的做法是以密码为基础的金钥只能用在登入，本章後面会详加说明，而使用其它动态产生的金钥来加密与解密跨网路传送的资料。</span><span id=Layer21></font></p><p><font size=2 color=#3c3c3c face=arial>kerberos也主要依赖秘密加密金钥</span><span id=Layer22></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>kerberos也主要依赖秘密加密金钥</span><span id=Layer23></font></p><hr><p><font size=2 color=#3c3c3c face=arial>然而Windows 2000 kerberos也允许使用智慧卡与公开金钥加入密技术登入，</span><span id=Layer24> <a target='_new' href=204.htm#>下一章</span><span id=Layer25></a> 再做说明。</span><span id=Layer26></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>然而Windows 2000 kerberos也允许使用智慧卡与公开金钥加入密技术登入，</span><span id=Layer27> <a target='_new' href=204.htm#>下一章</span><span id=Layer28></a> 再做说明。</span><span id=Layer29></font></p><hr><p><font size=2 color=#3c3c3c face=arial>principal用来登入的金钥实际上是principal密码的杂凑（hash）。杂凑演算法（有时也称为讯息摘要演算法（message digest algorithm））产生一个来自被杂凑资料的位元字串，但是不能用来回覆原来的输入值。换句话说，杂凑是单向的。如果有一个杂凑密码产生的值，它已经不可能回覆到原来的密码了。</span><span id=Layer30></font></p><p><font size=2 color=#3c3c3c face=arial>可以杂凑密码来产生秘密加密金钥</span><span id=Layer31></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>可以杂凑密码来产生秘密加密金钥</span><span id=Layer32></font></p><hr><p><font size=2 color=#3c3c3c face=arial>在Windows 2000，使用者有密码，想要验证使用者的伺服端应用程式有密码，而且网域内的所有电脑有密码。有密码的任何东西就具有作为安全性principal的资格，它们的密码可以被验证。执行在网域控制站上的Kerberos Key Distribution Center （KDC）有存取网域内每个principal的已加密过密码的权限（这资讯存放在每个principal的Actvie Directory物件里，保留在同一网域控制站中）。预设情况下，明文密码不会存放在目录里面，只有杂凑过的译文才保留在那里。要与其它目录服务的密码同步的话，管理员可以把明文密码与杂凑过的译文存放在一起。无论选择哪个，principal的密码资讯只会以加密过的形式储存起来，而且是利用可取得的最强固的加密层级加以加密。然而，尽管有这层保护，网域控制站还是应该保持绝对地安全。你绝对会想避免一个有闲又有心的攻击者成功地窃入你的网域中最重要的系统。</span><span id=Layer33></font></p><p><font size=2 color=#3c3c3c face=arial>Kerberos能存取存放在Active Directory里的杂凑过的密码</span><span id=Layer34></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Kerberos能存取存放在Active Directory里的杂凑过的密码</span><span id=Layer35></font></p><hr><p><font size=2 color=#3c3c3c face=arial>Kerberos协定允许协商应该使用那个加密演算法，而Kerberos实作习惯上预设为8位元组金钥的DES。Windows 2000 Kerberos支援DES，但它的加密演算法预设是RC4。RC4比DES更快更安全，在标准的Windows 2000环境中，所有的Kerberos加密都会使用这个新演算法。</span><span id=Layer36></font></p><p><font size=2 color=#3c3c3c face=arial>Windows 2000 Kerberos预设使用RC4进行加密</span><span id=Layer37></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Windows 2000 Kerberos预设使用RC4进行加密</span><span id=Layer38></font></p><hr><p><font size=2 color=#3c3c3c face=arial>128位元金钥使用在北美版本。强固的密码使用法的美国外销法律在本书出版时可能会改变，这个叙述在你阅读此书时可能不再为真。</span><span id=Layer39></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>128位元金钥使用在北美版本。强固的密码使用法的美国外销法律在本书出版时可能会改变，这个叙述在你阅读此书时可能不再为真。</span><span id=Layer40></font></p><hr><p><font size=2 color=#3c3c3c face=arial>要如何使用秘密金钥加密技术来私下地传送资料是显而易见的，但是要如何用来验证就不那麽明显了。要了解如何做到，想像一下你和我分享一把金钥，而且假设我送给你一些利用这把金钥加密过的资料。如果你使用这把金钥对讯息进行解密而且解密结果也正确的话，那麽这讯息必需是使用同一金钥所加密的。如果只有你和我知道这把金钥的话，那麽这讯息必定是我送的。依此方式，我可以证明我的身分－不必传送金钥，我就能验证自己了。</span><span id=Layer41></font></p><p><font size=2 color=#3c3c3c face=arial>证明我知道金钥就能证明我是谁</span><span id=Layer42></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>证明我知道金钥就能证明我是谁</span><span id=Layer43></font></p><hr><p><font size=2 color=#3c3c3c face=arial>然而，用这麽简单的方式来使用秘密金钥加密技术做验证动作并不实用。那需要每一对客户端/伺服端分享一把金钥，这意味着我们想要安全存取的每一项服务都得有一把不同的金钥。这绝对不会是我们想要的。那麽，如何更有效使用秘密金钥加密技术来做验证动作呢？Kerberos已经提供了解答。</span><span id=Layer44></font></p><p><font size=2 color=#3c3c3c face=arial><font size=2 face=arial color=#3e80d7><b> Ticket</span><span id=Layer45> </b></font>当客户端想要对在某些其他系统上的伺服端应用程式证明自己的身分时，客户端必须以某种方式提供给伺服端一张适当的ticket。每张ticket都允许特定的客户端对特定的伺服端应用程式证明使用者的身分，例如是一个特殊的DCOM应用程式。如图3-5，Kerberos ticket包含已加密以及未加密的资讯。虽然图片稍嫌简化，但可看出ticket的未加密部分包含两块主要资讯：发行这张ticket的Windows 2000网域名称（Kerberos标准的术语是「领域（realm）」而不是「网域（domain）」）以及这ticket所识别的principal名称。</span><span id=Layer46></font></p><p><font size=2 color=#3c3c3c face=arial>使用ticket来证明身分</span><span id=Layer47></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>使用ticket来证明身分</span><span id=Layer48></font></p><hr><br><center><a target=_new href=imagesh/3-5.gif><img border=0 src='imagesl/3-5.gif'></a></center></span><span id=Layer49><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图3-5</span><span id=Layer50> </b></font>Kerberos ticket包含各式各样的栏位，大部分是加密过的。</span><span id=Layer51></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>Ticket的已加密部分包含相当多的资讯。下面列出几个较有趣的栏位：</span><span id=Layer52></font></p><font size=2 color=#3c3c3c face=arial><ul><font size=2 face=arial color=#3c3c3c><li>各种ticket旗标，其中一些稍後会再描述。</span><span id=Layer53></li><br></font><font size=2 face=arial color=#3c3c3c><li>一把加密金钥，通常被称为session金钥，用来对在ticket所识别的使用者，以及ticket的目的地伺服器之间交换的资讯进行加密。</span><span id=Layer54></li><br></font><font size=2 face=arial color=#3c3c3c><li>使用者的网域和principal名称加密过的副本。</span><span id=Layer55></li><br></font><font size=2 face=arial color=#3c3c3c><li>这张ticket的有效期间，开始与结束时间。</span><span id=Layer56></li><br></font><font size=2 face=arial color=#3c3c3c><li>用来识别使用者系统的一个或多个IP位址。</span><span id=Layer57></li><br></font><font size=2 face=arial color=#3c3c3c><li>使用者的授权资料，伺服端用来决定这个使用者可以存取些什麽。</span><span id=Layer58></li><br></font></ul></font><p><font size=2 color=#3c3c3c face=arial>使用这张ticket的目的地伺服端应用程式的金钥（那就是说已杂凑过的密码）将所有的那些栏位加密。值得注意的是，网路上的使用者与任何攻击者都不能读取或修改ticket中的已加密栏位，因为它们不知道伺服端加密用的密码。</span><span id=Layer59></font></p><p><font size=2 color=#3c3c3c face=arial>每张ticket的一部分都会被ticket将被送达的应用程式的金钥所加密</span><span id=Layer60></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>每张ticket的一部分都会被ticket将被送达的应用程式的金钥所加密</span><span id=Layer61></font></p><hr><p><font size=2 color=#3c3c3c face=arial>携带ticket的开始与结束时间的栏位值得我们再做一些说明。每张ticket的生命周期是有限的，这意味着攻击者只能有一段有限的时间可以破解密码，这让成功的侵入更加困难，而窃取的ticket也只能在它过期前使用（使用其他人的ticket实际上需要的不只是ticket而已，稍後再做描述）。生命周期限度也意味着每张ticket一段时间後就会过期，这相当麻烦的。幸运的是，只要使用者保持在登入状态的话，Windows 2000会自动更新使用者的ticket。</span><span id=Layer62></font></p><p><font size=2 color=#3c3c3c face=arial>Ticket会过期，但登入中的使用者会被自动更新</span><span id=Layer63></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Ticket会过期，但登入中的使用者会被自动更新</span><span id=Layer64></font></p><hr><p><font size=2 color=#3c3c3c face=arial>互动式登入 当客户端想要对伺服端证明使用者的身分时，它必须取得到那伺服端的ticket。事实上，整个Kerberos协定差不多就是在取得与使用ticket。在开始描述协定的工作原理之前，值得花点时间解释一下本章後面所使用的记号。我主要采用标准的Kerberos记号，它们是：</span><span id=Layer65></font></p><font size=2 color=#3c3c3c face=arial><ul><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> K</span><span id=Layer66><sub><font size=2 color=#3c3c3c face=arial>X</span><span id=Layer67></font></sub> </b></font>X 的秘密金钥（就是以杂凑过的密码），在这里的X是一个客户端（C）、一个伺服端应用程式（S）、或是KDC自己。</span><span id=Layer68></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> {任何东西}K</span><span id=Layer69><sub><font size=2 color=#3c3c3c face=arial>X</span><span id=Layer70></font></sub> </b></font>以X的秘密金钥所加密的任何东西。</span><span id=Layer71></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> {T}K</span><span id=Layer72><sub><font size=2 color=#3c3c3c face=arial>S</span><span id=Layer73></font></sub> </b></font>以伺服端S的秘密金钥所加密的ticket。换句话说，这是给伺服端S的ticket（这个记号有点不精确，因为并没有加密整个ticket）。</span><span id=Layer74></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> K</span><span id=Layer75><sub><font size=2 color=#3c3c3c face=arial>X,Y</span><span id=Layer76></font></sub></span><span id=Layer77> </b></font>在X和Y之间使用的session金钥。</span><span id=Layer78></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> {任何东西}K</span><span id=Layer79><sub><font size=2 color=#3c3c3c face=arial>X,Y</span><span id=Layer80></font></sub> </b></font>以在X和Y之间使用的session金钥所加密的任何东西。</span><span id=Layer81></li><br></font></ul></font><p><font size=2 color=#3c3c3c face=arial>使用者第一次要求Kerberos ticket的时机是在使用者登入Windows 2000网域的某个帐号时。就使用者的观点来看，过程相当简单：在某台客户端机器上键入登入名称、网域名称、以及密码，然後等着看登入成功或失败。然而，真正发生的事情并没这麽简单。</span><span id=Layer82></font></p><p><font size=2 color=#3c3c3c face=arial>对使用者而言，Kerberos协定是看不见的</span><span id=Layer83></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>对使用者而言，Kerberos协定是看不见的</span><span id=Layer84></font></p><hr><p><font size=2 color=#3c3c3c face=arial>如图3-6，使用者的登入要求引发客户端机器送出一个讯息到执行在网域控制站上的KDC。讯息中包含几样东西，包括：</span><span id=Layer85></font></p><font size=2 color=#3c3c3c face=arial><ul><font size=2 face=arial color=#3c3c3c><li>使用者名称。</span><span id=Layer86></li><br></font><font size=2 face=arial color=#3c3c3c><li>预验资料（pre-authentication data），由一个使用K</span><span id=Layer87><sub><font size=2 color=#3c3c3c face=arial>C</span><span id=Layer88></font></sub>（就是使用者密码的杂凑值）当作金钥来加密的时间标签（timestamp）所组成。</span><span id=Layer89></li><br></font><font size=2 face=arial color=#3c3c3c><li>一个ticket-granting ticket （TGT）的要求。就像图3-5所示，TGT也只是一张平常的ticket。和所有的ticket一样，它被用来证明使用者的身分。但TGT的使用方式有点特别：我们将会看到，当要求要特定伺服端应用程式的ticket时，客户端的Kerberos SSP会向KDC出示TGT。</span><span id=Layer90></li><br></font></ul></font><p><font size=2 color=#3c3c3c face=arial>使用者再登入时要求一张ticket-granting ticket</span><span id=Layer91></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>使用者再登入时要求一张ticket-granting ticket</span><span id=Layer92></font></p><hr><br><center><a target=_new href=imagesh/3-6.gif><img border=0 src='imagesl/3-6.gif'></a></center></span><span id=Layer93><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图3-6</span><span id=Layer94> </b></font>登入期间，使用者取得TGT与session金钥，并利用它们求取其它ticket。</span><span id=Layer95></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>当这个要求到达网域控制站，KDC在网域的Active Directory资料库里查询出与使用者的principal名称相关联的项目。由这个项目，KDC取得使用者密码的杂凑值，然後使用它将预验资料解密。如果解密成功－如果得到的结果是最近的时间标签－KDC就可以确信这个使用者就是他或她所声称的人，因为使用者已经证明他知道正确的密码（注意，完成这件事并不需要在网路上传送密码。Kerberos提供的服务从不要求跨网路传送密码）。然而，如果解密失败的话，绝对是使用者输入了错误的密码，登入就失败了。</span><span id=Layer96></font></p><p><font size=2 color=#3c3c3c face=arial>KDC核对使用者的最初要求</span><span id=Layer97></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>KDC核对使用者的最初要求</span><span id=Layer98></font></p><hr><p><font size=2 color=#3c3c3c face=arial>如果预验资料确认了，KDC接着建立并传回客户端机器要求的：ticket-granting ticket（TGT）。就像所有的ticket，这张ticket包含使用者名称和发行它的网域名称、由KDC随机产生的session金钥K</span><span id=Layer99><sub><font size=2 color=#3c3c3c face=arial>C,K</span><span id=Layer100></font></sub>、ticket的生效与失效时间、以及各种旗标值。在授权资料（Authorization Data）栏位，TGT包含Windows 2000 SID以及其他可以识别使用者与使用者所属群组的资讯（这资讯是由Active Directory里的使用者项目取得的）。同样地，ticket的已加密部份是使用ticket将送往的伺服端之金钥加密的。因为TGT只被用来求取其它的ticket而且只有KDC可以发出ticket，所以TGT的已加密部份是使用KDC自己的金钥K</span><span id=Layer101><sub><font size=2 color=#3c3c3c face=arial>K</span><span id=Layer102></font></sub>加密的。</span><span id=Layer103></font></p><p><font size=2 color=#3c3c3c face=arial>如果一切正常，KDC送给使用者一张TGT</span><span id=Layer104></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>如果一切正常，KDC送给使用者一张TGT</span><span id=Layer105></font></p><hr><p><font size=2 color=#3c3c3c face=arial>除了TGT之外，KDC也将session金钥K</span><span id=Layer106><sub><font size=2 color=#3c3c3c face=arial>C,K</span><span id=Layer107></font></sub>一起送回给客户端，这金钥的值与伺服端放在TGT内的相同。利用使用者的已杂凑密码当作金钥将这把session金钥加以加密。当客户端机器得到这个讯息，它利用使用者输入的密码将收到的session金钥解密。在Windows 2000 Kerberos，这样的解密方式永远可行，因为只有藉由预验资料证明自己知道正确密码的使用者，才会真的收到送给它们的资讯。</span><span id=Layer108></font></p><p><font size=2 color=#3c3c3c face=arial>KDC也送给使用者已加密的session金钥</span><span id=Layer109></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>KDC也送给使用者已加密的session金钥</span><span id=Layer110></font></p><hr><p><font size=2 color=#3c3c3c face=arial>在Kerberos标准里，是否传送预验资料是可选择的，但Windows 2000 Kerberos选择永远使用。然而，非Microsoft的Kerberos实作通常选择不使用。如果一个帐号被设定为允许不使用的话，Windows 2000网域控制站也可以接受无预验资料的要求。这使得Windows 2000 KDC也能用在不产生这资讯的Kerberos客户端上。如果是这样的话，就在将收到的session金钥解密时证实使用者的身分，如图3-6的步骤四所示。如果输入的密码正确，对客户端/KDC session金钥的解密成功。然而，如果使用者键入错误的密码，解密会失败而使用者将不会得知这把session金钥。而就像下一节将描述的，取得到其他服务的ticket必需知道这把金钥。</span><span id=Layer111></font></p><p><font size=2 color=#3c3c3c face=arial>另一件令人关切的事值得在此一提：如果没有KDC可以使用的话，怎麽办？就算是整个网路都挂掉了，阻止使用者登入他的机器都是个坏主意。为了要在网路发生问题或伺服器错误时可以登入本机，已杂凑过的使用者密码以及使用者名称被存放在他或她的机器上。如果没有KDC可以使用的话，将使用者输入的资讯与这些储存的资料作比对。符合的话，登入成功。</span><span id=Layer112></font></p><p><font size=2 color=#3c3c3c face=arial>即使没有KDC可以使用，也能登入本机</span><span id=Layer113></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>即使没有KDC可以使用，也能登入本机</span><span id=Layer114></font></p><hr><p><font size=2 color=#3c3c3c face=arial><font size=2 face=arial color=#3e80d7><b> 网路验证</span><span id=Layer115> </b></font>一旦使用者成功登入，他可能会开始存取网路里其他电脑上的服务。基於安全考量，使用者至少必须以某些方式向那些服务证明自己的身分。在Windows 2000，Kerberos SSP可以呈交一张TGT给KDC来求取到特定服务的ticket。为了与TGT有所区别，这些ticket有时称为服务ticket，但两者的格式是完全相同的。然後那张ticket被送到目的地服务，目的地服务可以利用这张ticket来决定使用者是谁（事实上，取得TGT後，每个客户端马上求取他自己电脑的服务ticket以完成登入程序，这使得他可以向本机上的服务证明自己的身分）。</span><span id=Layer116></font></p><p><font size=2 color=#3c3c3c face=arial>给一张有效的TGT，KDC将发行服务ticket</span><span id=Layer117></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>给一张有效的TGT，KDC将发行服务ticket</span><span id=Layer118></font></p><hr><p><font size=2 color=#3c3c3c face=arial>在KDC中发出到特定服务之ticket的功能，有时称为ticket granting service （TGS）。</span><span id=Layer119></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>在KDC中发出到特定服务之ticket的功能，有时称为ticket granting service （TGS）。</span><span id=Layer120></font></p><hr><p><font size=2 color=#3c3c3c face=arial>例如，假设使用者想要存取一个执行在某个远端系统上的DCOM伺服端应用程式（称为伺服端S）。使用者载入应用程式的客户端部分，而这客户端会试着建立远端DCOM物件。然而，如果应用程式使用Kerberos来验证的话，客户端应用程式在存取远端伺服端之前，需要取得代表使用者的ticket。回想一下，一张ticket用来验证一个特定的使用者到一项特定的服务。因为分散式应用程式的客户端部份代表使用者，所以客户端得取得ticket来向伺服端证明使用者的身分。</span><span id=Layer121></font></p><p><font size=2 color=#3c3c3c face=arial>一张服务ticket验证一个使用者到一项特定的服务</span><span id=Layer122></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>一张服务ticket验证一个使用者到一项特定的服务</span><span id=Layer123></font></p><hr><p><font size=2 color=#3c3c3c face=arial>当客户端应用程式第一次送远端要求到伺服端，一个ticket要求会被送到KDC，如图3-7所示。程式开发者通常不必撰写这部分程式。代替的是，应用程式发展者只需要求使用Kerberos，其他事情就会在暗地里完成。这个要求包含几个东西，包括：</span><span id=Layer124></font></p><font size=2 color=#3c3c3c face=arial><ul><font size=2 face=arial color=#3c3c3c><li>使用者的TGT。</span><span id=Layer125></li><br></font><font size=2 face=arial color=#3c3c3c><li>服务ticket要求的伺服端应用程式名称，在这里是伺服端S。</span><span id=Layer126></li><br></font><font size=2 face=arial color=#3c3c3c><li>证明某个TGT属於某个使用者的authenticator。authenticator包含有现在时间以及使用者名称，而且使用登入时收到的session金钥K</span><span id=Layer127><sub><font size=2 color=#3c3c3c face=arial>C,K</span><span id=Layer128></font></sub>加密。</span><span id=Layer129></li><br></font></ul></font><br><center><a target=_new href=imagesh/3-7.gif><img border=0 src='imagesl/3-7.gif'></a></center></span><span id=Layer130><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图3-7</span><span id=Layer131> </b></font>使用TGT求取到特定伺服端应用程式的session ticket，然後使用这个session ticket证明使用者的身分。</span><span id=Layer132></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>当KDC收到这个要求，它将TGT解密（回想一下，只有KDC知道用来加密这张ticket的金钥K</span><span id=Layer133><sub><font size=2 color=#3c3c3c face=arial>K</span><span id=Layer134></font></sub>），然後从ticket中取得session金钥K</span><span id=Layer135><sub><font size=2 color=#3c3c3c face=arial>C,K</span><span id=Layer136></font></sub>。它接着使用这把session金钥将authenticator解密。Authenticator适合两项用途。首先，因为它是被客户端/KDC session金钥加密的，它可以证明使用者是不是它所宣称的人。因为就像前面已经提过的，取得session金钥的唯一方法是在登入时键入正确的密码。如果KDC将authenticator解密的尝试成功了，那麽客户端必定是拥有正确的session金钥。</span><span id=Layer137></font></p><p><font size=2 color=#3c3c3c face=arial>Authenticator可以证明使用者的身分</span><span id=Layer138></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Authenticator可以证明使用者的身分</span><span id=Layer139></font></p><hr><p><font size=2 color=#3c3c3c face=arial>再来，因为authenticator包含一张时间标签，可防止攻击者从网路上窃取使用者的TGT。每次产生一个新的authenticator就伴随使用一张ticket，而且因为时间标签是用只有客户端以及KDC才知道的session金钥加密的，所以并不是任何人都可以产生有效的authenticator。为了防止恶意的第叁者储存并且稍後重送authenticator（一个众所周知的例子是重播攻击（replay attack）），KDC将会拒绝任何时间标签太旧的authenticator。预设情况下，authenticator的时间标签必须与伺服器收到它的时间相差不超过5分钟，但这可以藉由管理工具更改。 为了进一步保证使用者不是呈交偷来的ticket，KDC也核对TGT中的IP位址与送出要求之系统的IP位址是否吻合。</span><span id=Layer140></font></p><p><font size=2 color=#3c3c3c face=arial>Authenticator防止重播攻击</span><span id=Layer141></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Authenticator防止重播攻击</span><span id=Layer142></font></p><hr><p><font size=2 color=#3c3c3c face=arial>这意味着使用Kerberos之机器的时钟至少必须松散地同步（loosely synchronize），所以Windows 2000使用IETF定义的Simple NetworkTime Protocol （SNTP）来执行时钟同步动作。</span><span id=Layer143></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>这意味着使用Kerberos之机器的时钟至少必须松散地同步（loosely synchronize），所以Windows 2000使用IETF定义的Simple NetworkTime Protocol （SNTP）来执行时钟同步动作。</span><span id=Layer144></font></p><hr><p><font size=2 color=#3c3c3c face=arial>如果每件事都检查过了，KDC将相信使用者就是他所宣称的人，而且送回他要求的服务ticket。KDC将TGT的某些栏位拷贝到新的服务ticket，包括使用者名称、网域、以及授权资料。它适当地设定服务ticket的旗标与开始/结束时间，并且随机产生一把将放置在ticket里的session金钥（简单地说，这把金钥是用来对在客户端与伺服端S之间传送的资讯进行加密）。然後KDC使用伺服端S的秘密金钥K</span><span id=Layer145><sub><font size=2 color=#3c3c3c face=arial>S</span><span id=Layer146></font></sub>将这张新的ticket加密，并且将ticket以及新的session金钥K</span><span id=Layer147><sub><font size=2 color=#3c3c3c face=arial>C,S</span><span id=Layer148></font></sub>送回给客户端。为了避免攻击者得知这把新的金钥，传送时使用KDC与客户端共有的session金钥将其加密。</span><span id=Layer149></font></p><p><font size=2 color=#3c3c3c face=arial>KDC从TGT复制某些资讯至它引发的每一个服务ticket</span><span id=Layer150></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>KDC从TGT复制某些资讯至它引发的每一个服务ticket</span><span id=Layer151></font></p><hr><p><font size=2 color=#3c3c3c face=arial>终於，整个练习的目标可以达成了：使用者能向伺服端应用程式证明他或她的身分。在送第一个要求到伺服端时，客户端呈交服务ticket，这张ticket是刚刚与使用K</span><span id=Layer152><sub><font size=2 color=#3c3c3c face=arial>C,S</span><span id=Layer153></font></sub>加密的authenticator一起收到的。这资讯是协定的一部分，而在客户端与伺服端之间使用。例如，在DCOM，ticket与authenticator被携带在适当的DCOM封包内的栏位里。不管怎样传送，接收系统用它的秘密金钥将ticket解密、从ticket中取得session金钥K</span><span id=Layer154><sub><font size=2 color=#3c3c3c face=arial>C,S</span><span id=Layer155></font></sub>、然後解密以及验证authenticator。如果每件事都检查过了，从ticket中取出使用者的身分资讯－principal名称、网域名称、与授权资料－以及使得它可以存取到伺服端应用程式。Kerberos SPP做掉所有这些事情，伺服端应用程式的开发者一点也不需要担心。</span><span id=Layer156></font></p><p><font size=2 color=#3c3c3c face=arial>接收系统将服务ticket解密以核对使用者的身分</span><span id=Layer157></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>接收系统将服务ticket解密以核对使用者的身分</span><span id=Layer158></font></p><hr><p><font size=2 color=#3c3c3c face=arial>虽然Kerberos并没有直接指出这件事，从收到的tciket取出的使用者相关资讯通常被用来做授权决定。实际上，要怎麽做全由伺服端应用程式的创作者决定：应用程式可以利用授权资料来模拟使用者、使用先前提过的标准Windows 2000授权方法、或是可以做一些比较简单的事情，例如在记录使用者可使用功能的清单中查询使用者的名称。至於授权如何执行、甚至是否真的执行，就不在Kerberos的职权范围内了。Kerberos反倒是专注在保证使用者确实是他在服务ticket中所宣称的身分。</span><span id=Layer159></font></p><p><font size=2 color=#3c3c3c face=arial>接收系统以它喜欢的任何方式做授权决定</span><span id=Layer160></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>接收系统以它喜欢的任何方式做授权决定</span><span id=Layer161></font></p><hr><p><font size=2 color=#3c3c3c face=arial>为了确定所有事情都已经讲清楚了，让我来总结一下为什麽这样的验证程序是可行的：因为使用者呈交的服务ticket是以伺服端S的秘密金钥加密的，而且因为只有KDC（当然还有伺服端S）知道这把金钥，所以这张ticket必须由KDC产生。而且因为KDC只会把服务金钥发给可以藉由正确地加密预验资料来证明自己知道正确密码的使用者，所以这个使用者绝对是他或她所宣称的人。与有效的authenticator一起呈交，一张Kerberos ticket就可以让使用者向伺服端证明他或她的身分。</span><span id=Layer162></font></p><p><font size=2 color=#3c3c3c face=arial>但是相反的问题又如何呢？我们刚刚已经看过Kerberos如何向伺服端证明客户端的身分，但客户端又如何确信伺服端就是它所宣称的人呢？攻击者可能安装一个伪造的伺服端S，然後欺骗客户端把它当作真正的伺服端藉以取得敏感资讯。为了避免这件事发生，Kerberos标准定义了相互验证（mutual authentication）的选择，绝大多数的应用程式都应该选择使用它。实作方式是，在伺服端的Kerberos SSP产生一个的讯息，其中包含有来自客户端的authenticator（使用客户端/伺服端S session金钥加密）之时间标签。当客户端上的Kerberos SSP收到这个讯息，它可以使用它的session金钥副本将讯息解密。如果客户端的Kerberos SSP发现时间标签与它刚刚送出的一样，那麽可以确定伺服端也知道这把session金钥。而且因为要得知这把session金钥必须将伺服端的ticket解密，这就会需要知道伺服端的密码，所以这个伺服端绝对是它所宣称的人。</span><span id=Layer163></font></p><p><font size=2 color=#3c3c3c face=arial>Kerberos也允许伺服端向客户端证明自己的身分</span><span id=Layer164></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Kerberos也允许伺服端向客户端证明自己的身分</span><span id=Layer165></font></p><hr><p><font size=2 color=#3c3c3c face=arial><font size=2 face=arial color=#3e80d7><b> 提供资料完整性与资料私密性</span><span id=Layer166> </b></font>到目前为止所描述的所有复杂机制都是在说明Kerberos如何提供一项安全性服务：验证。然而，回想一下，Kerberos也提供资料完整性与资料私密性这两项有用的服务。因为刚刚所提的交换机制使得客户端与伺服端拥有一把共有的session金钥，要提供这些服务就变得相当直接了。</span><span id=Layer167></font></p><p><font size=2 color=#3c3c3c face=arial>资料伴随着加密过的检查码以提供资料完整性</span><span id=Layer168></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>资料伴随着加密过的检查码以提供资料完整性</span><span id=Layer169></font></p><hr><p><font size=2 color=#3c3c3c face=arial>为了保证攻击者不能偷偷修改传送的资料，Kerberos SSP会为它所传送的每一个封包计算出一个检查码 （checksum）并且与封包一起传送这个检查码。检查码的值是基於资料而产生的函数值，所以如果资料改变了，检查码也会跟着改变。但是只送封包以及检查码是不够的－攻击者可能抓取封包、修改资料、为新的资料重新计算出检查码、然後传送它。为了避免这件事发生，资料的传送者不只利用讯息本身计算检查码，而是利用讯息还有其他资讯，然後使用session金钥将结果加密（在预设情况下，Windows 2000 Kerberos使用Message Digest 5 [MD5] 检查码演算法，而使用RC4将检查码加密，你也可以选择其他它支援的演算法）。没有攻击者可以为相改过的资料产生有效的检查码，因为它们不知道正确的session金钥。结果是封包的接收者总是可以察觉有没有人想要修改封包的内容。一如往常，Kerberos SSP会做掉这些工作，应用程式开发者要做的只是要求这项服务就行了。</span><span id=Layer170></font></p><p><font size=2 color=#3c3c3c face=arial>最後，提供资料私密性相当简单。因为客户端与伺服端共享一把session金钥，每台机器上的Kerberos SSP只要使用这把金钥将它要送给其他人的资料加密就行了。注意，资料私密性必然包含资料完整性，因为所有攻击者对网路上传送的已加密资料的修改意图都会被察觉出来。</span><span id=Layer171></font></p><p><font size=2 color=#3c3c3c face=arial>将资料加密以提供资料私密性</span><span id=Layer172></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>将资料加密以提供资料私密性</span><span id=Layer173></font></p><hr><p><font size=2 color=#3c3c3c face=arial>使用Kerberos的应用程式 定得使用资料完整性或资料私密性－通常是透过适当的API来要求使用它们－而且使用它们有碍效能。但是不使用它们又留给攻击者一个攻击漏洞，所以该如何决定，每个应用程式开发者得自己衡量。</span><span id=Layer174></font></p><font color=#3e72d7 face=arial size=4><b>其它Kerberos主题</span><span id=Layer175></b></font><p><font size=2 color=#3c3c3c face=arial>Kerberos提供分散式环境中基本的安全性服务：验证、资料完整性、以及资料私密性。但这技术提供了比我们已经看过的还要多的服务。本节就来多看一些进阶的Kerberos主题。</span><span id=Layer176></font></p><p><font size=2 color=#3c3c3c face=arial><font size=2 face=arial color=#3e80d7><b> 管理ticket与金钥</span><span id=Layer177> </b></font>一旦客户端取得ticket，它会把ticket以及相关的session金钥一起储存在客户端系统的ticket暂存区里。在ticket过期前，客户端可以一再地使用金钥以及ticket。那就是说，用到包含在ticket的结束时间（End Time）栏位时间为止。而且就像前面所说的一样，当ticket过期时，Windows 2000 Kerberos会自动更新它们，所以当使用者的TGT过期时，使用者不必重新登入。</span><span id=Layer178></font></p><p><font size=2 color=#3c3c3c face=arial>一旦取得ticket会被暂存在使用者的机器里</span><span id=Layer179></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>一旦取得ticket会被暂存在使用者的机器里</span><span id=Layer180></font></p><hr><p><font size=2 color=#3c3c3c face=arial>先前提过，Kerberos也要求每一个principal都要有一个密码，principal的秘密金钥就是由这个密码衍生而来的。每个使用者都有责任记住他或她自己的密码，但是伺服端应用程式又要如何存放它们的密码呢？答案是每个伺服端应用程式在本机上存放自己的密码，加密放在登录的安全区域里。就像所有的密码，这个密码应该被定期变更，这是管理员要做的事，系统不会自动变更伺服端应用程式的密码。</span><span id=Layer181></font></p><p><font size=2 color=#3c3c3c face=arial>伺服端应用程式的密码被存放在应用程式所在的机器上</span><span id=Layer182></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>伺服端应用程式的密码被存放在应用程式所在的机器上</span><span id=Layer183></font></p><hr><p><font size=2 color=#3c3c3c face=arial>另一个较简单、较安全的选择是设定伺服端应用程式去使用它所在机器principal（machine principal）的密码。这样一来，会将需要管理的密码之数量减到最低，而且因为机器principal密码会被定期变更，这让管理员的维护工作变得轻松多了。</span><span id=Layer184></font></p><p><font size=2 color=#3c3c3c face=arial><font size=2 face=arial color=#3e80d7><b> Delegation</span><span id=Layer185> </b></font>在前面的例子中，假设使用者已经向伺服端S证明他自己。伺服端S现在可以模拟这个使用者并且试着存取本机系统上的某些资源，例如一个档案。在这种情况下，Windows 2000内建的存取检查将会基於档案的ACL同意或拒绝存取动作。如果被存取的资源与伺服端在同一机器上的话，所有的动作都是理所当然的。</span><span id=Layer186></font></p><p><font size=2 color=#3c3c3c face=arial>但如果不是呢？假设要完成使用者要求的工作，伺服端S必须向执行在别台机器上的伺服端提出要求。即使伺服端T的直接使用者（direct user）是伺服端S，但它只是代表原始使用者（original user）提出要求，伺服端S并不是原始使用者。要想运作正常，使用者必须有某些方式可以传递它的身分给伺服端S，让伺服端S可以代为做进一步的远端要求。</span><span id=Layer187></font></p><p><font size=2 color=#3c3c3c face=arial>Kerberos藉由delegation支援这个想法，如图3-8所示。如果客户端应用程式要求的话，使用者的TGT以及关联的session金钥可以被传递给另一台伺服器，例如伺服器S（只送TGT是不够的，因为需要session金钥来建构要与TGT一起传送的authenticator）。就像所有的ticket一样，TGT会被加密，但要确定在网路传送时TGT的关联session金钥不会被攻击者偷走，所以再使用客户端与伺服端S共享的session金钥将这把金钥加密。</span><span id=Layer188></font></p><p><font size=2 color=#3c3c3c face=arial>Delegation允许伺服端具有由客户端传递过来的使用者身分</span><span id=Layer189></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Delegation允许伺服端具有由客户端传递过来的使用者身分</span><span id=Layer190></font></p><hr><br><center><a target=_new href=imagesh/3-8.gif><img border=0 src='imagesl/3-8.gif'></a></center></span><span id=Layer191><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图3-8</span><span id=Layer192> </b></font>S 藉由求取一张新的ticket，一个伺服端可以代表原始使用者存取另一个伺服端。</span><span id=Layer193></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>客户端要传递TGT到伺服端S必须是设定旗标（Flags）栏位中的FORWARDABLE旗标。然後伺服端S呈交TGT给KDC并且求取存取其它服务的ticket，即使是TGT中的IP位址与伺服端S的IP位址并不吻合也无所谓，FORWARDABLE旗标告诉KDC可以忽略这个不一致。客户端也只能传送它的TGT以及关联的session金钥给在Active Directory中帐号被标志为trusted for delegation的伺服端。并不允许使用者delegate它们的身分到任何伺服器。</span><span id=Layer194></font></p><p><font size=2 color=#3c3c3c face=arial>要想知道这怎麽总是行的通，假设客户端传递使用者的TGT以及关联的session金钥给伺服端S并且设定FORWARDABLE旗标。如果伺服端S需要代表使用者存取伺服端T的话，它呈交TGT以及有效的authenticator给KDC以求取到伺服端T的新ticket。就像原来的ticket一样，这张新的ticket会包含有使用者的身分，但是将会使用伺服端T的密码将它加密。当伺服端S将新的ticket以及有效的authenticator呈交给伺服端T时，伺服端T的行为表现就好像收到的要求是直接来自客户端的。</span><span id=Layer195></font></p><p><font size=2 color=#3c3c3c face=arial><font size=2 face=arial color=#3e80d7><b> 网域间的Kerberos</span><span id=Layer196> </b></font>到目前为止所描述的每件事都是假设客户端、伺服端、以及KDC在同一个网域内。Kerberos也允许在不同网域的客户端与伺服端做验证动作。这个程序比起我们先前看过的会稍微复杂些。</span><span id=Layer197></font></p><p><font size=2 color=#3c3c3c face=arial>不管执行伺服端应用程式的激起所在的网域为何，要向应用程式证明自己，客户端必须取得到那台机器的ticket。但是只有与目的地伺服端位在相同网域的KDC才能发行这张ticket，因为只有他知道伺服端的密码。如果客户端想要向不同网域中的伺服端证明自己的身分，那麽他必须向位在那个网域里的KDC求取一张到伺服端的ticket。一如往常，向KDC要求一张ticket需要呈交TGT给KDC。那麽，主要的问题是客户端必须取得到位於外面网域之KDC的TGT。一旦客户端有了这张TGT，他就可以以平常的方式要求以及使用到目的地伺服端的ticket。</span><span id=Layer198></font></p><p><font size=2 color=#3c3c3c face=arial>客户端可以要求一张到位於另一个网域之KDC的TGT</span><span id=Layer199></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>客户端可以要求一张到位於另一个网域之KDC的TGT</span><span id=Layer200></font></p><hr><p><font size=2 color=#3c3c3c face=arial>要使这成为可能，两个网域之间必须存在信任（trust）关系。跨网域信任如何在Windows 2000中达成将在下一节中详细说明，现在要知道的关键点是，当两个网域的信任关系建立时，同事也会产生一把只有这两个网域才知道的金钥。使用这把共享的金钥将在两个网域之间传递的ticket加密。</span><span id=Layer201></font></p><p><font size=2 color=#3c3c3c face=arial>跨网域存取需要网域间有信任关系</span><span id=Layer202></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>跨网域存取需要网域间有信任关系</span><span id=Layer203></font></p><hr><p><font size=2 color=#3c3c3c face=arial>图3-9展示运作流程（为了简化起见，图中省略了authenticator）。如图所示，假设位於us.qwickbank.com网域的客户端想要存取位於europe.qwickbank.com网域的伺服端Q。客户端首先呈交TGT给位於自己所在us.qwickbank.com网域里的KDC，要求要一张到位於europe.qwickbank.com网域里之KDC的TGT。us.qwickbank.com网域的KDC传回一张客户端可以用来向位於europe.qwickbank.com网域的KDC求取ticket的TGT。这张ticket会被这两个网域共享的金钥K</span><span id=Layer204><sub><font size=2 color=#3c3c3c face=arial>x</span><span id=Layer205></font></sub>加以加密。</span><span id=Layer206></font></p><p><font size=2 color=#3c3c3c face=arial>一旦有了这张TGT，客户端接着将它呈交给europe.qwickbank.com网域里的KDC，要求一张到伺服器Q的ticket（客户端可以利用DNS找到任何外面网域的网域控制站）。europe.qwickbank.com网域里的KDC使用与us.qwickbank.com网域的KDC共享的金钥，将客户端呈交的TGT加密。如果TGT是有效的，KDC接着在它的Active Directory资料库中查询伺服端Q的密码并且利用它来建造一张到伺服端Q的ticket。然後把ticket送回给客户端，它就可以把ticket呈交给伺服端Q了。</span><span id=Layer207></font></p><p><font size=2 color=#3c3c3c face=arial>在网域之间使用Kerberos的技术相当简单。所要做的只是增加了取得位於外面网域之KDC的TGT这额外的步骤（又一次，Kerberos SSP自动做掉了－应用程式开发者一点都不必担心）。但想想看在这个例子中europe.qwickbank.com网域的KDC在暗地里做了什麽样假设：它信任us.qwickbank.com网域的KDC在核对客户端的身分前不会发出这张TGT。换句话说，藉由收到以共享金钥加密的TGT，europe.qwickbank.com网域信任us.qwickbank.com网域的KDC正确地运作。要跨网域验证能够通行无阻，牵涉在内的两个网域必须要能互相信任。</span><span id=Layer208></font></p><br><center><a target=_new href=imagesh/3-9.gif><img border=0 src='imagesl/3-9.gif'></a></center></span><span id=Layer209><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图3-9</span><span id=Layer210> </b></font>在客户端取得到另一个Windows 2000网域之KDC的TGT後，客户端可以要求那个网域的ticket。</span><span id=Layer211></td></table></font></center><p><font size=2 color=#3c3c3c face=arial><font size=2 face=arial color=#3e80d7><b> 网域间的信任</span><span id=Layer212> </b></font>在两个网域间建立建立信任需要那些网域共享一个密码，然後使用这个密码当作加密金钥来产生到彼此KDC的TGT。在只有少数网域的组织里，明确地建立所有网域间的信任关系并不会花太多的功夫。然而，在拥有很多网域组织里，明确地建立所有网域间的信任关系就会事件艰钜的事了。很幸运的，在Windows 2000中，这不是必须的。不像Windows NT 4必须明确地管理网域间的信任关系，Windows 2000让管理员少做了很多工。</span><span id=Layer213></font></p><p><font size=2 color=#3c3c3c face=arial>首先，当一个新的网域加入网域树 （tree） 或树林forest） 时，Windows 2000自动建立两个网域间双向的信任关系。更具体地说，系统自动产生一把共享的金钥，并存放在每个网域的Active Directory中的设定（Configuration）资料里。就像刚刚说的，这把金钥是用来加密送到另一个网域的TGT。你可以不接受这预设值－利用设定管理工具的方式产生单向的信任关系是有可能的－但就定义来说，在网域树或树林内的所有网域都必须有双向的信任关系。</span><span id=Layer214></font></p><p><font size=2 color=#3c3c3c face=arial>网域数或树林里的所有网域必需彼此信任</span><span id=Layer215></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>网域数或树林里的所有网域必需彼此信任</span><span id=Layer216></font></p><hr><p><font size=2 color=#3c3c3c face=arial>然而，想一下如图3-10所示的网域树。根网域qwickbank.com之下有两个别的网域。这些网域都有自己的子网域（child domain）。预设情况下，每个网域都与它的父网域（parent domain）以及直接的子网域有双向的信任关系（那也就是说，一把共享的金钥）。但是间隔两个层级的网域又如何呢？根网域与位於网域树底部的网域需要有共享的金钥吗？</span><span id=Layer217></font></p><p><font size=2 color=#3c3c3c face=arial>很幸运地，答案是否定的。Kerberos提供transitive信任，这是一个简单想法的花俏名字。想法是，如果qwickbank.com网域信任europe.qwickbank.com网域，而europe.qwickbank.com网域又信任france.europe.qwickbank.com网域的话，那麽在qwickbank.com网域与france.europe.qwickbank.com网域之间自动就会建立起双向的信任 关系。就像前面所说的，网域树或树林内的任两个网域之间都有双向的 信任关系。网域只需与户网域以及直接组网域之间有共享的金钥－ Kerberos就会处理其馀部份。</span><span id=Layer218></font></p><p><font size=2 color=#3c3c3c face=arial>Transitive信任允许一个网域信任没有共享金钥的其他网域</span><span id=Layer219></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Transitive信任允许一个网域信任没有共享金钥的其他网域</span><span id=Layer220></font></p><hr><br><center><a target=_new href=imagesh/3-10.gif><img border=0 src='imagesl/3-10.gif'></a></center></span><span id=Layer221><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图3-10</span><span id=Layer222> </b></font>所有在网域树或树林里的网域之间都有transitive信任关系。</span><span id=Layer223></td></table></font></center><p><font size=2 color=#3c3c3c face=arial>在此说明transitive信任关系的运作原理。假设在qwickbank.com网域的客户端想要存取france.europe.qwickbank.com网域的伺服端R。客户端的网域与europe.qwickbank.com网域有信任关系（那就是说，有共享的金钥），而europe.qwickbank.com网域与france.europe.qwickbank.com网域有信任关系（所以他们的KDC共享一把金钥）。客户端首先向它的KDC求取一张到europe.qwickbank.com网域内之KDC的TGT。然後客户端连路那个KDC、呈交这张TGT、并且求取到网域内之KDC的TGT（在france.europe.qwickbank.com中）。一旦客户端有了另一张TGT，它呈交这张TGT给france.europe.qwickbank.com网域的KDC，并且要求一张到伺服端R的ticket。因为客户端已经呈交了一张有效的TGT，这最後的KDC很乐意提供出要求的ticket。只要全程都有信任关系（以及共享金钥），一切正常运作。就向所有的ticket一样，到另一个网域之KDC的ticket当然是暂存在客户端的机器上，这使得它们可以被重复使用。</span><span id=Layer224></font></p><p><font size=2 color=#3c3c3c face=arial>Transitive信任关系相当好，但它并不永远是适当的解决方案。例如，假设你想要在Windows 2000网域与Windows NT 4网域之间建立信任关系。因为Windows NT 4并不支援Kerberos，你所能做的最多只是在这些网域之间建立起单向的信任链结－transitive信任做不到。这种关系称为nontransitive信任。管理员可以选择在各个方向建立nontransitive信任关系，让两个网域里的使用者可以被验证去存取两者之中任何一个网域内的服务，但这必需自行手动去做。另一个需要用到nontransitive信任的情况是当信任链结建立在跨网域树林边界的时候，即使完全都是Windows 2000的环境中也一样。位在不同网域树林之网域间的transitive信任是不可能存在的，所以需要的话，管理员必需手动建立nontransitive信任关系。</span><span id=Layer225></font></p><p><font size=2 color=#3c3c3c face=arial>Windows 2000也允许建立nontransitive信任关系</span><span id=Layer226></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Windows 2000也允许建立nontransitive信任关系</span><span id=Layer227></font></p><hr><p><font size=2 color=#3c3c3c face=arial><font size=2 face=arial color=#3e80d7><b> 与非Microsoft Kerberos实作的互通性</span><span id=Layer228> </b></font>藉着在Windows 2000使用Kerberos，Microsoft已经保证了这项技术会被广泛使用。但是其他厂商也有实作Kerberos，这引发一个问题，Microsoft的版本与其他厂商产品的互通性好吗？最理想的答案是，只要Microsoft与其他厂商都遵循Kerberos第五版的官方标准RFC 1510，所有产品应该可以毫无困难地互通。很不幸地，事情没这麽简单。</span><span id=Layer229></font></p><p><font size=2 color=#3c3c3c face=arial>想要各厂商的Kerberos可以互通需要花些工夫</span><span id=Layer230></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>想要各厂商的Kerberos可以互通需要花些工夫</span><span id=Layer231></font></p><hr><p><font size=2 color=#3c3c3c face=arial>首先，前面已经说过Windows 2000 Kerberos预设使用RC4加密。不过，因为Microsoft也支援DES，所以这不是问题。在与非Microsoft Kerberos实作交谈时，Windows 2000 Kerberos会乐於协商使用DES来取代RC4（将特定的帐号设定为使用DES当作预设加密演算法是可能的，这使得协商过程更有效率）。</span><span id=Layer232></font></p><p><font size=2 color=#3c3c3c face=arial>有时会用专有名词MIT Kerberos来称呼非Microsoft实作的Kerberos协定。</span><span id=Layer233></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>有时会用专有名词MIT Kerberos来称呼非Microsoft实作的Kerberos协定。</span><span id=Layer234></font></p><hr><p><font size=2 color=#3c3c3c face=arial>再回想一下，登入时，Microsoft Kerberos会使用预验资料，大部分的其他实作不会这麽做。然而，就像前面提过的，设定某个帐号以便Windows 2000网域控制站在登入时不要求预验资料是可能的。这让非Microsoft Kerberos实作的客户端可以成功地取得来自Windows 2000 Kerberos伺服器的TGT。</span><span id=Layer235></font></p><p><font size=2 color=#3c3c3c face=arial>一个更重大的问题起源於Windows 2000 Kerberos升级自Windows NT 4现行安全性协定，NTLM。就像Kerberos一样，NTLM也使用一个杂凑演算法由使用者密码衍生出秘密金钥。但是NTLM使用的演算法是MD4，而标准Kerberos使用的是MIT定义的string-to-key函数。将Windows NT 4升级到Windows 2000并不会强制使用者改变他们的密码，所以Microsoft的Kerberos也允许使用由MD4衍生出来的秘密金钥。网域管理员可以自行引发密码变更、或让新帐号使用MIT标准的string-to-key函数来衍生秘密金钥、甚至可以要求所欲内的所有使用者改变密码。除非这麽做，不然Windows 2000 Kerberos不能与其他厂商的产品互通，因为它使用不同的演算法来把密码转换为秘密金钥。选择支援MD4，Microsoft使得绝大多数的事情变得简单－升级一个已存在的网域不需要使用者更新密码－而要互通成为可能就必须做一些额外的工作。</span><span id=Layer236></font></p><p><font size=2 color=#3c3c3c face=arial>预设情况下，Windows 2000 Kerberos使用非标准方法将密码杂凑为金钥</span><span id=Layer237></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>预设情况下，Windows 2000 Kerberos使用非标准方法将密码杂凑为金钥</span><span id=Layer238></font></p><hr><p><font size=2 color=#3c3c3c face=arial>还存在着另一个重要问题：如图3-5所示，每张Kerberos ticket都有包含一个授权资料（Authorization Data）栏位。在Windows 2000 Kerberos实作，这个栏位包含使用者的SID以及更多资讯。然而，其他的实作用这个栏位传送其他的资讯，因为RFC 1510并未定义它的内容应该是什麽。因为伺服端系统能利用授权资料栏位做存取控制的决定（例如，Windows 2000将它的SID与ACL做比较），它的里面是什麽是很要紧的事。</span><span id=Layer239></font></p><p><font size=2 color=#3c3c3c face=arial>Kerberos标准并未定义授权资料栏位里要送些什麽</span><span id=Layer240></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>Kerberos标准并未定义授权资料栏位里要送些什麽</span><span id=Layer241></font></p><hr><p><font size=2 color=#3c3c3c face=arial>图3-11展示一个可能的情节。假设在非Windows 2000 Kerberos领域的客户端想要存取执行在Windows 2000网域内之机器上的应用程式，称为伺服端V。就像任何跨网域存取所要做的，客户端可以向它的KDC要求一张到外面KDC的TGT，在这里是Windows 2000 KDC。假如这两个网域有信任关系，那麽TGT会被同意，而允许使用者要求一张到伺服端V的ticket。客户端接着呈交这张ticket给伺服端V以验证使用者。</span><span id=Layer242></font></p><br><center><a target=_new href=imagesh/3-11.gif><img border=0 src='imagesl/3-11.gif'></a></center></span><span id=Layer243><center><table border=0 ><td align=center><font color=#3c3c3c face=arial size=2><font size=2 face=arial color=#3e80d7><b> 图3-11</span><span ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -