根据http协议对状态码的定义，401表明未经受权的访问。在IIS中在401的基础上定义了一系列的子状态码来表明各类不一样状况下未经受权访问的具体缘由。
html
401.1 - Logon failed.-登录失败windows
401.2 - Logon failed due to server configuration.-基于服务器配置的登录失败浏览器
401.3 - Unauthorized due to ACL on resource.-资源访问控制列表返回未受权安全
401.4 - Authorization failed by filter.-服务器filter返回未受权服务器
401.5 - Authorization failed by ISAPI/CGI application.-服务器ISAPI/CGI返回未受权架构
这篇文章中主要来介绍各类常见401错误的重现方法相应的解决方案。在这以前首先介绍一下对于401问题的定位方式，即如何知道发生了401错误。app
401问题的定位方式
对于401问题的定位咱们要区分咱们是在客户端仍是在服务器端访问页面，由于服务器对于错误返回消息的配置不一样使咱们在浏览器中看到的结果截然不同。dom
客户端对于401问题的定位
在客户端咱们遇到401问题时常常会见到的页面以下，这是一个IIS 7及以上版本的默认401错误页面。ide
服务器也能够配置使用不一样的错误页面来呈现这个问题。因此更为精确的定位方式咱们仍是要参考服务器返回的状态码。
工具
在IE中打开F12开发者工具，切换到network选项卡，而后点start capturing。访问该网页，抓取的network追踪记录中就能够看到401的返回码。
服务端对于401问题的定位
在服务器端访问出错页面的结果以下，通常默认配置状况下服务器会显示详细的错误信息。
另外咱们也能够经过查看IIS日志来肯定详细的出错码。
打开IIS - Loggingfeature，注意须要肯定SelectFields中选中了Protocal Status和Protocal Substatus (默认状况下是选中的)。
而后到日志记录中查找相应的请求记录，从而肯定返回状态码与子码分别是什么。
#Software:Microsoft Internet Information Services 8.0
#Version:1.0
#Date:2012-10-05 04:34:24
#Fields:date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ipcs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken
2012-10-0504:34:24 ::1 GET /iisstart.htm - 80 - ::1Mozilla/5.0+(compatible;+MSIE+10.0;+Windows+NT+6.2;+WOW64;+Trident/6.0) -401 2 5 753
401.1 - Logon Failed
问题重现
401.1问题通常是由于用户名和密码没法在服务器经过认证致使。要重现这个问题能够在服务器禁用匿名访问方式。启用basic认证方式。
再次访问页面，就会弹出以下须要输入用户名和密码的对话框。
若是三次输入的用户名和密码出错的话，你就会获得这样一个页面
若是是服务器端详细的信息是这样的
解决方案
这种问题通常发生的缘由就是用户名和密码不正确。能够尝试重置用户密码或经过另一个用户登录来定位是不是用户名密码的问题。
另外还有一种较为常见的在服务器的应用程序池运行在一个本地或者域帐户的状况下，由于kerberos认证失败而致使401.1错误。这种问题的解决办法能够参照这里。
401.2 - Logon failed due to server configuration
问题重现
401.2问题通常是由于服务器配置缘由致使的，好比最多见的服务器启用了基于401Challenge的认证方式，那么客户端尝试发送匿名请求给服务器，服务器就会返回401 Challenge给客户端，客户端受到这个回复以后就会弹出认证对话框，如上面重现401.1问题时的认证对话框。而这个401Challenge请求在服务器日志里面会记录成401.2。
因此当在日志中发现下面这种401.2错误的时候不用担忧，由于能够看到用户名为空的请求返回了401.2，以后又有带了用户名的请求返回了200(请求成功)。
2012-10-0507:26:40 ::1 GET /iisstart.htm - 80 - ::1Mozilla/5.0+(compatible;+MSIE+10.0;+Windows+NT+6.2;+WOW64;+Trident/6.0) -401 2 5 7
2012-10-0507:27:08 ::1 GET /iisstart.htm - 80 - ::1Mozilla/5.0+(compatible;+MSIE+10.0;+Windows+NT+6.2;+WOW64;+Trident/6.0) -401 2 5 8
2012-10-0507:27:26 ::1 GET /iisstart.htm - 80domain\user1::1Mozilla/5.0+(compatible;+MSIE+10.0;+Windows+NT+6.2;+WOW64;+Trident/6.0) - 200 0 0 409
另一种401.2的重现方式很是简单，是把全部的认证方式所有禁用，再次访问网页就会返回401.2错误消息。在第一节问题通常定位方式截图中显示的401.2错误就是把全部的认证方式禁用获得的。
第三种方式比较特殊，咱们能够经过服务器端配置authorization rule来禁止或者容许特定的用户访问。为了重现问题咱们禁用全部的用户。
访问网页以后发现返回401.2错误，在服务器详细错误中在这里咱们要关注的一点是Module中显示的信息，这里咱们能够看到是UrlAuthorizationModule，而不是前面禁用了全部认证方式的IISWeb Core，这就告诉咱们出错的地方在于配置的的Authorization Rules。
解决方案
第一种状况属于正常现象，不是问题
第二种状况即没有启用任何认证方式，只须要在IIS Manager里面启用须要的认证方式便可。
第三种状况即被Authorization Rule阻挡，则须要分析这个authorization rule是不是否必须来决定对他的更改。
还有第四种状况，就是在配置文件中指定了认证方式可是相应的认证模块没有安装。这种状况多发生在系统迁移的过程当中。解决方案就是把相应的认证模块安装上。
401.3 - Unauthorized due to ACL on resource
问题重现
401.3问题是最明显的一个，即没有权限访问文件(夹)，要重现这个问题咱们能够将要访问的文件的安全性设置为拒绝任何人访问。而后请求该文件就会获得如下出错信息。
在这里须要关注的错误显示的Logon User，这样能够知道你正在以什么身份访问文件。
解决方案
调试401.3须要知道两件事，
第一是什么资源组织了访问，问题出在上级文件夹仍是文件自己。
第二是咱们以什么样的身份访问资源的时候被阻止了。
调试这个问题最好的工具是Process Monitor。打开Process Monitor过滤w3wp进程对文件的访问。就能够看到access deny被记录下来。同时还有访问身份信息。这样咱们就能够在文件系统作相应的更改来解决问题。
401.4 - Authorization failed by filter
问题重现
401.4问题重现比起前面要更加费些周折，由于这个错误的意思是自定义filter返回了拒绝访问的错误。因此咱们要先建立一个自定义filter。
这里值得注意的是在IIS6上只能建立自定义ISAPI Filter来处理进入的各类请求，建立ISAPI Extension来处理特定的请求。而这两种扩展方式在IIS7及以上的版本再也不被推荐使用，取而代之的是建立Http Module和HttpHandler来扩展IIS的功能，并且支持托管和非托管两种模式，开发和调试都更加方便。
为了更形象的重现这个问题，咱们仍是采用ISAPI Filter的方式。建立ISAPI Filter须要两个文件。
401-4-Filter.def
LIBRARY 401-4-Filter
;DESCRIPTION 'filter to return 401.4'
EXPORTS
HttpFilterProc
GetFilterVersion401-4-Filter.C
#include
#include
#define DEFAULT_BUFFER_SIZE 1024
#define MAX_BUFFER_SIZE 4096
DWORD
OnPreprocHeaders(
IN HTTP_FILTER_CONTEXT * pfc,
IN HTTP_FILTER_PREPROC_HEADERS * pPPH
);
BOOL
WINAPI
GetFilterVersion(
HTTP_FILTER_VERSION * pVer
)
{
pVer->dwFilterVersion = HTTP_FILTER_REVISION;
lstrcpyn( pVer->lpszFilterDesc,
"Filter to return 401.4 error",
SF_MAX_FILTER_DESC_LEN );
pVer->dwFlags =
SF_NOTIFY_ORDER_HIGH |
SF_NOTIFY_PREPROC_HEADERS
;
return TRUE;
}
DWORD
WINAPI
HttpFilterProc(
IN HTTP_FILTER_CONTEXT * pfc,
DWORD dwNotificationType,
LPVOID pvNotification
)
{
switch ( dwNotificationType )
{
case SF_NOTIFY_PREPROC_HEADERS:
return OnPreprocHeaders(
pfc,
(HTTP_FILTER_PREPROC_HEADERS *) pvNotification );
}
return SF_STATUS_REQ_NEXT_NOTIFICATION;
}
DWORD
OnPreprocHeaders(
HTTP_FILTER_CONTEXT * pfc,
HTTP_FILTER_PREPROC_HEADERS * pPPH
)
{
SetLastError( ERROR_ACCESS_DENIED );
return SF_STATUS_REQ_ERROR;
}
将其编译成与application pool CPU架构(x86|x64)相同的classlibrary。而后经过IIS Manager功能视图中ISAPI Filter中加入编译产生的Dll。以后请求页面就会获得以下返回。
解决方案
能够看到详细信息中并无显示出出问题的模块，这里就须要咱们经过必定的调试手段来定位这个出错的模块在哪里。比较方便的方式是经过failed request tracing追踪请求，找到出错的模块。
详细的方法能够参考这里
401.5 - Authorization failed by ISAPI/CGI application
问题重现
401.5问题的出现缘由可能源于如下几个方面阻止了请求。
自定义的ISAPIextension
CGI程序
ASP页面
自定义handler
这里经过一个managedhttp handler来重现这个问题，将如下代码放在网站根目录下App_Code文件夹，而后在IISManager功能视图里选在Handler Mapping，添加Managed Handler，选择一个对应的请求路径，咱们这里用它来处理全部*.aa的文件请求，以后在网站里面加入一个test.aa文件，经过浏览器发送请求。
using System.Web;
namespace 4015Handler
{
public class 4015Handler: IHttpHandler
{
public bool IsReusable
{
get { return true; }
}
public void ProcessRequest(HttpContext context)
{
context.Response.StatusCode = 401;
context.Response.SubStatusCode = 5;
context.Response.End();
}
}
}
就会获得这样的结果。
解决方案
对于这个问题的定位方式与401.4同样，能够经过failedrequest tracing来跟踪消息，找到出错的模块。
详细方法以下
3360
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
