IIS 操作失败诊断指南
作者：gbnis
介绍
自己辛辛苦苦建起来的网站无法访问，的确令人沮丧。不过别担心，本文将会指导你找到故障的根源。
操作失败的可能因素
大多数操作失败的原因不外乎下列几种：网络连接故障，防火墙设置不当，IIS 权限问题。一般而言，网络故障容易发现。举例来说, 如果你的网络不能传输任何数据，那么问题极有可能出在网络硬件上。如果本地网络正常，从外面却不能访问你的网站，那么就该查查端口80是不是被防火墙禁止了，只要作个简单的端口扫描(port sniffing)就明确了。
我打算根据人们对本文的回应情况重新撰写一篇完整的故障诊断指南。然而本文仅仅讨论由于权限问题引起的 IIS 的操作失败。
建立安全日志
IIS 连接故障的诊断，第一步是对故障的现象有个清楚的了解。此时经常需要查看你的事件日志。然而，你得先做一些设置，否则事件日志里的信息对你毫无用处。
既然这里讨论的是与权限有关的 IIS 操作故障，那么我们势必要用到安全日志。因此先得重新配置安全日志：告诉 IIS 我们要记录什么，然后停止 IIS ，再清空安全日志，最后重新启动 IIS 服务。也许你会奇怪：为什么要停止 IIS 服务？因为 IIS 有时把安全日志记录写入 cache (缓存)。如果不重新启动 IIS ，那么当你清空日志以后，cache 中的记录马上又会被写入。很明显，这种信息将被误认为当前记录而将你引入歧途。因此，我强烈推荐停止并重新启动 IIS 服务。
现在开始设置 IIS。首先，进入 Program | Administrative Tools | Computer Management。然后，找到Services and Applications | Internet Information Services。展开 Internet Information Services 项显示网站。在有问题的网站名称上点右键，选取 Properties 打开属性页，现在，点属性页中的 Web Site 项，选中 Enable Logging 项以开启日志。此时，你会看到一个列表让你选择日志文件格式。我推荐使用 W3C Extended 格式，点 Properties 按钮，选 Extended Logging Properties (扩展日志属性页)。
默认情况下，属性页中的 General Properties (一般属性) 已被选中。在这里可以设定隔多久产生新的记录文件，这个值的大小无所谓，自己选吧。扩展属性页比较重要。在这里你可以选择哪些信息需要保存到日志里。你可以自由选择，但是至少应该包括如下几项：
Date (日期)，Time (时间)，Client IP Address (客户 IP 地址),User Name (用户名)，Method (方法)，HTTP Status (HTTP 状态)和 Win32 Status (Win32 状态)。
选择完毕以后，点 OK ，再点 OK ，就可以回到计算机管理界面了。
既然已经配置好了网站记录选项，我们就来清空cache (高速缓存) 和日志记录吧。第一步：停止所有的 IIS 服务。方法是：进入 DOS 命令提示方式(Program | Accessories | Command Prompt)，在 DOS 提示窗口中键入命令：
NET STOP IISADMIN/Y
只需这一个命令就能停止所有的 IIS 服务。完成后，离开 DOS 提示窗口，进入 Programs | Administrative tools | Event Viewer (事件查看器)。在 Security Log (安全日志) 上点右键，选 Clear All Events (清除所有事件)。好，现在已经清空了 cache 和安全日志，可以重起 IIS 了。回到 DOS 提示窗口，键入4行命令：
NET START W3SVC
NET START MSFTPSVC
NET START NNTPSVC
NET START SMTPSVC
注意了，这些命令不是对每个人都需要的。例如，举例来说，如果你没有运行 FTP 服务,那么你就不必键入与 FTP 有关的命令(译者注：W3SVC - WEB ，MSFTPSVC - FTP，NNTPSVC - NNTP，SMTPSVC - SMTP)。
检查安全日志
现在你已经设置好了安全日志，可以创建日志项了。试着访问有故障的网站。我建议，如果可能的话，尝试从公司内部和外部，从许多人的机器上访问它。因为这样可以得到许多有用的日志记录，通过对它们的比较分析可以大大帮助找出问题的根源。也许，你会发现只有从公司内部能够访问，而从外部不行；或者，只有授权用户能够访问，而匿名用户不行。等等。
当你整理安全日志项目时，我推荐你首先看看错误代码为 401 和 403 的日志项目。代码为 401 和 403 的错误有很多。但是一旦有了确切的代码，你就得到了极为重要的线索。下面列出许多 401 和 403 错误及其含义：
401;1 非法操作：登录失败
401;2 非法操作：服务器设置错误导致的登录失败
401;3 非法操作：使用控制列表 (ACL) 项目
401;4 非法操作：IIS 过滤器阻止存取
401;5 非法操作：ISAPI 或 CGI 应用程序
403;1 操作禁止：没有执行权限
403;2 操作禁止：没有读取权限
403;3 操作禁止：没有写入权限
403;4 操作禁止：要求 SSL
403;5 操作禁止：要求 128位 SSL
403;6 操作禁止：IP 地址被拒绝
403;7 操作禁止：要求客户证书
403;8 操作禁止：拒绝存取站点
403;9 操作禁止：当前连接的用户太多
403;10 操作禁止：设置错误
403;11 操作禁止：密码不正确
403;12 操作禁止：要求有效的客户证书
403;13 操作禁止：客户证书已作废
403;14 操作禁止：拒绝列目录
403;15 操作禁止：超过许可的客户数目
403;16 操作禁止：客户存取证书非法或尚未认证
403;17 操作禁止：客户存取证书过期或尚未升效
试试看，从你的安全日志中找到 401 和 403 错误，跟上述列表对照一下，或许能有帮助呢？如果还是没找到原因，请看下一节。那里将讨论特殊的权限问题和解决办法。
连接失败的其他可能因素
如果问题还是没有解决，那么就要考虑 IIS 的提示信息是否正确了。特别是当你的 ASP 代码中有 <!-- #include --!> 时更要小心了。
举个例子，假设你在访问 DEFAULT.ASP 遇到了 access denied (拒绝操作)错误。有一种可能是，你确实有访问 DEFAULT.ASP 的权限，但是没有访问它所 include (引用)的其它页面的权限。比如：DEFAULT.ASP 中引用 TOOLS.ASP，而 TOOLS.ASP 内有某种 ACL 区块，则你访问 DEFAULT.ASP 时当然会 access denied 了。本例中，DEFAULT.ASP 本身是正确的，但它包含的某个组件却有问题。IIS 不会直接调用它的组件，只会在包含组件的页面报告错误。于是在访问 DEFAULT.ASP 时就出错了。
幸运的是，要确定组件是不是操作失败的根源并不难：把所有 include 行都注释掉；如果问题消失，那么你就可以肯定问题出在某些组件上了；然后, 把 include 行逐个恢复，恢复一个就访问一次网页，观察一次提示信息。如此就能很快确定是哪一行引起的问题了。
检查你的帐户
还有一个故障诊断技术是：从安全日志中查看访问网页时用的是哪个帐号。也许出于某种原因，用了不恰当的帐号来访问网站。如果是这样，就容易解释为什么会出现 access denied 了。即使找到的是正确的帐号，你也能确定用的是哪个帐号。这样你就可以自信地检查该帐户的 ACL 了，因为你已经知道问题在哪了。
检查帐户的权限时,还有一些注意事项。比如，帐户必须对网站及其子目录所在的文件夹有 NTFS 级访问权限。类似地，你也要检查该帐户是否有本地登录或远程登录权限。
料想不到的错误
偶然地，使用者可能需要被设为只读权限，但是你却得到错误信息说用户需要写入或删除权限。通常，如果这些意外错误发生在一个新网站时，并不代表你的系统有安全漏洞。它可能仅仅是因为网页上的某些组件需要写入或删除权限。计数器就是一个例子。
匿名访问
绝大多数网站使用匿名访问。也就是说，使用者不必输入帐号和密码。然而，为了安全起见，身份验证仍然在进行，只是用户看不见而已。匿名访问的原理是使用网站上的某个特定帐户。使用匿名访问时，该帐号必须存在，拥有合法的密码，尚未过期，而且未被删除。其余的标准安全机制也在进行，比如：帐户的 ACL 或指定登录时长等。
为了确定用于匿名访问的帐号，你可以在计算机管理界面的 virtual server (虚拟服务器)上点右键，选取 Properties 即可。当属性页出现时，点 Directory Security (目录安全)，在其中的 Anonymous Access and Authentication Control (匿名操作和验证控制)栏点 Edit 按钮。此时会出现 Authentication 对话框。确定 Anonymous Access 项已被选中，然后点 Edit 按钮就可以看到是哪一帐户被使用。
结论
我们看到，IIS 的权限及其相关的故障是复杂多变的。但是，利用合理的方法来追查问题的根源，你就能够轻松地解决它们。 http://netadmin.77169.com/HTML/20031203155800.html
关注我们
