📄 210002.htm
字号:
<html><body><span id=Layer1><a name=210002><font color=#3e70d7 face=arial size=5><b>IIS基础概论</span><span id=Layer2></b></font><p><font size=2 color=#3c3c3c face=arial>就像其他伺服器的功能一样，IIS是设计来接受并处理HTTP的要求，然後回传结果。就先前描述，处理一个要求可能需要IIS直接读取HTML档案，然後将它的内容传回，或可能需要将要求（request）传送到某些应用程式。IIS并不是支小程式，因此在此有许多有趣的话题可供讨论。其中有两项特别切题：虚拟目录与IIS验证。</span><span id=Layer3></font></p><font color=#3e72d7 face=arial size=4><b>虚拟目录</span><span id=Layer4></b></font><p><font size=2 color=#3c3c3c face=arial>当一个浏览器将一个URL当成要求的一部份传送时，IIS必须使用某种方法将URL对映到这个URL指定的元素。虽然可以在URL中使用完整的档案路径名称以达成这个目的，这个结果并不吸引大部份的使用者。为了要使用简单一点的URL，IIS定义了虚拟目录的概念（也称为虚拟根目录）。一个虚拟目录不过就是档案系统中一个真正目录的别名罢了，它主要的目的就是让客户端看到的URL能够简短一些。IIS的嵌入单元，Internet Services Manager，可用来将一个特定的实体目录指定成一个虚拟目录，然後指定一个名称。一旦这个工作完成後，从浏览器传入的URL便能够包含虚拟目录的名称，IIS将会自动对应到虚拟目录的真正路径所在。IIS 5.0并非如前版将这个对照表储存在系统登录，而是储存在IIS metabase中，它是大部份IIS组态资讯的储存地方。</span><span id=Layer5></font></p><p><font size=2 color=#3c3c3c face=arial>虚拟目录对应到档案系统中的实际路径，可让URL的名称变短一 些</span><span id=Layer6></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>虚拟目录对应到档案系统中的实际路径，可让URL的名称变短一 些</span><span id=Layer7></font></p><hr><p><font size=2 color=#3c3c3c face=arial>举例来说，假设QwickBank选择将一群HTML档案储存在关联到www.qwickbank.com这台机器上的c:\inetpub\marketing\information目录。使用Internet Services Manager，则QwickBank的网站管理者便能够建立一个称为info的虚拟目录，然後将之关联到c:\inetpub\marketing\information。若客户端对这台机器发行一个要求，URL为http://www.qwickbank.com/info/newcust.htm，IIS将会将URL中的虚拟目录名称「info」对照到它关联的c:\inetpub\marketing\information，然後检视这个目录中的newcust.htm。</span><span id=Layer8></font></p><font color=#3e72d7 face=arial size=4><b>IIS中的验证</span><span id=Layer9></b></font><p><font size=2 color=#3c3c3c face=arial>就如同可透过远端存取的任何伺服器应用程式一样，IIS通常得知道它的使用者是谁。换句话说，它需拥有某些验证使用者的方式。IIS能设定以许多不同的方式来达到这个目的，并可以同时在不同的客户端上使用不同的验证机制。</span><span id=Layer10></font></p><p><font size=2 color=#3c3c3c face=arial>IIS支援许多验证的选项</span><span id=Layer11></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>IIS支援许多验证的选项</span><span id=Layer12></font></p><hr><p><font size=2 color=#3c3c3c face=arial>这些选项包含：</span><span id=Layer13></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> 匿名存取验证</span><span id=Layer14> </b></font>（</span><span id=Layer15><font size=2 face=arial color=#3e80d7><b> Anonymous authentication</span><span id=Layer16> </b></font>） 并不执行验证使用者的动作。取代的方法是将每个使用者对应到Windows 2000中相同的一个使用者帐号，这个帐号被授权存取任何的HTML档案、ISAPI DLL或ASP网页。</span><span id=Layer17></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> 基本验证</span><span id=Layer18> </b></font>（</span><span id=Layer19><font size=2 face=arial color=#3e80d7><b> Basic authentication</span><span id=Layer20> </b></font>） IIS要求使用者帐号输入与密码，然後在网路中进行传输。若是透过HTTP发出要求，这也就是说，若HTTP搭配SSL使用，则这个资讯将会使用标准的SSL机制进行加密，如</span><span id=Layer21> <a target='_new' href=204.htm#>第四章</span><span id=Layer22></a> 所描述。若没有搭配SSL，则传送未经加密的资讯。</span><span id=Layer23></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> 摘要式Windows网域伺服器验证</span><span id=Layer24> </b></font>（</span><span id=Layer25><font size=2 face=arial color=#3e80d7><b> Digest authentication</span><span id=Layer26> </b></font>） 摘要式Windows网域伺服器验证和基本验证一样，依赖客户端所提供的使用者名称与密码。然而与基本验证不同的地方在於这些资讯并非以明码方式在网路上传递。取代的做法，将使用者帐号、密码与timestamp，和一些其它的资讯连结在一起。这些资讯采用MD5杂凑（hash）演算法重新产生一个新的值，然後传送到IIS。因为IIS知道客户端的密码，timestamp与任何客户端用来产生这个hash的值，它便可以计算出相同的hash值。若客户端与伺服器都使用相同的密码，则伺服器计算出来的hash值就会符合客户端传送过来的hash值，那麽验证的动作就成功了。不过，若它们使用不同的密码，则计算出来的hash值就不会相符，验证就会失败。因为密码也是hash过的部份资讯，而密码从不会使用明码的方式在网路上传送，所以客户端仍旧依赖它的密码来验证自己。这样的过程让摘要式Windows网域伺服器验证比起基本验证的方式更安全更有意义。</span><span id=Layer27></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> 整合的Windows验证</span><span id=Layer28> </b></font>通常使用在内部网路（intranet），而非应用在公用的网际网路。这个选项允许IIS与浏览器进行协商，然後选择使用Kerberos或NTLM来做为验证的协定。这个解决方案只能配合Internet Explorer使用，而只有Internet Explorer 5.0以上版本支援Kerberos，而早期的版本只支援NTLM。同时注意一下，Kerberos允许委派（delegation） 能将验证要求安全地从IIS传送到其它台机器的能力。而NTLM是无法达到这个要求的。</span><span id=Layer29></li><br></font><font size=2 face=arial color=#3c3c3c><li><font size=2 face=arial color=#3e80d7><b> SSL</span><span id=Layer30> </b></font>如同</span><span id=Layer31> <a target='_new' href=204.htm#>第四章</span><span id=Layer32></a> 描述，IIS依赖SChannel security service provider （SSP） 来实作SSL。回顾起SSL使用证书（certificate）与数位签章（digital signature） 验证伺服器的识别给客户端，若客户端拥有private key与证书，则SSL也可以用来验证客户端。</span><span id=Layer33> <a target='_new' href=204.htm#>第四章</span><span id=Layer34></a> 描述如何使用Microsoft Certificate Service建构CA阶层，以便发行证书给信任这个阶层的人。不过SSL最常应用在公用的网际网路，而一般的客户端并不愿意信任其它组织内部CA发行的证书 （为何该信认呢？）。这样的结果是，IIS使用来向客户端表明正身的证书通常必需从公正的CA机构取得，如VeriSign、Thawte，或其它商业性的组织。若将IIS设定为可接受客户端的证书，则透过SSL交换时，客户端传送的签名就如</span><span id=Layer35> <a target='_new' href=204.htm#>第四章</span><span id=Layer36></a> 所描述的方式进行验证。举例来说，若发行客户端证书的CA，或证书验证链（certification chain） 中的根CA在IIS伺服器所在机器上的Trusted Root CA store自行签署证书，则在这个证书验证链中的所有证书都视为有效的。为了进行签名验证，客户端的证书将会被视为信任。</span><span id=Layer37></li><br></font></ul></font><p><font size=2 color=#3c3c3c face=arial>分散式的安全性从来就不是件容易的事。为了在不同的情况下，提供不同的需求，IIS提供许多选项。一般来说，使用最强健的验证机制是很好的也是很实际的，因为你可能想尽量提供最佳的安全性。否则，就不用烦恼了。</span>
</body></html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -