投递文章投递文章 投稿指南 RSS订阅RSS订阅

IIS的各种身份验证详细测试

来源:cnBLOGs 发布时间:2007-11-20 收藏 投稿 字体:【

一、  IIS的身份验证概述

IIS具有身份验证功能,可以有以下几种验证方式:

1、 匿名访问

这种方式不验证访问用户的身份,客户端不需要提供任何身份验证的凭据,服务端把这样的访问作为匿名的访问,并把这样的访问用户都映射到一个服务端的账户,一般为IUSER_MACHINE这个用户,可以修改映射到的用户:

clip_image001

2、 集成windows身份验证

这种验证方式里面也分为两种情况

2.1.    NTLM验证

这种验证方式需要把用户的用户名和密码传送到服务端,服务端验证用户名和密码是否和服务器的此用户的密码一致。用户名用明码传送,但是密码经过处理后派生出一个8字节的key加密质询码后传送。

2.2.    Kerberos验证

这种验证方式只把客户端访问IIS的验证票发送到IIS服务器,IIS收到这个票据就能确定客户端的身份,不需要传送用户的密码。需要kerberos验证的用户一定是域用户。

每一个登录用户在登录被验证后都会被域中的验证服务器生成一个票据授权票(TGT)作为这个用户访问其他服务所要验证票的凭证(这是为了实现一次登录就能访问域中所有需要验证的资源的所谓单点登录SSO功能),而访问IIS服务器的验证票是通过此用户的票据授权票(TGT)向IIS获取的。之后此客户访问此IIS都使用这个验证票。同样访问其他需要验证的服务也是凭这个TGT获取该服务的验证票。

下面是kerberos比较详细的原理。

Kerberos原理介绍:

工作站端运行着一个票据授权的服务,叫Kinit,专门用做工作站同认证服务器Kerberos间的身份认证的服务。

1.        用户开始登录,输入用户名,验证服务器收到用户名,在用户数据库中查找这个用户,结果发现了这个用户。

2.        验证服务器生成一个验证服务器跟这个登录用户之间共享的一个会话口令(Session key),这个口令只有验证服务器跟这个登录用户之间使用,用来做相互验证对方使用。同时验证服务器给这个登录用户生成一个票据授权票(ticket-granting ticket),工作站以后就可以凭这个票据授权票来向验证服务器请求其他的票据,而不用再次验证自己的身份了。验证服务器把{ Session key ticket-granting ticket }用登录用户的口令加密后发回到工作站。

3.        工作站用自己的口令解密验证服务器返回的数据包,如果解密正确则验证成功。解密后能够获得登录用户与验证服务器共享的Session key和一张ticket-granting ticket

 

到此,登录用户没有在网络上发送口令,通过验证服务器使用用户口令加密验证授权票的方法验证了用户,用户跟验证服务器之间建立了关系,在工作站上也保存来相应的身份证明,以后要是用网络中的其他服务,可以通过这个身份证明向验证服务器申请相应服务器的服务票,来获得相应服务身份验证。

 

4.        如果用户第一次访问IIS服务器,工作站的kinit查看本机上没有访问IIS服务器的验证票,于是kinit会向验证服务器发出请求,请求访问IIS服务的验证票。Kinit先要生成一个验证器,验证器是这样的:{用户名:工作站地址}用跟验证服务器间的Session key加密。Kinit将验证器、票据授权票、你的名字、你的工作站地址、IIS服务名字发送的验证服务器,验证服务器验证验证授权票真实有效,然后用跟你共享的Session key解开验证器,获取其中的用户名和地址,与发送这个请求的用户和地址比较,如果相符,说明验证通过,这个请求合法。

5.        验证服务器先生成这个用户跟IIS服务器之间的Session key会话口令,之后根据用户请求生成IIS服务器的验证票,是这个样子的:{会话口令:用户名:用户机器地址:服务名:有效期:时间戳},这个验证票用IIS服务器的密码(验证服务器知道所有授权服务的密码)进行加密形成最终的验证票。最后,验证服务器{会话口令+加好密的验证票}用用户口令加密后发送给用户。

6.        工作站收到验证服务器返回的数据包,用自己的口令解密,获得跟IIS服务器的Session keyIIS服务器的验证票。

7.        工作站kinit同样要生成一个验证器,验证器是这样的:{用户名:工作站地址}用跟IIS服务器间的Session key加密。将验证器和IIS验证票一起发送到IIS服务器。

8.        IIS服务器先用自己的服务器密码解开IIS验证票,如果解密成功,说明此验证票真实有效,然后查看此验证票是否在有效期内,在有效期内,用验证票中带的会话口令去解密验证器,获得其中的用户名和工作站地址,如果跟验证票中的用户名和地址相符则说明发送此验证票的用户就是验证票的所有者,从而验证本次请求有效。

3、 基本身份验证

这种验证方式完全是把用户名和明文用明文(经过base64编码,但是base64编码不是加密的,经过转换就能转换成原始的明文)传送到服务端验证。服务器直接验证服务器本地是否用用户跟客户端提供的用户名和密码相匹配的,如果有则通过验证。

 

二、  匿名访问

服务端IIS设置了允许匿名访问后,在收到客户端的资源请求后,不需要经过身份验证,直接把请求的资源返回给客户端。

GET /iisstart.htm HTTP/1.1

Accept: */*

Accept-Language: zh-cn

UA-CPU: x86

Accept-Encoding: gzip, deflate

If-Modified-Since: Fri, 21 Feb 2003 12:15:52 GMT

If-None-Match: "0ce1f9a2d9c21:d87"

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; MAXTHON 2.0)

Host: 192.168.100.5

Connection: Keep-Alive

 

HTTP/1.1 200 OK

Content-Length: 1193

Content-Type: text/html

Last-Modified: Fri, 21 Feb 2003 12:15:52 GMT

Accept-Ranges: bytes

ETag: "0ce1f9a2d9c21:d8b"

Server: Microsoft-IIS/6.0

MicrosoftOfficeWebServer: 5.0_Pub

X-Powered-By: ASP.NET

Date: Mon, 12 Nov 2007 07:29:40 GMT

 

三、  Windows集成验证

集成 Windows 身份验证可以使用 NTLM Kerberos V5 身份验证,当 Internet Explorer 试图设为集成验证的IIS的资源时,IIS 发送两个 WWW 身份验证头,Negotiate NTLM

客户端IE认识Negotiate头,将选择Negotiate头,之后IE可以选择NTLM Kerberos两种验证方式。

如果客户端不认识Negotiate头,只能选择NTLM头,就只能使用NTLM验证方式。

现在IE使用的版本一般都在5.0以上,所以现在可以认为IE客户端都能识别Negotiate 头。

所以本文只考虑IE接受Negotiate头,分别使用NTLM Kerberos两种验证的情况。

 

1、 NTLM验证过程

1.1.    客户端选择NTLM方式

如果IE选择了NTLM验证,IE就会在发送到IIS的请求中加入一个Authorization: Negotiate头,内容为:

Authorization: Negotiate NTLMSSPXXXXXXXXXXXXXXXXX

蓝色部分在实际中是经过base64编码的,其中“NTLMSSP”表示是NTLM验证的请求,后面的“XXXXXXXX”部分是二进制的数据,告诉服务器,客户端现在选择了NTLM验证,请服务器发送质询码给客户端。

1.2.    服务端返回质询码

服务器在返回无授权访问的http回应的头部加入Authorization: Negotiate头,内容为:

Authorization: Negotiate NTLMSSPXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

服务器返回的“XXXXXXXX”部分中含有一个八字节的质询码。

1.3.    客户端加密质询码再次发送请求

客户端使用客户端帐号的密码派生出来的8字节DESkey使用DES算法加密收到的质询码。连同客户端帐号的用户名发送到服务端,形式还是这样:

Authorization: Negotiate NTLMSSPXXXXXXXXXXXXXXXXX

这里的“XXXXXXX”部分包含了加密后的质询码和客户端用户名,用户名在其中以明码形式存在。

1.4.    服务端验证客户端用户和密码

服务端收到用户名后,先查验本机是否有这个用户,如果没有直接返回没有授权的http回应。

如果有这个用户,就用这个用户的密码派生出来的8字节DESkey使用DES算法加密发给客户端的那个8字节的质询码,然后跟收到客户端发送来的加密后的质询码比较,如果不相同,表示客户端输入密码不正确看,返回没有授权的http回应;如果相同,就表示客户端输入这个用户的密码正确,验证通过,返回客户端请求的资源。

 

2、 Kerberos验证过程

2.1.    客户端选择Kerberos验证

如果客户端选择了Kerberos验证,客户端直接在请求头中加入Authorization: Negotiate头,内容为:

Authorization: Negotiate XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

其中“XXXXXXXXXX”包含了客户端登录用户的身份验证票(登录时域中的票据服务器发放的标识此登录用户身份的票据,其中不包含用户的密码)。

2.2.    服务端验证身份验证票

服务器验证用户验证票,如果有效的票据,服务端能据此获得用户的用户名,并验证用户的有效性。验证通过后,服务端返回客户端请求的资源。

 

但是客户端IE何时选择NTLM 、合适选择Kerberos呢?下面通过一系列的测试来找出答案。

 

分服务器和客户端在域不在域两种情况测试。

 

3、 客户端和服务器都不在域中

测试环境为服务器和客户端机器在同一个局域网中,但是都不在域中。客户端IE请求服务端IIS的一个页面default.aspx

顶一下
(1)
100%
踩一下
(0)
0%
本文Tags:
  • 表情:
  •    
  • 评价:
用户名: 密码: 匿名 注册
最新评论 查看所有评论
About iTtang - 联系我们  - 专题列表 - 友情链接  -  高级搜索  -  帮助中心  -  您的意见