获取 Kerberos 认证方式的用户名的方法、 装置和系统 技术领域 本发明涉及代理环境下的身份认证协议，更具体地说，涉及一种获取 Kerberos 认证方式的用户名的方法、装置和系统。
背景技术 在网络环境中，主要包括两种认证协议 ：Kerberos 协议、和 NTLM(WindowsNT LAN Manager Challenge/Response) 协议。 NTLM 协议是用在包括 Windows 操作系统的网 络中的一种认证协议。 下面详细描述 NTLM 非交互式的认证过程 ：
1、客户端首先在本地加密当前用户的密码成为密码散列 ；
2、客户端向代理服务器发送自己的用户名，这个用户名是没有经过加密的，明 文直接传输 ；
3、代理服务器产生一个 16 位的随机数字发送给客户端，作为一个 challenge( 挑 战)；
4、客户端再用加密后的密码散列来加密该 challenge，然后把这个返回给代理服 务器。 作为 response( 响应 ) ；
5、代理服务器把用户名、给客户端的 challenge、客户端返回的 response 这三项 数据发送给域控制器 ；
6、域控制器使用用户名在 SAM(Security Account Manager) 数据库中找到这个用 户的密码散列，然后使用这个密码散列来加密 challenge ；
7、域控制器比较两次加密的 challenge，如果一样，那么认证成功。
Kerberos 协议基于私钥加密算法，需要可信任的第三方作为认证服务器，主要 用于计算机网络的身份鉴别，用户只需输入一次身份验证信息就可以凭借此验证获得的 票据访问多个服务，即 SSO(Single Sign On)。 由于在每个客户端和服务器之间建立了共 享密钥，使得该协议具有相当的安全性。
Kerberos 协议流程如图 1 所示，详细描述如下 ：
(1) 客户端从 KDC 请求 TGT
在用户试图通过提供用户凭据登录到客户端时，如果已启用了 Kerberos 身份认 证协议，则客户端计算机上的 Kerberos 服务向 KDC(Key DistributionCenter，密钥分发中 心 ) 发送一个 Kerberos 身份认证服务请求，以期获得 TGT(Ticket-Granting Ticket，票证许 可票证 )。
(2)KDC 发送加密的 TGT 和登录会话密钥
KDC 为用户获取长效密钥 ( 即密码 )，然后解密随 Kerberos 身份认证请求一起传 送的时间戳。 如果该时间戳有效，则用户是有效用户。 KDC 身份认证服务创建一个登 录会话密钥，并使用用户的长效密钥对该登录会话密钥进行加密。 然后，KDC 身份认证 服务再创建一个 TGT，它包括用户信息和登录会话密钥。 最后，KDC 身份认证服务使用 长效密钥加密 TGT，并将加密的登录会话密钥和加密的 TGT 传递给客户端。
(3) 客户端向 KDC TGS 请求 ST
客户端使用其长效密钥 ( 即密码 ) 解密登录会话密钥，并在本地缓存。 同时， 客户端还将加密的 TGT 存储在缓存中。 这时还不能访问网络服务，因为它仅获得了 TGT 和登录会话密钥，仅完成了网络登录的过程，还没有获得访问相应网络服务器所需的服 务票证 (Service Ticket， ST)。 客户端向 KDC 票证许可服务 (Ticket-Granting Service， TGS) 发送一个服务票证请求 (ST 是由 TGS 颁发的 )。
(4)TGS 发送加密的服务会话密钥和 ST
KDC 使用自己创建的登录会话密钥解密认证符 ( 通常是时间戳 )。 如果验证者 消息成功解密，则 TGS 从 TGT 提取用户信息，并使用用户信息创建一个用于访问对应 服务的服务会话密钥。 使用该用户的登录会话密钥对该服务会话密钥的一个副本进行加 密，创建一个具有服务会话密钥和用户信息的服务票证 (ST)，然后使用该服务的长效密 钥 ( 密码 ) 对该服务票证进行加密。 并将加密的服务会话密钥和服务票证返回给客户端。
(5) 客户端发送访问网络服务请求
客户端访问服务时，向代理服务器发送一个请求。 该请求包含身份认证消息 ( 时间戳 )，并用服务会话密钥和服务票证进行加密。
(6) 服务器与客户端进行相互验证
Kerberos 服务器使用服务会话密钥和服务票证解密认证符，并计算时间戳。 然 后与认证符中的时间戳进行比较，如果误差在允许的范围内 ( 通常为 5 分钟 )，则通过测 试，服务器使用服务会话密钥对认证符 ( 时间戳 ) 进行加密，然后将认证符传回到客户 端。 客户端用服务会话密钥解密时间戳，如果该时间戳与原始时间戳相同，则该服务是 真正的，客户端继续连接。 这是一个双向、相互的身份认证过程。
在常见的网络应用场景中，通常需要在核心交换机与代理服务器之间部署流量 分析或审计设备，来获取和分析网络流量的用户信息。 然而当代理服务器的用户采用了 Kerberos 认证方式的情况下，传送的数据包中不存在用户名信息，也就无法获取用户名 以便对用户进行实名制分析。 发明内容 本发明要解决的技术问题在于，针对现有技术的上述无法获取用户名以便对用 户进行实名制分析的缺陷，提供一种获取 Kerberos 认证方式的用户名的方法。
针对上述缺陷，还提供一种获取 Kerberos 认证方式的用户名的装置。
针对上述缺陷，还提供一种获取 Kerberos 认证方式的用户名的系统。
本发明解决其技术问题所采用的技术方案是 ：构造一种获取 Kerberos 认证方式 的用户名的方法，包括 ：
设置代理服务器的用户认证方式为集成认证方式 ；
接收所述代理服务器为响应客户端的访问请求所发送的回复数据包 ；
判断所述回复数据包是否为预设类型数据包，且判断所述回复数据包中是否包 含预设字符串 ；
依据判断结果配置所述回复数据包中包含的所述预设字符串的首字符为预设字 符；
重新计算经配置后的所述回复数据包的 TCP 校验和并予以替换 ；
发送经配置和重新计算后的所述回复数据包至客户端，使得所述客户端将其与 代理服务器的认证方式设置为 NTLM 认证方式 ；
接收所述客户端发送的认证数据包并从中提取所述客户端的用户名。
在本发明所述的获取 Kerberos 认证方式的用户名的方法中，所述集成认证方式 包括 Kerberos 认证方式、 NTLM 认证方式和 Negotiate 认证方式。
在本发明所述的获取 Kerberos 认证方式的用户名的方法中，所述预设类型数 据包包括应用层的首 12 字节为 “HTTP/1.1 407” 的数据包和应用层的首 12 字节为 “HTTP/1.1 401” 的数据包 ；
其中，判断所述回复数据包是否为预设类型数据包具体包括 ：判断所述数据包 是否为应用层的首 12 字节为 “HTTP/1.1 407” 或 “HTTP/1.1 401” 的数据包。
在本发明所述的获取 Kerberos 认证方式的用户名的方法中，所述预设字符串包 括 “Kerberos\r\n” 和 “Negotiate\r\n” ；
其中，判断所述回复数据包中是否包含预设字符串具体包括 ：判断所述回复数 据包中是否包含 “Kerberos\r\n” 或 “Negotiate\r\n”。 在本发明所述的获取 Kerberos 认证方式的用户名的方法中，其中，依据判断结 果配置所述回复数据包中包含的所述预设字符串的首字符为预设字符具体包括 ：
如果所述回复数据包为应用层的首 12 字节为 “HTTP/1.1 407” 或 “HTTP/1.1 401” 的数据包且所述回复数据包中包含 “Kerberos\r\n” 或 “Negotiate\r\n”，则配置所 述回复数据包中包含的 “Kerberos\r\n” 和 “Negotiate\r\n” 的首字符为预设字符。
在本发明所述的获取 Kerberos 认证方式的用户名的方法中，所述预设字符为 “0” 字符。
本发明还提供一种获取 Kerberos 认证方式的用户名的装置，包括 ：
设置单元，用于设置代理服务器的用户认证方式为集成认证方式 ；
接收单元，用于接收所述代理服务器为响应客户端的访问请求所发送的回复数 据包，以及接收所述客户端发送的认证数据包并从中提取所述客户端的用户名 ；
判断单元，用于判断所述回复数据包是否为预设类型数据包，且判断所述回复 数据包中是否包含预设字符串 ；
配置单元，用于依据判断结果配置所述回复数据包中包含的所述预设字符串的 首字符为预设字符 ；
计算和替换单元，用于重新计算经配置后的所述回复数据包的 TCP 校验和并予 以替换 ；
发送单元，用于发送经配置和重新计算后的所述回复数据包至客户端，使得所 述客户端将其与代理服务器的认证方式设置为 NTLM 认证方式。
在本发明所述的获取 Kerberos 认证方式的用户名的装置中，所述预设类型数 据包包括应用层的首 12 字节为 “HTTP/1.1 407” 的数据包和应用层的首 12 字节为 “HTTP/1.1 401” 的数据包。
在本发明所述的获取 Kerberos 认证方式的用户名的装置中，所述预设字符串包 括 “Kerberos\r\n” 和 “Negotiate\r\n”。
本发明还提供一种获取 Kerberos 认证方式的用户名的系统，包括客户端、域控 制器、代理服务器，还包括 ：
用户名获取装置，与所述客户端和代理服务器通信连接，用于获取所述客户端 的用户名，所述用户名获取装置包括 ：
设置单元，用于设置代理服务器的用户认证方式为集成认证方式 ；
接收单元，用于接收所述代理服务器为响应客户端的访问请求所发送的回复数 据包，以及接收所述客户端发送的认证数据包并从中提取所述客户端的用户名 ；
判断单元，用于判断所述回复数据包是否为预设类型数据包，且判断所述回复 数据包中是否包含预设字符串 ；
配置单元，用于依据判断结果配置所述回复数据包中包含的所述预设字符串的 首字符为预设字符 ；
计算和替换单元，用于重新计算经配置后的所述回复数据包的 TCP 校验和并予 以替换 ；
发送单元，用于发送经配置和重新计算后的所述回复数据包至客户端，使得所 述客户端将其与代理服务器的认证方式设置为 NTLM 认证方式。 本发明的有益效果是，在使用代理服务器且支持集成认证方式的环境下，通过 配置或修改数据包中的预设字符串中的预设字符，从而使得客户端的认证方式设置为 NTML 认证方式，在客户端发送认证数据包时就可以从中获取到客户端对应的用户名， 通过分析网络上传送的该用户名对应的数据流来决定是否对该用户进行相应的控制措 施。
附图说明
下面将结合附图及实施例对本发明作进一步说明，附图中 ： 图 1 是 Kerberos 协议的认证方式流程图 ； 图 2 是依据本发明一实施例的获取 Kerberos 认证方式的用户名的方法流程图 ； 图 3 是图 1 中步骤 103 的详细流程图 ； 图 4 是依据本发明一实施例的获取 Kerberos 认证方式的用户名的装置结构示意 图 5 是依据本发明一实施例的获取 Kerberos 认证方式的用户名的系统结构示意 图 6 是在代理环境下使用图 1 所示的获取用户名方法之后的数据通信示意图。图；
图；
具体实施方式
图 2 是依据本发明一实施例的获取 Kerberos 认证方式的用户名的方法 100 流程 图，图 2 所示的获取用户名的方法可由部署在客户端和代理服务器之间的审计或流控设 备来完成。 由于 Kerberos 认证方式环境下，传送的数据包中未包含用户名等信息，因此 审计或流控设备若想获取 Kerberos 认证方式环境下的用户名等信息是不可能的。 若想获 取用户名，需要将客户端和代理服务器之间的认证方式修改为 NTLM，具体实现步骤如 下：步骤 201，设置代理服务器的用户认证方式为集成认证方式 ； 步骤 202，接收所述代理服务器为响应客户端的访问请求所发送的回复数据包； 步骤 203，判断所述回复数据包是否为预设类型数据包，且判断所述回复数据包 中是否包含预设字符串 ；
步骤 204，依据判断结果配置所述回复数据包中包含的所述预设字符串的首字符 为预设字符 ；首字符即首字节。
步骤 205，重新计算经配置后的所述回复数据包的 TCP 校验和并予以替换 ； 即，重新计算 TCP 校验和，并将新的 TCP 校验和写入回复数据包中的 TCP 校验和位置， 替换之前的 TCP 校验和。
步骤 206，发送经配置和重新计算后的所述回复数据包至客户端，使得所述客户 端将其与代理服务器的认证方式设置为 NTLM 认证方式 ；
步骤 207，接收所述客户端发送的认证数据包并从中提取所述客户端的用户名。
其中，集成认证方式包括 Kerberos 认证方式、 NTLM 认证方式和 Negotiate 认 证方式。 设置为集成认证方式后，代理服务器会回发一个包含 NTLM、 Kerberos 以及 Negotiate 代理认证方式字段的恢复包，客户端可根据代理服务器返回的回复数据包进行 协商，如果客户端支持 Kerberos 则使用 Kerberos，否则使用 NTLM(win 2003 以上系统默 认是 Kerberos)。 为了获取客户端的用户名信息，则必需使得认证方式的选择权不由客户 端决定，因此将代理服务器返回的回复数据包的代理认证方式字段进行修改，使得客户 端将其与代理服务器的认证方式强制设置为 NTLM 认证方式。 而在 NTLM 认证方式中， 由于客户端发送的数据包 ( 通常使用 Base64 编码的 ) 中包含用户名信息，通过解码该数 据包就可以获取到用户名，并据此分析网络上传送的该用户名对应的数据流来决定是否
对该用户进行相应的控制措施。
图 3 是图 2 中步骤 203 的详细流程图。 在本发明中，预设类型数据包包括应用 层的首 12 字节为 “HTTP/1.1 407” 的数据包 ( 或称为 407 回包 ) 和应用层的首 12 字节 为 “HTTP/1.1 401” 的数据包 ( 或称为 401 回包 )。 预设字符串包括 “Kerberos\r\n” 和 “Negotiate\r\n”。
其中，图 2 中的步骤 203 包括图 3 所示的步骤 2031 和步骤 2032。
在步骤 2031 中，判断数据包是否为应用层的首 12 字节为 407 回包或 401 回包。 若是，则进入步骤 2032，进一步判断所述回复数据包中是否包含预设字符串，若否，则 结束。
在步骤 2032 中，判断回复数据包中是否包含 “Kerberos\r\n” 或 “Negotiate\ r\n”， 若 包 含 “Kerberos\r\n” 或 “Negotiate\r\n” 中 任 一 个， 则 进 入 步 骤 104 ；若 “Kerberos\r\n” 和 “Negotiate\r\n” 中任一个都不包含，则结束。 其中在判断数据包中 是否包含 “Kerberos\r\n” 或 “Negotiate\r\n”，主要是判断数据包的应用层中是否包含 “Kerberos\r\n” 或 “Negotiate\r\n”。 在判断是否包含 “Kerberos\r\n” 或 “Negotiate\ r\n” 之 前， 还 需 判 断 数 据 包 的 应 用 层 中 是 否 包 含 “Proxy-Authenticate ： ” ( 冒 号 后 面 有 一 个 空 格 )。 不 过 一 般 情 况 下， 代 理 服 务 器 发 送 的 数 据 包 中 都 会 包 含 “Proxy-Authenticate ： ”，因此可以根据需要决定是否做此判断。在步骤 204 中，如果所述回复数据包为应用层的首 12 字节为 “HTTP/1.1407” 或 “HTTP/1.1 401” 的数据包且所述回复数据包中包含 “Kerberos\r\n” 或 “Negotiate\ r\n”，则配置回复数据包中包含的 “Kerberos\r\n” 和 “Negotiate\r\n” 的首字符为预设字 符。 在本发明中，预设字符可以任意设置，只要保证将 “Kerberos\r\n” 的首字符 “K” 更改为非 K 字符，将 “Negotiate\r\n” 的首字符 “N” 更改为非 N 字符即可。 例如但 不限于将 “K” 和 “N” 都更改为 “0”，即 “Kerberos\r\n” 更改为 “0erberos\r\n”， “Negotiate\r\n” 更改为 “0egotiate\r\n”。 “Kerberos\r\n” 和 “Negotiate\r\n” 的首字 符更改的唯一原则就是使得回复数据包中不再包含字符串 “Kerberos\r\n” 和 “Negotiate\ r\n”。
由于对数据包中的 “Kerberos\r\n” 和 “Negotiate\r\n” 的首字符进行了更改，数 据包中的原来的 TCP 校验和已错误，为了使得数据包能够正常发送和识别，需要对 TCP 校验和进行重新计算和替换。 这样，客户端收到该数据包后，就会将其与代理服务器的 认证方式设置为 NTLM 认证方式。
关于图 2 和图 3 所示流程图的处理过程总结如下 ：
1) 判断首 12 字节是否为 “HTTP/1.1 407” 回包或 “HTTP/1.1 401” 回包 ；
2) 如 果 为 “HTTP/1.1 407” 回 包 或 “HTTP/1.1 401” 回 包， 判 断 随 后 的 数 据 是 否 包 含 “Proxy-Authenticate ： ” ( 冒 号 后 面 有 一 个 空 格 ) ；以 及 判 断 “Proxy-Authenticate ： ” 字段后面紧跟的数据是否为 “Kerberos\r\n” 或 “Negotiate\ r\n”，如果是则修改这两种字符串的第一个字节并继续步骤 (3) ；
3) 然后继续回到步骤 1) 进行判断，直到数据包末尾。
因此，以 407 回包为例，我们关注的数据包内容大致如下 ：
HTTP/1.1 407
...( 忽略中间内容 )
Proxy-Authenticate ：Negotiate\r\n
Proxy-Authenticate ：Kerberos\r\n
...( 忽略后面内容 )
图 4 是依据本发明一实施例的获取 Kerberos 认证方式的用户名的装置 400 结构示 意图。 装置 400 即前文所述的审计或流控设备或者审计或流控设备中的一个部件，获取 客户端的用户名。
装置 400 包括设置单元 401、接收单元 402、判断单元 403、配置单元 404、计算 和替换单元 405、发送单元 406。
设置单元 401，用于设置代理服务器的用户认证方式为集成认证方式 ；
接收单元 402，用于接收所述代理服务器为响应客户端的访问请求所发送的回复 数据包，以及接收所述客户端发送的认证数据包并从中提取所述客户端的用户名 ；
判断单元 403，用于判断所述回复数据包是否为预设类型数据包，且判断所述回 复数据包中是否包含预设字符串 ；
配置单元 404，用于依据判断结果配置所述回复数据包中包含的所述预设字符串 的首字符为预设字符 ；
计算和替换单元 405，用于重新计算经配置后的所述回复数据包的 TCP 校验和并予以替换 ；
发送单元 406，用于发送经配置和重新计算后的所述回复数据包至客户端，使得 所述客户端将其与代理服务器的认证方式设置为 NTLM 认证方式。
其中，预设类型数据包包括应用层的首 12 字节为 “HTTP/1.1 407” 的数据包和 应用层的首 12 字节为 “HTTP/1.1 401” 的数据包。 预设字符串包括 “Kerberos\r\n” 和 “Negotiate\r\n”。
图 2-3 中关于获取 Kerberos 认证方式的用户名的方法的详细描述适用于图 4，此 处不再赘述。
关于图 4 中的设置单元 401 可以单独设置，或者独立于装置 400 外设置，图 4 中 示出了设置单元 401 包含在装置 400 中仅为示例，并不作为对本发明的限制。 图 4 中可 以不包含设置单元，由其它方式或装置来执行认证方式的设置操作，也就是说，装置 400 工作的前提是代理服务器的用户认证方式为集成认证方式。 装置 400 可以单独设置，也 可以设置于网桥设备中。 包含装置 400 的网桥设备既可以完成路由和数据交换功能又可 以获取用户名，实现对客户端用户的数据分析和监控。
图 5 是依据本发明一实施例的获取 Kerberos 认证方式的用户名的系统 500 结构示 意图。 系统 500 包括客户端 501、域控制器 502、代理服务器 503，用户名获取装置 504。 用户名获取装置 504，与客户端 501 和代理服务器 503 通信连接，用于获取客户 端 501 的用户名，用户名获取装置 504 的具体结构与图 4 所示的装置 400 相同，图 4 中关 于装置 400 的描述适用于图 5 中的用户名获取装置 504，此处不再赘述。 客户端 501 与用 户名获取装置 504 和域控制器 502 的数据通信还需要核心交换机来实现，图中未示出。
图 6 是在代理环境下使用图 1 所示的获取用户名方法之后的数据通信示意图。 在 此实施例中，以 407 回包为例进行阐述。 用户名获取装置为图 4 中的装置 400 或图 5 中 的用户名获取装置 504，图 6 中的用户名获取装置也可以是包含装置 400 或用户名获取装 置 504 的网桥设备。
用户名获取装置获取到来自代理服务器的回复数据包 ( 这里示出的是 407 回包， 还可以是 401 回包 ) 后，判断该回复数据包为 407 回包后，将 407 回包中的 “Negotiate” 和 “Kerberos” 中的首字母 “N”、 “K” 更改为 “0”。 此处的更改方式仅为示例， 只要保证将 “Kerberos\r\n” 的首字符 “K” 更改为非 K 字符，将 “Negotiate\r\n” 的首 字符 “N” 更改为非 N 字符即可，如前文所述。
经过处理后的回复数据包传送到客户端，客户端将用户认证方式设置成 NTLM 认证方式，客户端随后发送的数据包中就会包含用户名，用户名获取装置通过截获传送 路径上的数据包就能得知用户名，并能获取用户名对应的数据流，从而对该用户的操作 行为进行分析和控制。
图 6 中，代理服务器以及客户端均加入域 ( 例如公司或企业局域网的域 ) 中，并 设置好域上的用户名以及密码。 图中，代理服务器通过核心路由器与 web 服务器进行交 互。 下面对采用本发明获取用户名的方法后的处理过程和显示结果进行阐述 ：
1) 将代理服务器用户身份认证方式设置为集成方式。
2) 用户名获取装置 ( 例如流量分析或审计设备 ) 开启篡改数据包以及获取 NTLM 用户名的功能。
3) 客户端 PC 的浏览器设置 web 代理上网，指向代理服务器。
4) 在 PC 上使用 wireshark( 一种网络封包分析软件 ) 进行抓包，当然还可以使用 其它抓包工具。
5) 通过浏览器上网，弹出认证框后，输入客户端在域上设置好的用户名与密 码。
可以发现， wireshark 抓包的 http 407 回包中的 “Kerberos” 以及 “Negotiate” 字段已经被改为 “0erberos” 和 “0egotiate”，后续认证方式也自动转换成 NTLM，且浏 览器正常上网，用户名获取装置 ( 例如流量分析或审计设备 ) 上也正确地提取了用户名。
本发明通常可应用在对企业或集团的局域网或其它区域网络中的用户的数据交 互行为进行管理和监控。 便于公司或企业管理其员工，保证公司的机密信息不对外公 开，同时也能及时地制止不正常或非法的数据传递活动。 一旦发现问题，所接收的数据 包不再继续发送给代理服务器。
本发明在使用代理服务器且同时支持 NTLM 和 Kerberos 认证方式的环境下，通 过篡改数据包的方式，令代理服务器的协商的身份认证方式由 Kerberos 变为 NTLM，从 而能够从中提取用户名，解决了在这种网络场景中，流量分析或审计设备无法进行用户 实名制分析的问题。