Windows集成验证功能块概要设计.doc

1 引言1.1 编写目的编写该文档的目的在于引导软件开发人员、软件测试人员以及最终用户对Windows下的集成验证的原理及实现有更好的理解。该文档的读者为用户代表、软件分析人员、开发管理人员、质量管理人员和测试人员。1.2 概述身份认证是系统安全的一个基础方面，它用来确认尝试登录域或访问网络资源的任何用户的身份。Windows服务器系统身份认证针对所有网络资源启用“单点登录”（SingleSign-on，SSO）。采用单点登录后，用户可以使用一个密码或智能卡一次登录到域，然后向域中的任何计算机验证身份。身份认证的重要功能就是它对单点登录的支持。单点登录是一种方便用户访问多个系统的技术，用户只需在登录时进行一次注册，就可以在一个网络中自由访问，不必重复输入用户名和密码来确定身份。单点登录的实质就是安全上下文（Security Context）或凭证（Credential）在多个应用系统之间的传递或共享。当用户登录系统时，客户端软件根据用户的凭证（例如用户名和密码）为用户建立一个安全上下文，安全上下文包含用于验证用户的安全信息，系统用这个安全上下文和安全策略来判断用户是否具有访问系统资源的权限。Kerberos V5身份认证协议提供一个在客户端跟服务器端之间，或者服务器与服务器之间的双向身份认证机制。单点登录在安全性方面提供了两个主要优点。对用户而言，单个密码或智能卡的使用减少了混乱，提高了工作效率。对管理员而言，由于管理员只需要为每个用户管理一个账户，因此域用户所要求的管理支持减少了。2 身份验证原理解析身份验证是一个验证客户端身份的过程，通常采用指定的第三方授权方式。客户端可能是最终用户、计算机、应用程序或服务。客户端的标识称为安全原则。为了使用服务器应用程序进行验证，客户端提供某种形式的凭据来允许服务器验证客户端的标识。确认了客户端的标识后，应用程序可以授予执行操作和访问资源的原则。2.1 NTLM身份验证这种验证方式需要把用户的用户名和密码传送到服务端，服务端验证用户名和密码是否和服务器的此用户的密码一致。用户名用明码传送，但是密码经过处理后派生出一个8字节的key加密质询码后传送。2.1.1 NTLM身份验证机制图：NTLM 质询/应答机制2.1.2 概述质询/应答机制 用户请求访问。用户尝试通过提供用户凭据登录到客户端。登录前，客户端计算机缓存密码的哈希值并放弃密码。客户端向服务器发送一个请求，该请求包括用户名以及纯文本格式的请求。 服务器发送质询消息。服务器生成一个称为质询的 16 字节随机数（即 NONCE），并将它发送到客户端。 客户端发送应答消息。客户端使用由用户的密码生成的一个密码哈希值来加密服务器发送的质询。它以应答的形式将这个加密的质询发回到服务器。 服务器将质询和应答发送到域控制器。服务器将用户名、原始质询以及应答从客户端计算机发送到域控制器。 域控制器比较质询和应答以对用户进行身份验证。域控制器获取该用户的密码哈希值，然后使用该哈希值对原始质询进行加密。接下来，域控制器将加密的质询与客户端计算机的应答进行比较。如果匹配，域控制器则发送该用户已经过身份验证的服务器确认。 服务器向客户端发送应答。假定凭据有效，服务器授予对所请求的服务或资源的客户端访问权。2.2 Kerberos身份验证与 NTLM 身份验证相比，Kerberos 身份验证具有以下优势： 相互身份验证。当客户端使用 Kerberos v5 协议对特定服务器上的特定服务进行身份验证，Kerberos 为客户端提供网络上恶意代码不会模拟该服务的保证。 委托支持。使用 Kerberos 身份验证对客户端进行身份验证的服务器可以模拟这些客户端，并使用该客户端的安全上下文访问网络资源。 性能。Kerberos 身份验证提供优于 NTLM 身份验证的改进的性能。 简化的信任管理。具有多个域的网络不再需要一组复杂的显式、点对点信任关系。 互操作性。Microsoft 实现的 Kerberos 协议基于向 Internet 工程任务组 （IETF） 推荐的标准跟踪规范。因此，Windows 2000 中协议的实现为与其他网络的互操作奠定了基础（其中 Kerberos 版本 5 用于身份验证）。2.2.1 Kerberos身份验证机制图：Kerberos 身份验证2.2.2 Kerberos v5 协议遵循以下步骤 客户端从 KDC 请求 TGT.用户试图通过提供用户凭据登录到客户端。客户端计算机上的 Kerberos 服务向密钥发行中心 （KDC） 发送一个 Kerberos 身份验证服务请求。该请求包含用户名、请求票证授予票证（ticket-granting ticket，TGT）所获取的服务信息，以及使用用户的长期密钥（即密码）加密的时间戳。 注:在 Windows 2000 Server 或 Windows Server 2003 操作系统上，域控制器充当 KDC，而 Active Directory 宿主安全帐户数据库。 身份验证服务发送加密的 TGT 和会话密钥。KDC 为来自 Active Directory 的用户获取长期密钥（即密码），然后解密随请求一起传送的时间戳。如果该时间戳有效，则用户是真正的用户。KDC 身份验证服务创建一个登录会话密钥，并使用用户的长期密钥对该副本进行加密。然后，该身份验证服务创建一个 TGT，它包括用户信息和登录会话密钥。最后，该身份验证服务使用自己的密钥加密 TGT，并将加密的会话密钥和加密的 TGT 传递给客户端。 客户端从 TGT 请求服务器访问。客户端使用其长期密钥（即密码）解密登录会话密钥，并在本地缓存它。此外，客户端还将加密的 TGT 存储在它的缓存中。访问网络服务时，客户端向 KDC 票证授予服务（ticket-granting service，TGS）发送一个包含信息的请求，这些信息包括用户名、使用用户登录会话密钥加密的验证者消息、TGT，以及用户想访问的服务（和服务器）名称。 TGS 发送加密的会话密钥和票证。KDC 上的 TGS 使用自己的密钥解密 KDC 并提取登录会话密钥。它使用该登录会话密钥解密验证者消息（通常是时间戳）。如果验证者消息成功解密，TGS 从 TGT 提取用户信息，并使用用户信息创建一个用于访问该服务的服务会话密钥。它使用该用户的登录会话密钥对该服务会话密钥的一个副本进行加密，创建一个具有服务会话密钥和用户信息的服务票证，然后使用该服务的长期密钥（密码）对该服务票证进行加密。然后，TGS 将加密的服务会话密钥和服务票证添加到客户端。 客户端发送服务票证。客户端访问服务时，向服务器发送一个请求。该请求包含验证者消息（时间戳），该消息使用服务会话密钥和服务票证进行加密。 服务器发送加密的时间戳以进行客户端验证。服务器解密服务票证并提取服务会话密钥。通过使用服务会话密钥，服务器解密验证者消息（时间戳）并计算它。如果验证者通过测试，则服务器使用服务会话密钥对验证者（时间戳）进行加密，然后将验证者传回到客户端。客户端解密时间戳，如果该时间戳与原始时间戳相同，则该服务是真正的，客户端继续连接。3 功能实现3.1 NTLM身份验证3.1.1 认证过程 1: C - S GET .2: C S GET . Authorization: NTLM 4: C - S 401 Unauthorized WWW-Authenticate: NTLM 5: C - S GET . Authorization: NTLM 6: C - S 200 Ok从交互过程可以发现，client会发送type-1消息和type-3消息给server，而server会发送type-2消息给client。Type-1消息包括机器名、Domain等Type-2消息包括server发出的NTLM challengeType-3消息包括用户名、机器名、Domain、以及两个根据server发出的challenge计算出的response，这里response是基于challenge和当前用户的登录密码计算而得3.1.2 功能实现通过IE访问，上述的交互会由浏览器自动完成，微软总是有办法自己到系统里去拿到Domain、用户名、密码等等信息的，而火狐等其他浏览器就没有这么方便了，它必须要用户手工输入，当server返回401错误后，火狐会弹出该对话框让用户输入用户名、密码（在IE中，如果使用当前登录的用户名、密码验证失败后也会弹出类似的对话框）有了NTLM HTTP认证协议，下面要实现SSO就方便多了。这时Server已经拿到client的认证信息：用户名、Domain、密码和challenge的某个运算值，这时Server只要利用这些信息连接到AD（Active Directory，活动目录）进行认证即可。用户认证过程中Server拿到的并不是密码，而是密码的某个单向hash值，我们将通过SMB协议验证该用户身份有效性。SMB是微软用来进行局域网文件共享和传输的协议，也称为CIFS（Common Internet File System）首先我们看一下CIFS协议里连接和断开连接的部分：连接：断开连接：在CIFS连接server（比如AD）时，首先server会发一个叫做EncryptionKey的东东给client，然后client会利用和NTLM HTTP认证中一样的算法计算出一个response给server，这个细节很关键！因为如果http server（在这里充当CIFS的client）用这个EncryptionKey作为给http client的challenge，http client会计算出response给http server，然后http server就可以拿着这个response到AD上验证了！现在有三个参与者了：http client，http server和AD想象一下，首先http client发http请求给http server，为了对这个client认证，http server首先连接AD，然后就得到一个EncryptionKey，它就把这个EncryptionKey作为challenge返回给http client，然后http client会根据这个challenge和用户密码计算出response送给http server，而http server就拿着这个response到AD去认证了。下图就表示整个这个过程：在我们的程序中通过使用Open Source的library JCIFS完成认证过程。JCIFS是samba组织下的一帮牛开发的一套兼容SMB协议的library，我们可以用它来在java里访问Windows共享文件，当然，既然它帮我们实现了SMB协议，那要用它来实现NTLM SSO就很容易了。将JCIFS的library导入工程中。创建一个Servlet Filter，继承jcifs的NtlmHttpFilter。修改web.xml文件。 SSO Ntlm Filter com.security.filters.sso.ntlm.NtlmFilter jcifs.resolveOrderWINS,BCAST,DNSjcifs.util.loglevel2 SSO Ntlm Filter /portal/ntlm/* NtlmFilter类的实现主要完成获取验证用户信息，验证结果的处理。注：具体在认证系统中代码如何实现还要考虑下，主要是要考虑结合管理平台的认证方式配置，以及下面介绍的采用Kerberos V5协议的Kerberos认证方式。3.2 Kerberos身份验证注：关于网络层Kerberos身份认证相关知识请参考网络工程师必读网络安全系统设计 电子工业出版社 王达，第五章内容。这里就不过多说明了。/art/200908/141558.htm 5.1 身份认证概述 5.1.1 单点登录身份认证执行方式 5.1.2 主要的身份认证类型 5.2.1 Kerberos V5身份认证机制 5.2.2 Kerberos V5身份认证的优点与. 5.2.3 Kerberos V5协议标准 5.2.4 Kerberos V5身份认证所用端口 5.3 Kerberos SSP认证 5.4.1 Kerberos中的密钥 5.4.2 Kerberos票证（1） 5.4.2 Kerberos票证（2） 5.4.3 认证符 5.4.4 凭证缓存 5.4.5 密钥分发中心（KDC） 5.5.1 Kerberos V5身份认证的3个子协. 5.5.2 身份认证服务（AS）交换 5.5.3 票证许可服务（TGS）交换 5.5.4 客户端/服务器（CS）交换 5.6.1 身份认证服务交换消息详解（1） 5.6.1 身份认证服务交换消息详解（2） 5.6.2 票证许可服务交换消息详解（1） 5.6.2 票证许可服务交换消息详解（2） 5.6.3 客户端/服务器身份认证交换消. 5.6.3 客户端/服务器身份认证交换消息 5.7.1 本地登录示例 5.7.2 域登录示例 5.7.3 域用户的工作站登录（1） 5.7.3 域用户的工作站登录（2） 5.7.3 域用户的工作站登录（3） 5.7.4 单域身份认证示例（1） 5.7.4 单域身份认证示例（2） 5.7.5 用户到用户的身份认证 5.8 Kerberos V5身份认证的启用与策略3.2.1 认证过程客户端IE申请页面GET /auth/portal/tidal HTTP/1.1Accept: */*Accept-Language: zh-cnAccept-Encoding: gzip, deflateUser-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: domain195Connection: Keep-Alive服务端返回无授权回应HTTP/1.1 401 UnauthorizedContent-Type: text/htmlServer: Resion/3.1.6WWW-Authenticate: NegotiateDate: Sat, 10 Oct 2009 17:27:18 GMT客户端选择Kerberos验证，发送验证票到服务端客户端在域中，并且以域账户登录，所以客户端IE选择使用Kerberos身份验证，发送与用户的验证票到服务端。GET /iisstart.htm HTTP/1.1Accept: */*Accept-Language: zh-cnUA-CPU: x86Accept-Encoding: gzip, deflateUser-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: domain195Connection: Keep-AliveAuthorization: Negotiate YIIEzQYGKwYBBQUCoIIEwTCCBL2gJDAiBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICCqKCBJMEggSPYIIEiwYJKoZIhvcSAQICAQBuggR6MIIEdqADAgEFoQMCAQ6iBwMFACAAAACjggOiYYIDnjCCA5qgAwIBBaEOGwxTWkJUSS5HT1YuQ06iFzAVoAMCAQKhDjAMGwRIVFRQGwRsb2dzo4IDaDCCA2SgAwIBF6EDAgEMooIDVgSCA1IeN8fZeLtzkw+5H8HOKmM8zgDOVL5GmeXoS8dMgE20RtI14EVWWZLn2j0AMXTqMOA550Grsadh89vZ89+6vprkVL0v49FM+gxHFCmZSOvLTIawBqXvLU6w1Pni8PN1pbhOKCRVON6+5XH4MN8Rfuqpyy1A/2gfeQIfLMMHs73yohp7h7QJP29b61jm0vj1xE0jEP7EupHlr225vrrVCnktTksbyqi88kIZlCB84J1gTqYoNeOycn4Qzvv8x6z1AsCfo2SBSwo1tj38BK2Fbu+BRXw26RrebGWPkILYwqED7bSR+RlDdokEhjubbyaWcnIjiSXZaN5kQqZQqms3iqhUrZpX7RaaV5BsMOgJs7LwYmc3uM5v7YqljwFD3T44XfpAiS3xlyirP3modOR1l+hV2xdIIFusXtRzY7rTkmEb2F3dGjTiMXySrc0GGhe3TrIeH9nB/2Udo/Z9m0ifXC0EU2fFogefmDc322vHhhv9gEYccG44Q/cnWx8gY9GfWCRihlaefGK+DmCvm+515UFYeIcG5KafXBQw3KX7MjI4/4hlAh3mQNn9p3nX0ePy1G1RRV2SToN7eg1PkaaYXDeC6MSIwCb53MfebzpyN0LKzmPZ6GneLYbyBIpANzPNoXz/LADA1h/l8F098ti1fThPVkUgoehgy1iyovTXyqJg6rojI0juIH7fKfc/UpfO+eLMhsquhH1KNjkCTD2CkdUfcsEU7B15j15p1OyGeg5/tEbRE67+NAWkfLSPp5R3tzGqjAh39w8n/8EWot9DBlHwk+qJp3rMFJZIvNtmXuvqnUW1NGpO1GIf78PBixyFwrJSo5syTfCiWIcw9YQ7MyvuyynAmsXeaI5+OP/GfmGpnvt5kMznu5q/nNf7LMV8n6x2+lmNlcPJiWr+KckPM9Nvntw2h/bl2qGnHDdOqNYI2N0VxzIm8wY6dWS3NIwlGl/usMjjebaELFP6rdHjpVG6pziJYjrBrws5DbqCxJ1EOeQdBiT8l1O6OUQqdOBVZH6/bj5MkLghWv0edHG8TJ4OGa69nMHDwTBOyuyRbTr5uWWFnESdyAGGbfGlJjuvSSzxgZViMSB2j8Ulk8x8MCqrupEK2i0UR6HrMNMJIDJsVcXTpIG6MIG3oAMCAReiga8EgazteAbcguseBpQnHeJihLFO78PfjI2Qop+MkH9jCOrvO9cQns1GzOKByoAbeP307QQq4zbaDF3EJlOC/4k4A6W4dc4k5lNeOgwR4LEvbIQKpdlljFiW8XUb+IgovsOlZEG0qFQgZY0I35I4Uvk/2dDkz06DGiDsQ0IENrRIMT4/7xgMSmkzspO2ojSbG5aKlbjK203QxMlkEoxb8WpJFZQggUqrLAr0q2graET服务端验证通过，返回资源HTTP/1.1 200 OKServer: Resion/3.1.6WWW-Authenticate: Negotiate oYGgMIGdoAMKAQChCwYJKoZIgvcSAQICooGIBIGFYIGCBgkqhkiG9xIBAgICAG9zMHGgAwIBBaEDAgEPomUwY6ADAgEXolwEWrdYWb37ROEMMnP/4vTBwSe9hVe4XklXCWqFKG16d53aBUiTEem+lrFE8ycBgSln3zme63lKfSn9UHoNTlT100T86wxllsyrrMe437ElPcxI4pgcv9rNKU9aKg=Location http:/domain195/auth/portal/tidal/Content-Type text/htmlContent-Length 73Date: Sat, 10 Oct 2009 17:27:18 GMT不管客户端跟服务器是否在域、也不管客户端是否以域帐号登陆，只要客户端以ip地址访问服务器，那么客户端就会选择NTLM方式验证，并且不会直接发送客户端登录用户的用户名和密码给服务器，而是会弹出一个对话框要求用户输入用户名和口令，然后发送到服务端验证。集成 Windows 身份验证Kerberos的验证方式是 Intranet 环境中最好的身份验证方案，在这种用户拥有 Windows 域帐户，Kerberos验证不在网络上传递用户密码，只用传送一个用户验证票。NTLM要传送用户的密码，但是密码经过处理后派生出一个8字节的key加密质询码，也是比较安全的。3.2.2 功能实现(1).在 Active Directory 服务器中，为运行认证系统的主机创建一个用户帐户“authserver”（选择“新建”“用户”，而不是“新建”“计算机”）。 在创建该用户帐户时，应使用计算机的简单名称。例如，在 Active Directory 中创建一个名为 authwall的用户。 请记录下创建用户帐户时定义的密码。在步骤 3 中将需要使用此密码。请勿选择“用户必须在下次登录时更改密码”选项，或任何其他密码选项。 (2).配置新用户帐户以使其符合 Kerberos 协议。此用户帐户的加密类型必须是 DES 并且必须要求进行 Kerberos 预身份验证。 在左窗格的“用户”树中，用鼠标右键单击该用户帐户的名称，然后选择“属性”。 选择“帐户”选项卡，并选中“为此帐户使用 DES 加密类型”框。确保未选中其他框，尤其不要选中“不要求进行 Kerberos 预身份验证”。 设置加密类型可能会损坏密码。因此，应重置用户密码，方法是用鼠标右键单击该用户帐户的名称，选择“重设密码”，然后重新输入之前指定的同一密码。 (3).使用 ktpass 实用工具创建用户映射： ktpass -princ HTTP/authserverDOMAIN.COM -mapuser authserver -pass password -out C:TEMPauthserver.keytab -crypto des-cbc-md5 (4).创建 keytab 文件。在 Windows 上，ktab实用工具管理密钥表中的委托人名称和密钥对，并允许您列出、添加、更新或删除委托人名称和密钥对。在 UNIX 上，最好使用 ktpass实用工具。 在运行域控制器的主机上运行 ktab 实用工具来创建 keytab 文件： ktab -k authserver.keytab -a HTTP/authserverDOMAIN.COM (5).可以通过ktab -l -k authserver.keytab, 来看看里面究竟有针对什么Service的Key。创建JAAS登录文件JAAS 登录文件指明安全框架使用 Kerberos 身份验证并定义 Kerberos 标识信息的 keytab 文件的位置。该文件的位置在java.security.auth.login.config 启动参数中指定.tidalsoft.webconsole.server com.sun.security.auth.module.Krb5LoginModule required debug=true doNotPrompt=true storeKey=true useKeyTab=true keyTab=keytab文件路径;使用 Kerberos 身份验证，需设置下列启动参数： -Djava.security.krb5.realm=域名-Djava.security.krb5.kdc=域控IP地址-Djava.security.auth.login.config=login.config-Djavax.security.auth.useSubjectCredsOnly=false-Dweblogic.security.enableNegotiate=true其中 java.security.krb5.realm 定义运行 Active Directory 服务器的 Microsoft 域。 java.security.krb5.kdc 定义运行 Active Directory 服务器的主机名。 java.security.auth.login.config 定义 Kerberos 登录信息的位置。 javax.security.auth.useSubjectCredsOnly 指定可以使用主题凭据之外的身份验证机制。 相关技术总结JAASGSS-API4 配置 Internet Explorer 浏览器 要将 Internet Explorer 浏览器配置为使用 Windows 身份验证，请在 Internet Explorer 中执行以下过程： 4.1 配置本地 Intranet 域 1. 在 Internet Explorer 中，选择“工具”“Internet 选项”。2. 选择“安全”选项卡。3. 选择“本地 Intranet”，然后单击“站点”。4. 在“本地 Intranet”弹出窗口中，确保选中“包括所有不使用代理服务器的站点”和“包括没有列在其他区域的所有本地 (Intranet) 站点”选项。5. 单击“高级”。6. 在“本地 Intranet”（高级）对话框中，添加所有要在参与 SSO 配置的 WebLogic Server 实例中使用的相对域名（例如，），然后单击“确定”。4.2 配置 Intranet 身份验证 1. 选择“工具”“Internet 选项”。2. 选择“安全”选项卡。3. 选择“本地 Intranet”，然后单击“自定义级别.”。4. 在“安全设置”对话框中，滚动到“用户验证”部分。5. 选择“只在 Intranet 区域自动登录“。使用此选项时，用户不必重新输入登录凭据，它是此解决方案的关键部分。6. 单击“确定”。4.3 验证代理设置 如果启用了代理服务器，则：1. 选择“工具”“Internet 选项”。2. 选择“连接”选项卡，然后单击“局域网设置”。3. 验证代理服务器地址和端口号是否正确。4. 单击“高级”。5. 在“代理服务器设置”对话框中，确保在“例外”字段中输入了所有需要的域名。6. 单击“确定”关闭“代理服务器设置”对话框。4.4 为 Internet Explorer 6.0 设置集成身份验证 如果运行 Internet Explorer 6.0，则除了已描述的设置外，还需要进行另一项设置。1. 在 Internet Explorer 中，选择“工具”“Internet 选项”。2. 选择“高级”选项卡。3. 滚动到“安全”部分。4. 确保选中“启用集成 Windows 身份验证(需要重启动)”，然后单击“确定”。5. 如果未选中此选项，请重新启动计算机。5 认证系统运行环境变更认证系统的JAVA运行环境为x, 在进行