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

上一篇 / 下一篇 2008-01-25 07:07:19

查看( 77 ) / 评论( 1 ) / 评分( 1 / 0 )

一、 IIS的身份验证概述

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

1、匿名访问

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

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 key和IIS服务器的验证票。

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

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