專利名稱：獲取Kerberos認證方式的用戶名的方法、裝置和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及代理環(huán)境下的身份認證協(xié)議，更具體地說，涉及一種獲取Kerberos 認證方式的用戶名的方法、裝置和系統(tǒng)。
背景技術(shù)：
在網(wǎng)絡(luò)環(huán)境中，主要包括兩種認證協(xié)議Kerberos協(xié)議、和NTLM (WindowsNT LAN Manager Challenge/Response)協(xié)議。NTLM協(xié)議是用在包括Windows操作系統(tǒng)的網(wǎng)
絡(luò)中的一種認證協(xié)議。下面詳細描述NTLM非交互式的認證過程1、客戶端首先在本地加密當前用戶的密碼成為密碼散列；2、客戶端向代理服務(wù)器發(fā)送自己的用戶名，這個用戶名是沒有經(jīng)過加密的，明 文直接傳輸；3、代理服務(wù)器產(chǎn)生一個16位的隨機數(shù)字發(fā)送給客戶端，作為一個challenge (挑 戰(zhàn))；4、客戶端再用加密后的密碼散列來加密該challenge，然后把這個返回給代理服 務(wù)器。作為response (響應(yīng))；5、代理服務(wù)器把用戶名、給客戶端的challenge、客戶端返回的response這三項
數(shù)據(jù)發(fā)送給域控制器；6、域控制器使用用戶名在SAM (SecurityAccount Manager)數(shù)據(jù)庫中找到這個用
戶的密碼散列，然后使用這個密碼散列來加密challenge ；7、域控制器比較兩次加密的challenge，如果一樣，那么認證成功。Kerberos協(xié)議基于私鑰加密算法，需要可信任的第三方作為認證服務(wù)器，主要 用于計算機網(wǎng)絡(luò)的身份鑒別，用戶只需輸入一次身份驗證信息就可以憑借此驗證獲得的 票據(jù)訪問多個服務(wù)，即SSO(Single Sign On)。由于在每個客戶端和服務(wù)器之間建立了共 享密鑰，使得該協(xié)議具有相當?shù)陌踩浴?Kerberos協(xié)議流程如圖1所示，詳細描述如下(1)客戶端從KDC請求TGT在用戶試圖通過提供用戶憑據(jù)登錄到客戶端時，如果已啟用了 Kerberas身份認 證協(xié)議，則客戶端計算機上的Kerberos服務(wù)向KDC (Key DistributionCenter，密鑰分發(fā)中 心)發(fā)送一個Kerberos身份認證服務(wù)請求，以期獲得TGT (Ticket-Granting Ticket,票證許
可票證)。(2)KDC發(fā)送加密的TGT和登錄會話密鑰KDC為用戶獲取長效密鑰(即密碼)，然后解密隨Kerberos身份認證請求一起傳 送的時間戳。如果該時間戳有效，則用戶是有效用戶。KDC身份認證服務(wù)創(chuàng)建一個登 錄會話密鑰，并使用用戶的長效密鑰對該登錄會話密鑰進行加密。然后，KDC身份認證 服務(wù)再創(chuàng)建一個TGT，它包括用戶信息和登錄會話密鑰。最后，KDC身份認證服務(wù)使用 長效密鑰加密TGT，并將加密的登錄會話密鑰和加密的TGT傳遞給客戶端。
4
(3)客戶端向KDC TGS請求ST客戶端使用其長效密鑰(即密碼)解密登錄會話密鑰，并在本地緩存。同時， 客戶端還將加密的TGT存儲在緩存中。這時還不能訪問網(wǎng)絡(luò)服務(wù)，因為它僅獲得了 TGT 和登錄會話密鑰，僅完成了網(wǎng)絡(luò)登錄的過程，還沒有獲得訪問相應(yīng)網(wǎng)絡(luò)服務(wù)器所需的服 務(wù)票證(Service Ticket, ST)?？蛻舳讼?KDC 票證許可服務(wù)(Ticket-Granting Service, TGS)發(fā)送一個服務(wù)票證請求(ST是由TGS頒發(fā)的)。(4) TGS發(fā)送加密的服務(wù)會話密鑰和STKDC使用自己創(chuàng)建的登錄會話密鑰解密認證符(通常是時間戳)。如果驗證者 消息成功解密，則TGS從TGT提取用戶信息，并使用用戶信息創(chuàng)建一個用于訪問對應(yīng) 服務(wù)的服務(wù)會話密鑰。使用該用戶的登錄會話密鑰對該服務(wù)會話密鑰的一個副本進行加 密，創(chuàng)建一個具有服務(wù)會話密鑰和用戶信息的服務(wù)票證(ST)，然后使用該服務(wù)的長效密 鑰(密碼)對該服務(wù)票證進行加密。并將加密的服務(wù)會話密鑰和服務(wù)票證返回給客戶端。(5)客戶端發(fā)送訪問網(wǎng)絡(luò)服務(wù)請求客戶端訪問服務(wù)時，向代理服務(wù)器發(fā)送一個請求。該請求包含身份認證消息 (時間戳)，并用服務(wù)會話密鑰和服務(wù)票證進行加密。(6)服務(wù)器與客戶端進行相互驗證Kerberos服務(wù)器使用服務(wù)會話密鑰和服務(wù)票證解密認證符，并計算時間戳。然 后與認證符中的時間戳進行比較，如果誤差在允許的范圍內(nèi)(通常為5分鐘)，則通過測 試，服務(wù)器使用服務(wù)會話密鑰對認證符(時間戳)進行加密，然后將認證符傳回到客戶 端?？蛻舳擞梅?wù)會話密鑰解密時間戳，如果該時間戳與原始時間戳相同，則該服務(wù)是 真正的，客戶端繼續(xù)連接。這是一個雙向、相互的身份認證過程。在常見的網(wǎng)絡(luò)應(yīng)用場景中，通常需要在核心交換機與代理服務(wù)器之間部署流量 分析或?qū)徲嬙O(shè)備，來獲取和分析網(wǎng)絡(luò)流量的用戶信息。然而當代理服務(wù)器的用戶采用了 Kerberas認證方式的情況下，傳送的數(shù)據(jù)包中不存在用戶名信息，也就無法獲取用戶名 以便對用戶進行實名制分析。

發(fā)明內(nèi)容
本發(fā)明要解決的技術(shù)問題在于，針對現(xiàn)有技術(shù)的上述無法獲取用戶名以便對用 戶進行實名制分析的缺陷，提供一種獲取Kerberos認證方式的用戶名的方法。針對上述缺陷，還提供一種獲取Kerberos認證方式的用戶名的裝置。針對上述缺陷，還提供一種獲取Kerberos認證方式的用戶名的系統(tǒng)。本發(fā)明解決其技術(shù)問題所采用的技術(shù)方案是構(gòu)造一種獲取Kerberos認證方式 的用戶名的方法，包括設(shè)置代理服務(wù)器的用戶認證方式為集成認證方式；接收所述代理服務(wù)器為響應(yīng)客戶端的訪問請求所發(fā)送的回復(fù)數(shù)據(jù)包；判斷所述回復(fù)數(shù)據(jù)包是否為預(yù)設(shè)類型數(shù)據(jù)包，且判斷所述回復(fù)數(shù)據(jù)包中是否包 含預(yù)設(shè)字符串；依據(jù)判斷結(jié)果配置所述回復(fù)數(shù)據(jù)包中包含的所述預(yù)設(shè)字符串的首字符為預(yù)設(shè)字 符；
重新計算經(jīng)配置后的所述回復(fù)數(shù)據(jù)包的TCP校驗和并予以替換；發(fā)送經(jīng)配置和重新計算后的所述回復(fù)數(shù)據(jù)包至客戶端，使得所述客戶端將其與 代理服務(wù)器的認證方式設(shè)置為NTLM認證方式；接收所述客戶端發(fā)送的認證數(shù)據(jù)包并從中提取所述客戶端的用戶名。在本發(fā)明所述的獲取Kerberos認證方式的用戶名的方法中，所述集成認證方式 包括Kerberos認證方式、NTLM認證方式禾口 Negotiate認證方式。在本發(fā)明所述的獲取Kerberos認證方式的用戶名的方法中，所述預(yù)設(shè)類型數(shù) 據(jù)包包括應(yīng)用層的首12字節(jié)為“HTTP/1.1 407”的數(shù)據(jù)包和應(yīng)用層的首12字節(jié)為
“HTTP/1.1 401” 的數(shù)據(jù)包；其中，判斷所述回復(fù)數(shù)據(jù)包是否為預(yù)設(shè)類型數(shù)據(jù)包具體包括判斷所述數(shù)據(jù)包 是否為應(yīng)用層的首12字節(jié)為“HTTP/1.1 407”或"HTTP/1.1401"的數(shù)據(jù)包。在本發(fā)明所述的獲取Kerberos認證方式的用戶名的方法中，所述預(yù)設(shè)字符串包 括 ‘‘Kerberos\r\n” 禾口 ‘‘Negotiate\r\n” ；其中，判斷所述回復(fù)數(shù)據(jù)包中是否包含預(yù)設(shè)字符串具體包括判斷所述回復(fù)數(shù) 據(jù)包中是否包含 ‘‘Kerberos\r\n” 或 ‘‘Negotiate\r\n”。在本發(fā)明所述的獲取Kerberos認證方式的用戶名的方法中，其中，依據(jù)判斷結(jié) 果配置所述回復(fù)數(shù)據(jù)包中包含的所述預(yù)設(shè)字符串的首字符為預(yù)設(shè)字符具體包括如果所述回復(fù)數(shù)據(jù)包為應(yīng)用層的首12字節(jié)為“HTTP/1.1 407”或“HTTP/1.1 401”的數(shù)據(jù)包且所述回復(fù)數(shù)據(jù)包中包含“Kerberos\r\n”或“Negotiate\r\n”，則配置所 述回復(fù)數(shù)據(jù)包中包含的“Kerberos\r\n”和“Negotiate\r\n”的首字符為預(yù)設(shè)字符。在本發(fā)明所述的獲取Kerberos認證方式的用戶名的方法中，所述預(yù)設(shè)字符為 “O”字符。本發(fā)明還提供一種獲取Kerberos認證方式的用戶名的裝置，包括設(shè)置單元，用于設(shè)置代理服務(wù)器的用戶認證方式為集成認證方式；接收單元，用于接收所述代理服務(wù)器為響應(yīng)客戶端的訪問請求所發(fā)送的回復(fù)數(shù) 據(jù)包，以及接收所述客戶端發(fā)送的認證數(shù)據(jù)包并從中提取所述客戶端的用戶名；判斷單元，用于判斷所述回復(fù)數(shù)據(jù)包是否為預(yù)設(shè)類型數(shù)據(jù)包，且判斷所述回復(fù) 數(shù)據(jù)包中是否包含預(yù)設(shè)字符串；配置單元，用于依據(jù)判斷結(jié)果配置所述回復(fù)數(shù)據(jù)包中包含的所述預(yù)設(shè)字符串的 首字符為預(yù)設(shè)字符；計算和替換單元，用于重新計算經(jīng)配置后的所述回復(fù)數(shù)據(jù)包的TCP校驗和并予 以替換；發(fā)送單元，用于發(fā)送經(jīng)配置和重新計算后的所述回復(fù)數(shù)據(jù)包至客戶端，使得所 述客戶端將其與代理服務(wù)器的認證方式設(shè)置為NTLM認證方式。在本發(fā)明所述的獲取Kerberos認證方式的用戶名的裝置中，所述預(yù)設(shè)類型數(shù) 據(jù)包包括應(yīng)用層的首12字節(jié)為“HTTP/1.1 407”的數(shù)據(jù)包和應(yīng)用層的首12字節(jié)為
“HTTP/1.1 401” 的數(shù)據(jù)包。在本發(fā)明所述的獲取Kerberos認證方式的用戶名的裝置中，所述預(yù)設(shè)字符串包 括 “Kerberos\r\n” 禾口 “Negotiate\r\n”。
本發(fā)明還提供一種獲取Kerberos認證方式的用戶名的系統(tǒng)，包括客戶端、域控 制器、代理服務(wù)器，還包括用戶名獲取裝置，與所述客戶端和代理服務(wù)器通信連接，用于獲取所述客戶端 的用戶名，所述用戶名獲取裝置包括設(shè)置單元，用于設(shè)置代理服務(wù)器的用戶認證方式為集成認證方式；接收單元，用于接收所述代理服務(wù)器為響應(yīng)客戶端的訪問請求所發(fā)送的回復(fù)數(shù) 據(jù)包，以及接收所述客戶端發(fā)送的認證數(shù)據(jù)包并從中提取所述客戶端的用戶名；判斷單元，用于判斷所述回復(fù)數(shù)據(jù)包是否為預(yù)設(shè)類型數(shù)據(jù)包，且判斷所述回復(fù) 數(shù)據(jù)包中是否包含預(yù)設(shè)字符串；配置單元，用于依據(jù)判斷結(jié)果配置所述回復(fù)數(shù)據(jù)包中包含的所述預(yù)設(shè)字符串的 首字符為預(yù)設(shè)字符；計算和替換單元，用于重新計算經(jīng)配置后的所述回復(fù)數(shù)據(jù)包的TCP校驗和并予 以替換；發(fā)送單元，用于發(fā)送經(jīng)配置和重新計算后的所述回復(fù)數(shù)據(jù)包至客戶端，使得所 述客戶端將其與代理服務(wù)器的認證方式設(shè)置為NTLM認證方式。本發(fā)明的有益效果是，在使用代理服務(wù)器且支持集成認證方式的環(huán)境下，通過 配置或修改數(shù)據(jù)包中的預(yù)設(shè)字符串中的預(yù)設(shè)字符，從而使得客戶端的認證方式設(shè)置為 NTML認證方式，在客戶端發(fā)送認證數(shù)據(jù)包時就可以從中獲取到客戶端對應(yīng)的用戶名， 通過分析網(wǎng)絡(luò)上傳送的該用戶名對應(yīng)的數(shù)據(jù)流來決定是否對該用戶進行相應(yīng)的控制措 施。


下面將結(jié)合附圖及實施例對本發(fā)明作進一步說明，附圖中圖1是Kerberos協(xié)議的認證方式流程圖；圖2是依據(jù)本發(fā)明一實施例的獲取Kerberos認證方式的用戶名的方法流程圖；圖3是圖1中步驟103的詳細流程圖；圖4是依據(jù)本發(fā)明一實施例的獲取Kerberos認證方式的用戶名的裝置結(jié)構(gòu)示意 圖；圖5是依據(jù)本發(fā)明一實施例的獲取Kerberos認證方式的用戶名的系統(tǒng)結(jié)構(gòu)示意 圖；圖6是在代理環(huán)境下使用圖1所示的獲取用戶名方法之后的數(shù)據(jù)通信示意圖。
具體實施例方式圖2是依據(jù)本發(fā)明一實施例的獲取Kerberos認證方式的用戶名的方法100流程 圖，圖2所示的獲取用戶名的方法可由部署在客戶端和代理服務(wù)器之間的審計或流控設(shè) 備來完成。由于Kerberas認證方式環(huán)境下，傳送的數(shù)據(jù)包中未包含用戶名等信息，因此 審計或流控設(shè)備若想獲取Kerberos認證方式環(huán)境下的用戶名等信息是不可能的。若想獲 取用戶名，需要將客戶端和代理服務(wù)器之間的認證方式修改為NTLM，具體實現(xiàn)步驟如 下
步驟201，設(shè)置代理服務(wù)器的用戶認證方式為集成認證方式；步驟202，接收所述代理服務(wù)器為響應(yīng)客戶端的訪問請求所發(fā)送的回復(fù)數(shù)據(jù) 包；步驟203，判斷所述回復(fù)數(shù)據(jù)包是否為預(yù)設(shè)類型數(shù)據(jù)包，且判斷所述回復(fù)數(shù)據(jù)包 中是否包含預(yù)設(shè)字符串；步驟204，依據(jù)判斷結(jié)果配置所述回復(fù)數(shù)據(jù)包中包含的所述預(yù)設(shè)字符串的首字符 為預(yù)設(shè)字符；首字符即首字節(jié)。步驟205，重新計算經(jīng)配置后的所述回復(fù)數(shù)據(jù)包的TCP校驗和并予以替換； 即，重新計算TCP校驗和，并將新的TCP校驗和寫入回復(fù)數(shù)據(jù)包中的TCP校驗和位置， 替換之前的TCP校驗和。步驟206，發(fā)送經(jīng)配置和重新計算后的所述回復(fù)數(shù)據(jù)包至客戶端，使得所述客戶 端將其與代理服務(wù)器的認證方式設(shè)置為NTLM認證方式；步驟207，接收所述客戶端發(fā)送的認證數(shù)據(jù)包并從中提取所述客戶端的用戶名。其中，集成認證方式包括Kerberos認證方式、NTLM認證方式和Negotiate認 證方式。設(shè)置為集成認證方式后，代理服務(wù)器會回發(fā)一個包含NTLM、Kerberos以及 Negotiate代理認證方式字段的恢復(fù)包，客戶端可根據(jù)代理服務(wù)器返回的回復(fù)數(shù)據(jù)包進行 協(xié)商，如果客戶端支持Kerberos則使用Kerberos，否則使用NTLM(win 2003以上系統(tǒng)默 認是Kerberos)。為了獲取客戶端的用戶名信息，則必需使得認證方式的選擇權(quán)不由客戶 端決定，因此將代理服務(wù)器返回的回復(fù)數(shù)據(jù)包的代理認證方式字段進行修改，使得客戶 端將其與代理服務(wù)器的認證方式強制設(shè)置為NTLM認證方式。而在NTLM認證方式中， 由于客戶端發(fā)送的數(shù)據(jù)包(通常使用Base64編碼的)中包含用戶名信息，通過解碼該數(shù) 據(jù)包就可以獲取到用戶名，并據(jù)此分析網(wǎng)絡(luò)上傳送的該用戶名對應(yīng)的數(shù)據(jù)流來決定是否 對該用戶進行相應(yīng)的控制措施。圖3是圖2中步驟203的詳細流程圖。在本發(fā)明中，預(yù)設(shè)類型數(shù)據(jù)包包括應(yīng)用 層的首12字節(jié)為“HTTP/1.1 407”的數(shù)據(jù)包(或稱為407回包)和應(yīng)用層的首12字節(jié) 為“HTTP/1.1401”的數(shù)據(jù)包(或稱為401回包)。預(yù)設(shè)字符串包括“Kerberos\r\n”和
“Negotiate\r\n”。其中，圖2中的步驟203包括圖3所示的步驟2031和步驟2032。在步驟2031中，判斷數(shù)據(jù)包是否為應(yīng)用層的首12字節(jié)為407回包或401回包。 若是，則進入步驟2032，進一步判斷所述回復(fù)數(shù)據(jù)包中是否包含預(yù)設(shè)字符串，若否，則結(jié)束。在步驟2032中，判斷回復(fù)數(shù)據(jù)包中是否包含“Kerberos\r\n”或“Negotiate\ r\n”，若包含 “Kerberos\r\n” 或 “Negotiate\r\n” 中任一個，則進入步驟 104;若
“Kerberos\r\n”禾Π “Negotiate\r\n”中任一個都不包含，則結(jié)束。其中在判斷數(shù)據(jù)包中 是否包含“Kerberos\r\n”或“Negotiate\r\n”，主要是判斷數(shù)據(jù)包的應(yīng)用層中是否包含 “Kerberos\r\n” 或 “Negotiate\r\n”。在判斷是否包含 “Kerberos\r\n” 或 “Negotiate\ r\n”之前，還需判斷數(shù)據(jù)包的應(yīng)用層中是否包含“Proxy-Authenticate ”(冒 號后面有一個空格)。不過一般情況下，代理服務(wù)器發(fā)送的數(shù)據(jù)包中都會包含 "Proxy-Authenticate ”，因此可以根據(jù)需要決定是否做此判斷。
在步驟204中，如果所述回復(fù)數(shù)據(jù)包為應(yīng)用層的首12字節(jié)為“HTTP/1.1407” 或“HTTP/1.1401”的數(shù)據(jù)包且所述回復(fù)數(shù)據(jù)包中包含“Kerberos\r\n”或“Negotiate\ r\n”，則配置回復(fù)數(shù)據(jù)包中包含的“Kerberos\r\n”和“Negotiate\r\n”的首字符為預(yù)設(shè)字 符。在本發(fā)明中，預(yù)設(shè)字符可以任意設(shè)置，只要保證將“KerberosVXn”的首字符“K” 更改為非K字符，將“NegotiateVXn”的首字符“N”更改為非N字符即可。例如但 不限于將 “K” 和 “N” 都更改為 “0”，艮P “Kerberos\r\n” 更改為 “Oerberos\r\n”，
“Negotiate\r\n” 更改為 “Oegotiate\r\n”。 “Kerberos\r\n” 禾口 “Negotiate\r\n” 的首字 符更改的唯一原則就是使得回復(fù)數(shù)據(jù)包中不再包含字符串“Kerberos\r\n”和“Negotiate\ r\n”。由于對數(shù)據(jù)包中的“Kerberos\r\n”禾Π “Negotiate\r\n”的首字符進行了更改，數(shù)
據(jù)包中的原來的TCP校驗和已錯誤，為了使得數(shù)據(jù)包能夠正常發(fā)送和識別，需要對TCP 校驗和進行重新計算和替換。這樣，客戶端收到該數(shù)據(jù)包后，就會將其與代理服務(wù)器的 認證方式設(shè)置為NTLM認證方式。關(guān)于圖2和圖3所示流程圖的處理過程總結(jié)如下1)判斷首12字節(jié)是否為“HTTP/1.1 407”回包或“HTTP/1.1 401”回包；2)如果為“HTTP/1.1 407” 回包或“HTTP/1.1 401” 回包，判斷隨后 的數(shù)據(jù)是否包含“Proxy-Authenticate:，，(冒號后面有一個空格)；以及判斷 "Proxy-Authenticate ” 字段后面緊跟的數(shù)據(jù)是否為 “Kerberos\r\n” 或 “Negotiate\
r\n”，如果是則修改這兩種字符串的第一個字節(jié)并繼續(xù)步驟(3)；3)然后繼續(xù)回到步驟1)進行判斷，直到數(shù)據(jù)包末尾。因此，以407回包為例，我們關(guān)注的數(shù)據(jù)包內(nèi)容大致如下HTTP/1.1 407...(忽略中間內(nèi)容)Proxy-Authenticate Negotiate\r\nProxy-Authenticate Kerberos\r\n...(忽略后面內(nèi)容)圖4是依據(jù)本發(fā)明一實施例的獲取Kerberos認證方式的用戶名的裝置400結(jié)構(gòu)示 意圖。裝置400即前文所述的審計或流控設(shè)備或者審計或流控設(shè)備中的一個部件，獲取 客戶端的用戶名。裝置400包括設(shè)置單元401、接收單元402、判斷單元403、配置單元404、計算 和替換單元405、發(fā)送單元406。設(shè)置單元401，用于設(shè)置代理服務(wù)器的用戶認證方式為集成認證方式；接收單元402，用于接收所述代理服務(wù)器為響應(yīng)客戶端的訪問請求所發(fā)送的回復(fù) 數(shù)據(jù)包，以及接收所述客戶端發(fā)送的認證數(shù)據(jù)包并從中提取所述客戶端的用戶名；判斷單元403，用于判斷所述回復(fù)數(shù)據(jù)包是否為預(yù)設(shè)類型數(shù)據(jù)包，且判斷所述回 復(fù)數(shù)據(jù)包中是否包含預(yù)設(shè)字符串；配置單元404，用于依據(jù)判斷結(jié)果配置所述回復(fù)數(shù)據(jù)包中包含的所述預(yù)設(shè)字符串 的首字符為預(yù)設(shè)字符；計算和替換單元405，用于重新計算經(jīng)配置后的所述回復(fù)數(shù)據(jù)包的TCP校驗和并予以替換；發(fā)送單元406，用于發(fā)送經(jīng)配置和重新計算后的所述回復(fù)數(shù)據(jù)包至客戶端，使得 所述客戶端將其與代理服務(wù)器的認證方式設(shè)置為NTLM認證方式。其中，預(yù)設(shè)類型數(shù)據(jù)包包括應(yīng)用層的首12字節(jié)為“HTTP/1.1 407”的數(shù)據(jù)包和 應(yīng)用層的首12字節(jié)為“HTTP/1.1401”的數(shù)據(jù)包。預(yù)設(shè)字符串包括“KerberosVXn”和
“Negotiate\r\n”。圖2-3中關(guān)于獲取Kerberos認證方式的用戶名的方法的詳細描述適用于圖4，此 處不再贅述。關(guān)于圖4中的設(shè)置單元401可以單獨設(shè)置，或者獨立于裝置400外設(shè)置，圖4中 示出了設(shè)置單元401包含在裝置400中僅為示例，并不作為對本發(fā)明的限制。圖4中可 以不包含設(shè)置單元，由其它方式或裝置來執(zhí)行認證方式的設(shè)置操作，也就是說，裝置400 工作的前提是代理服務(wù)器的用戶認證方式為集成認證方式。裝置400可以單獨設(shè)置，也 可以設(shè)置于網(wǎng)橋設(shè)備中。包含裝置400的網(wǎng)橋設(shè)備既可以完成路由和數(shù)據(jù)交換功能又可 以獲取用戶名，實現(xiàn)對客戶端用戶的數(shù)據(jù)分析和監(jiān)控。圖5是依據(jù)本發(fā)明一實施例的獲取Kerberos認證方式的用戶名的系統(tǒng)500結(jié)構(gòu)示 意圖。系統(tǒng)500包括客戶端501、域控制器502、代理服務(wù)器503，用戶名獲取裝置504。用戶名獲取裝置504，與客戶端501和代理服務(wù)器503通信連接，用于獲取客戶 端501的用戶名，用戶名獲取裝置504的具體結(jié)構(gòu)與圖4所示的裝置400相同，圖4中關(guān) 于裝置400的描述適用于圖5中的用戶名獲取裝置504，此處不再贅述?？蛻舳?01與用 戶名獲取裝置504和域控制器502的數(shù)據(jù)通信還需要核心交換機來實現(xiàn)，圖中未示出。圖6是在代理環(huán)境下使用圖1所示的獲取用戶名方法之后的數(shù)據(jù)通信示意圖。在 此實施例中，以407回包為例進行闡述。用戶名獲取裝置為圖4中的裝置400或圖5中 的用戶名獲取裝置504，圖6中的用戶名獲取裝置也可以是包含裝置400或用戶名獲取裝 置504的網(wǎng)橋設(shè)備。用戶名獲取裝置獲取到來自代理服務(wù)器的回復(fù)數(shù)據(jù)包(這里示出的是407回包， 還可以是401回包)后，判斷該回復(fù)數(shù)據(jù)包為407回包后，將407回包中的“Negotiate” 和“Kerberos”中的首字母“N”、“K”更改為“0”。此處的更改方式僅為示例， 只要保證將“KerberosVm”的首字符“K”更改為非K字符，將“NegotiateVXn”的首 字符“N”更改為非N字符即可，如前文所述。經(jīng)過處理后的回復(fù)數(shù)據(jù)包傳送到客戶端，客戶端將用戶認證方式設(shè)置成NTLM 認證方式，客戶端隨后發(fā)送的數(shù)據(jù)包中就會包含用戶名，用戶名獲取裝置通過截獲傳送 路徑上的數(shù)據(jù)包就能得知用戶名，并能獲取用戶名對應(yīng)的數(shù)據(jù)流，從而對該用戶的操作 行為進行分析和控制。圖6中，代理服務(wù)器以及客戶端均加入域(例如公司或企業(yè)局域網(wǎng)的域)中，并 設(shè)置好域上的用戶名以及密碼。圖中，代理服務(wù)器通過核心路由器與web服務(wù)器進行交 互。下面對采用本發(fā)明獲取用戶名的方法后的處理過程和顯示結(jié)果進行闡述1)將代理服務(wù)器用戶身份認證方式設(shè)置為集成方式。2)用戶名獲取裝置(例如流量分析或?qū)徲嬙O(shè)備)開啟篡改數(shù)據(jù)包以及獲取NTLM 用戶名的功能。
3)客戶端PC的瀏覽器設(shè)置web代理上網(wǎng)，指向代理服務(wù)器。
4)在PC上使用wireshark(—種網(wǎng)絡(luò)封包分析軟件)進行抓包，當然還可以使用 其它抓包工具。
幻通過瀏覽器上網(wǎng)，彈出認證框后，輸入客戶端在域上設(shè)置好的用戶名與密碼。
可以發(fā)現(xiàn)，wireshark抓包的 http 407 回包中的 “Kerberos” 以及 “i^gotiate” 字段已經(jīng)被改為“Oerberos”和“(bgotiate”，后續(xù)認證方式也自動轉(zhuǎn)換成NTLM，且瀏覽器正常上網(wǎng)，用戶名獲取裝置(例如流量分析或?qū)徲嬙O(shè)備)上也正確地提取了用戶名。
本發(fā)明通?？蓱?yīng)用在對企業(yè)或集團的局域網(wǎng)或其它區(qū)域網(wǎng)絡(luò)中的用戶的數(shù)據(jù)交 互行為進行管理和監(jiān)控。便于公司或企業(yè)管理其員工，保證公司的機密信息不對外公 開，同時也能及時地制止不正常或非法的數(shù)據(jù)傳遞活動。一旦發(fā)現(xiàn)問題，所接收的數(shù)據(jù) 包不再繼續(xù)發(fā)送給代理服務(wù)器。
本發(fā)明在使用代理服務(wù)器且同時支持NTLM和Kerberos認證方式的環(huán)境下，通 過篡改數(shù)據(jù)包的方式，令代理服務(wù)器的協(xié)商的身份認證方式由Kerberos變?yōu)镹TLM，從 而能夠從中提取用戶名，解決了在這種網(wǎng)絡(luò)場景中，流量分析或?qū)徲嬙O(shè)備無法進行用戶 實名制分析的問題。
權(quán)利要求
1.一種獲取Kerberos認證方式的用戶名的方法，其特征在于，包括 設(shè)置代理服務(wù)器的用戶認證方式為集成認證方式；接收所述代理服務(wù)器為響應(yīng)客戶端的訪問請求所發(fā)送的回復(fù)數(shù)據(jù)包； 判斷所述回復(fù)數(shù)據(jù)包是否為預(yù)設(shè)類型數(shù)據(jù)包，且判斷所述回復(fù)數(shù)據(jù)包中是否包含預(yù) 設(shè)字符串；依據(jù)判斷結(jié)果配置所述回復(fù)數(shù)據(jù)包中包含的所述預(yù)設(shè)字符串的首字符為預(yù)設(shè)字符； 重新計算經(jīng)配置后的所述回復(fù)數(shù)據(jù)包的TCP校驗和并予以替換； 發(fā)送經(jīng)配置和重新計算后的所述回復(fù)數(shù)據(jù)包至所述客戶端，使得所述客戶端將其與 代理服務(wù)器的認證方式設(shè)置為NTLM認證方式；接收所述客戶端發(fā)送的認證數(shù)據(jù)包并從中提取所述客戶端的用戶名。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述集成認證方式包括Kerberas認證方 式、NTLM認證方式禾口 Negotiate認證方式。
3.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述預(yù)設(shè)類型數(shù)據(jù)包包括應(yīng)用層的首 12字節(jié)為"HTTP/1.1 407"的數(shù)據(jù)包和應(yīng)用層的首12字節(jié)為"HTTP/1.1401"的數(shù)據(jù) 包；其中，判斷所述回復(fù)數(shù)據(jù)包是否為預(yù)設(shè)類型數(shù)據(jù)包具體包括判斷所述數(shù)據(jù)包是否 為應(yīng)用層的首12字節(jié)為"HTTP/1.1 407"或"HTTP/1.1401"的數(shù)據(jù)包。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述預(yù)設(shè)字符串包括"KerberasVW 和 “Negotiate\r\n” ；其中，判斷所述回復(fù)數(shù)據(jù)包中是否包含預(yù)設(shè)字符串具體包括判斷所述回復(fù)數(shù)據(jù)包 中是否包含 “Kerberos\r\n” 或 “Negotiate\r\n”。
5.根據(jù)權(quán)利要求4所述的方法，其特征在于，其中，依據(jù)判斷結(jié)果配置所述回復(fù)數(shù)據(jù) 包中包含的所述預(yù)設(shè)字符串的首字符為預(yù)設(shè)字符具體包括如果所述回復(fù)數(shù)據(jù)包為應(yīng)用層的首12字節(jié)為"HTTP/1.1 407"或"HTTP/1.1401" 的數(shù)據(jù)包且所述回復(fù)數(shù)據(jù)包中包含“Kerberos\r\n”或“Negotiate\r\n”，則配置所述回復(fù) 數(shù)據(jù)包中包含的“Kerberos\r\n”禾Π “Negotiate\r\n”的首字符為預(yù)設(shè)字符。
6.根據(jù)權(quán)利要求1 5任一項所述的方法，其特征在于，所述預(yù)設(shè)字符為“0”字符。
7.一種獲取Kerberos認證方式的用戶名的裝置，其特征在于，包括 設(shè)置單元，用于設(shè)置代理服務(wù)器的用戶認證方式為集成認證方式；接收單元，用于接收所述代理服務(wù)器為響應(yīng)客戶端的訪問請求所發(fā)送的回復(fù)數(shù)據(jù) 包，以及接收所述客戶端發(fā)送的認證數(shù)據(jù)包并從中提取所述客戶端的用戶名；判斷單元，用于判斷所述回復(fù)數(shù)據(jù)包是否為預(yù)設(shè)類型數(shù)據(jù)包，且判斷所述回復(fù)數(shù)據(jù) 包中是否包含預(yù)設(shè)字符串；配置單元，用于依據(jù)判斷結(jié)果配置所述回復(fù)數(shù)據(jù)包中包含的所述預(yù)設(shè)字符串的首字 符為預(yù)設(shè)字符；計算和替換單元，用于重新計算經(jīng)配置后的所述回復(fù)數(shù)據(jù)包的TCP校驗和并予以替換；發(fā)送單元，用于發(fā)送經(jīng)配置和重新計算后的所述回復(fù)數(shù)據(jù)包至客戶端，使得所述客 戶端將其與代理服務(wù)器的認證方式設(shè)置為NTLM認證方式。
8.根據(jù)權(quán)利要求7所述的裝置，其特征在于，所述預(yù)設(shè)類型數(shù)據(jù)包包括應(yīng)用層的首 12字節(jié)為"HTTP/1.1 407"的數(shù)據(jù)包和應(yīng)用層的首12字節(jié)為"HTTP/1.1401"的數(shù)據(jù)包。
9.根據(jù)權(quán)利要求8所述的裝置，其特征在于，所述預(yù)設(shè)字符串包括“KerberosVXn” 和 “Negotiate\r\n”。
10.—種獲取Kerberos認證方式的用戶名的系統(tǒng)，包括客戶端、域控制器、代理服務(wù) 器，其特征在于，還包括用戶名獲取裝置，與所述客戶端和代理服務(wù)器通信連接，用于獲取所述客戶端的用 戶名，所述用戶名獲取裝置包括設(shè)置單元，用于設(shè)置代理服務(wù)器的用戶認證方式為集成認證方式； 接收單元，用于接收所述代理服務(wù)器為響應(yīng)客戶端的訪問請求所發(fā)送的回復(fù)數(shù)據(jù) 包，以及接收所述客戶端發(fā)送的認證數(shù)據(jù)包并從中提取所述客戶端的用戶名；判斷單元，用于判斷所述回復(fù)數(shù)據(jù)包是否為預(yù)設(shè)類型數(shù)據(jù)包，且判斷所述回復(fù)數(shù)據(jù) 包中是否包含預(yù)設(shè)字符串；配置單元，用于依據(jù)判斷結(jié)果配置所述回復(fù)數(shù)據(jù)包中包含的所述預(yù)設(shè)字符串的首字 符為預(yù)設(shè)字符；計算和替換單元，用于重新計算經(jīng)配置后的所述回復(fù)數(shù)據(jù)包的TCP校驗和并予以替換；發(fā)送單元，用于發(fā)送經(jīng)配置和重新計算后的所述回復(fù)數(shù)據(jù)包至客戶端，使得所述客 戶端將其與代理服務(wù)器的認證方式設(shè)置為NTLM認證方式。
全文摘要
本發(fā)明涉及獲取Kerberos認證方式的用戶名的方法、裝置和系統(tǒng)，包括設(shè)置代理服務(wù)器為集成認證方式；接收代理服務(wù)器為響應(yīng)客戶端的訪問請求所發(fā)送的回復(fù)數(shù)據(jù)包；判斷回復(fù)數(shù)據(jù)包是否為預(yù)設(shè)類型數(shù)據(jù)包且判斷其中是否包含預(yù)設(shè)字符串；依據(jù)判斷結(jié)果配置所述回復(fù)數(shù)據(jù)包中包含的預(yù)設(shè)字符串的首字符為預(yù)設(shè)字符；重新計算TCP校驗和并予以替換；發(fā)送經(jīng)配置和重新計算后的回復(fù)數(shù)據(jù)包至客戶端，使得客戶端將其與代理服務(wù)器的認證方式設(shè)置為NTLM認證方式；接收客戶端發(fā)送的認證數(shù)據(jù)包并從中提取用戶名。本發(fā)明通過配置或修改數(shù)據(jù)包中的預(yù)設(shè)字符串中的預(yù)設(shè)字符，使得客戶端的認證方式設(shè)置為NTML認證方式，從而獲取到客戶端對應(yīng)的用戶名。
文檔編號H04L29/08GK102025748SQ201110000470
公開日2011年4月20日 申請日期2011年1月4日 優(yōu)先權(quán)日2011年1月4日
發(fā)明者武昆, 陳俊浩 申請人:深信服網(wǎng)絡(luò)科技(深圳)有限公司