如果只为一小部分已知用户开发 Web 程序，且这些用户都有 Windows 帐号，在这种情况下，Windows 验证是一个适合的解决方案。它可以利用已有的用户和用户分组信息进行系统验证。

       和表单验证不同，Windows 验证没有在 ASP.NET 中内置。Windows 验证将验证的责任交给了 IIS。IIS 通过浏览器验证 Windows 用户帐号的凭证。如果用户验证成功，IIS 则允许这次网页请求，并将用户和角色信息传递给 ASP.NET，这样你的程序就可以用几乎和表单验证一样的方式处理这些信息。

1. 为什么使用 Windows 验证？

• 对于开发，几乎不需要进行多少编程工作
• Windows 验证允许 IIS 和浏览器处理验证流程，你不需要创建登录页面、检查数据库或编写任何自定义代码，Windows 已经提供了基本的用户帐号功能，比如密码过期，密码锁定和用户分组。
• 允许使用已有的用户进行登录
• 通常，使用 Windows 验证时，用户是和 Web 服务器相同的本地网络或者企业内部互联网络的一部分。这就意味着你可以通过登录到计算机的凭证验证用户。最重要的是，根据你使用的配置和网络结构，你可以提供一个无需单独登录步骤的“隐藏”验证机制，浏览器只使用当前用户已登录的身份。
• 为多种类型的应用程序提供一个单独的验证模型
• 你可以为 Web 服务、ASP.NET 程序和基于 WCF 的服务使用相同的验证模型。Windows 验证可使你摆脱让身份信息在计算机彼此之间流动的痛苦工作。
• 允许使用身份模拟和 Windows 安全机制
• 例如，可以设置 Windows 的文件访问权限控制对文件的访问。但是要记住非常重要的一点，这些设置不会自动起作用。因为 Web 程序默认以一个固定的账户身份运行（IIS 7.x 通常是 Network Service），你可以谨慎的使用 Windows 验证 和身份模拟改变这一行为。

2. 为什么不使用 Windows 验证？

       Windows 验证有潜在的风险，Windows 用户帐号可能拥有对 Web 服务器或者其他网络内机器的权限。你不会冒险给网站用户授予这些权限吧？

       IIS 使用的一些验证的方法需要用户在他们的机器上有相应的软件。这使得使用非微软操作系统或没有 IE 浏览器的用户就无法使用它。

       Windows 验证没有给你任何对验证过程的控制。无法通过编程管理 Windows 账户信息，也无法储存用户特定的信息。

3. Windows 验证机制

       部署 Windows 验证时，IIS 有 3 种策略对它每次收到的请求进行验证。

• Basic 验证：用户名和密码以纯文本的格式传递。作为 HTML 标准的一部分，这是唯一被所有浏览器支持的验证模式
• Digest 验证：用户名和密码不传递，相反，一个已加密的安全地散列字符串被发送
• 集成 Windows 验证：用户名和密码不被传递。已登录到 Windows 系统的用户的身份被作为一个令牌自动传递。

3.1 Basic 验证

       支持最广泛的验证协议是 Basic 验证。客户端验证时，浏览器显示一个登录框用来输入用户名和密码。当用户提供了信息后，信息被传送到 Web 服务器，一旦 IIS 收到验证数据，它会使用相应 Windows 帐号来验证网站用户。

       Basic 验证的关键限制在于它是不安全的，至少它本身是不安全的。用户名和密码以纯文本格式传输，数据以 Base64 的形式编码(非加密)为字符串，网络窃听者可以非常容易的读取。

       只在安全的场合下使用 Basic 验证。比如，无需保护用户凭证信息的环境下，或和一个 HTTP 网络加密协议(如 SSL)捆绑时。

3.2 Digest 验证

       也需要用户通过浏览器显示的登录对话框提供帐号信息。但不同的是，Digest 验证传递密码的散列串，而不是密码本身，这样你没有使用 SSL 也可以防止密码被窃取。

       使用 Digest 验证用户的过程如下：

1. 未经验证的客户端请求一个受限的网页
2. 服务器返回一个 HTTP 401 响应。这个响应含有一个 nonce 值（一个随机生成的字符序列），Web 服务器发送 nonce 前会确保它的唯一性
3. 客户端使用这个 nonce、密码、用户名和其他一些值创建一个散列。散列串与纯文本的用户名一起被发回服务器
4. 服务器使用 nonce 值、为当前用户保存的密码及其他一些值创建一个散列串，然后与客户端发来的散列串匹配以确定验证成功与否

       对于每个验证请求，nonce 值都会变化，这确保了安全机制。但 IIS Digest 验证的一个限制是需要验证的虚拟目录必需在一个 Windows 活动目录域控制器上运行或者受其控制才能起作用。

3.3 集成 Windows 验证

       这个模式对于基于广域网或基于局域网的企业内联网应用程序是最方便的验证标准，它无需执行任何客户端的交互即可执行验证。当 IIS 要求客户端验证时，浏览器会发送一个代表当前用户的 Windows 账户身份的标志，但如果 Web 服务器无法使用这个信息进行验证，它会显示一个登录框让用户输入一个不同的用户名和密码。

       客户端和 Web 服务器必须在同一个局域网或企业内联网上。这是因为集成 Windows 验证实际上并不发送用户名和密码信息。相反，它和它所属的域服务器或者活动目录实例互相协作，以此登录并获得将验证信息发送到 Web 服务器的客户端机器上。

       用来传输验证信息的协议有两个：NTLM（NT LAN Manager，NT 局域网管理）验证和 Kerberos 5，根据客户端和服务器操作系统的版本进行选择。如果客户端和服务器端操作系统的版本都在 Windows 2000或者更高，而且两台机器都运行在一个活动目录中，Kerberos 被用作验证协议，否则使用 NTLM 验证。

3.3.1 NTLM 验证

       NTLM 验证 通过一种基于客户端和服务器端三向握手的 盘问/响应 机制来验证客户端。

1. 客户端向服务器端发送信息，表示想和服务器进行通信。
2. 服务器生成一个 64位 的随机值 nonce（当前值）缓存之，并向客户端返回 nonce 以响应客户端的请求。这个响应称为盘问（challenge）。
3. 客户端操作系统要求用户输入用户名和密码，然后自动散列化之。这个散列密码成为主密钥（master key），用来对 nonce 加密。随后将加密后的 nonce 和用户名作为对服务器的响应。
4. 服务器检验返回的 nonce。根据用户是本地用户还是域用户，检验会在本地发生或域控制器上发生。用户的主密钥（即密码的散列版本）会从安全账户数据库中取出，然后对服务器上的纯文本 nonce 进行加密。如果重新生成的 nonce 加密版本和客户端返回的加密版本匹配，则用户验证成功。
5. 在服务器上为当前用户创建一个登录会话。

       整个过程，密码从来都不会在网络上进行传输，这使得 NTLM 非常安全，但还有另一种更安全的协议。

3.3.2 Kerberos 验证简介

       就目前来讲，Kerberos 5 是最安全的协议。它是由 IETF（Internet Engineering Task Force，因特网工程任务组）创建的一个著名的公共标准，实现了一个基于票据的验证协议。如果激活了集成的 Windows 验证，在下面的情况中会自动使用 Kerberos。

• 客户端和服务器端都运行在 Windows 2000 或更高版本
• 网络中存在一个首要域控制器（扮演密钥分发中心的角色）的活动目录域

       Kerberos 的内容能写一本书。这里只学习一些基本概念来帮助理解必需的配置任务以及每一个功能在什么时候会起作用。比如 NTLM 和 Kerberos 之间一个很大的区别就是 Kerberos 同时支持身份模拟和委托，而 NTLM 只支持身份模拟。

       Kerberos 系统的核心组件是 KDC（Key Distribution Center，密钥分发中心），负责发送票据和管理凭证。在 Windows 世界里，活动目录的首要域控制器扮演着 KDC 的角色。验证过程涉及的每一个参与者（客户端和服务器）必须信任 KDC。KDC 管理所有用户和计算机的账号，并发送验证票据和会话票据。

       Kerberos 和 NTLM 还有另外一个很大的不同：NTLM 在工作组环境下运行，无需中央授权。Kerberos 则需要一个中央授权来发送任意类型的票据，因此，要使 Kerberos 起作用，需要连接到一个活动目录的域控制器。

       Kerberos 验证和票据的基本流程：

1. 客户端提交一个请求到验证服务，验证服务运行在 KDC（活动目录域控制器）上面。请求包含用户名，KDC 从安全账号数据库中读取用户的主密钥（密码的散列版本）。
2. 它创建一个 TGT（Ticket-Granting Ticket，票据授予票据）。包含一个用于用户会话的会话密钥以及一个过期日期的时间。服务器使用用户的主密钥对 TGT 进行加密，然后发送会客户端。
3. 客户端只有输入正确的密码，客户端操作系统才能创建相同的主密钥（散列）来成功解密从服务器接收到的 TGT。解密成功，验证通过。
4. 客户端将 TGT 在本地缓存。
5. 当客户端想和网络中的一台成员服务器通信时，首先向 KDC 请求一个会话票据。为此，它将一个在本地缓存的 TGT 发送到 KDC 上的票据授予服务。这个服务检查 TGT，如果 TGT 有效（没有过期、没有被篡改等），它就为这个客户端和成员服务器之间的通信创建一个会话密钥，然后使用客户端的主密钥对这个会话密钥进行加密。此外，这个会话密钥被打包到 ST（Session Ticket，会话票据），ST 包含了额外的过期信息。这个会话票据使用成员服务器的主密钥进行加密。当然，服务器和客户端都必须被 KDC 所知，也就是之前它们二者都被添加到了域中（域中增加一个机器意味着这个机器和 KDC 之间建立一个信任关系）。因此，KDC 知道客户端和成员服务器的主密钥。
6. 被加密的会话密钥和会话票据都被传送到客户端。
7. 客户端解密会话密钥，并在本地缓存中保存会话密钥的副本。
8. 客户端把加密的会话密钥传送到服务器。
9. 如果服务器可以成功解密并验证从客户端接收的会话票据，就会建立通信会话。
10. 客户端和服务器端都使用先前生成的会话密钥对通信传输进行加密。一旦会话票据过期，整个操作会重来一遍。

       每一个票据（会话票据、票据授予票据）都有一定的功能。这些功能只是某些特性（如身份模拟或委托）所需的一组定义好的属性。比如，有了特定的属性，它们可以在服务器上模拟客户端用户的身份或者将客户端身份委托给另外一个服务器。