網絡身份認證——Kerberos配置及認證

NO IMAGE

教材:《信息系統安全概論》

實驗目的

Windows域下kerberos的實現,對用戶是否透明,儘可能多的描述細節。
學習Kerberos的安裝和配置方法,掌握和了解Kerberos的工作原理和實現原理,使用Kerberos實現網絡身份認證。

實驗要求

1)閱讀教材4.6節內容,分別說明客戶機與三類服務器所需完成的任務及以及這種身份認證方式的優缺點。

2)在Kerberos服務端,查詢KDC的配置文件,說明KDC支持的加密方式有哪些?

3)使用命令# man kadmin或查閱MIT Kerberos官方命令手冊,說明在配置服務端時步驟3涉及語句的含義。

4)安裝配置完畢後,分別在客戶端和服務端輸入klist命令,輸出結果是什麼,說明其含義。

實驗環境

VMware Workstation Pro + Ubuntu 16.04

–備註:可以在虛擬機中開啟克隆,就可以實現在一臺機上控制服務端/客戶端的功能。

實驗內容

一、客戶機與三類服務器所需完成的任務,及優缺點

Kerberos認證機制如圖

網絡身份認證——Kerberos配置及認證

1.1 Authentication
客戶機:提供用戶名和口令,向AS傳輸戶名。
身份認證服務器AS:驗證收到的用戶名的合法性,將加密處理後的通行證和會話密鑰用該合法用戶對應的正確口令傳回給客戶機。

1.2 Grant
客戶機:合法用戶已經通過口令解鎖成功,得到會話密鑰(ticket),向grant服務器提供ticket加密的服務請求和身份認證的時候得到的通行證
審批服務器Grant:驗證通行證和服務請求的合法性,合法則發放會話密鑰2和服務卡(第二張ticket)

1.3 Service
客戶機:得到grant提供的服務卡,向SS發送會話密鑰2加密的服務卡和啟動服務的請求。
應用服務器SS:檢驗啟動服務請求和服務卡的合法性,若合法則啟動服務。

1.4優點

1)性能較高

一旦Client獲得用於訪問某個Server的票據,則該Server就能根據票據實現對Client的驗證,不再需要KDC(身份認證機制)的參與

2)實現了雙向驗證(Mutual Authentication)

傳統的NTLM認證基於這樣一個前提:Client訪問的遠程的Service是可信的、無需對於進行驗證,所以NTLM不曾提供雙向驗證的功能————這顯然有點理想主義,為此Kerberos彌補了這個不足:Client在訪問Server的資源之前,可以要求對Server的身份執行認證。

3)互操作性(Interoperability)

Kerberos最初由MIT首創,現在已經成為一行被廣泛接受的標準。所以對於不同的平臺可以進行廣泛的互操作。

1.5 缺點
1)Kerberos身份認證採用的是對稱加密機制,加密和解密使用相同的密鑰,安全性有所降低
2)Kerberos中身份認證服務和票據授權服務是集中式管理的,容易形成瓶頸,且系統的性能和安全性也過分依賴於這兩個服務的性能和安全。

二、在Kerberos服務端,查詢KDC的配置文件

涉及加密方式的信息如下
master_key_type = des3-hmac-sha1
用於控制加密主體數據庫中各項的主密鑰的加密類型

supported_enctypes = aes256-cts:normal arcfour-hmac:normal
des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm
des:onlyrealm des:afs3

supported_enctypes將指定 kadmin addprinc
在為特定領域創建主體時使用的加密類型的缺省集。如果 Kerberos 領域中的大多數系統都支持缺省加密類型集的子集,則應使用 supported_enctypes 參數
詳細解釋參考 https://docs.oracle.com/cd/E19253-01/819-7061/6n91j2ver/index.html

三、配置服務端時步驟3涉及語句的含義

步驟3.添加主體principal

# sudo kadmin.local

進入kerberos管理頁面,有兩種方式:
在Krb5 server所在機器並且當前用戶是root的話,可以使用kadmin.local免密碼進入;當前用戶是非root用戶或在其他機器上時,可以使用kadmin $admin_user進入,需要輸入此admin用戶的密碼

kadmin.local: addprinc admin/admin

添加 principal:admin,這裡之後要輸入兩次密碼,用於客戶端登錄

kadmin.local: ktadd -k /etc/kadm5.keytab kadmin/admin kadmin/changepw

kadmin: ktadd [-e enctype] [-k keytab] [-q] [principal | -glob principal-exp]
將服務主體添加至密鑰表文件
本命令行中,kadmin/admin 和 kadmin/changepw 主體被添加至主 KDC 的密鑰表文件。對於該示例,密鑰表文件必須是在 kdc.conf 文件中指定的文件。

kadmin.local: addprinc -randkey ftp/服務器域名	

addprinc [options] <new_principal>
-randkey
為新添加的principal生成一個隨機密碼。注意如果為principal生成一個隨機密碼,那麼必須要將生成的隨機密碼放在keytab文件中才能使用

kadmin.local: ktadd -k /etc/ftp.keytab ftp/服務器域名

同上,將ftp/服務器域名 添加至ftp.keytab

kadmin.local: quit

退出kadmin

更多內容參考docs.oracle.com/cd/E19683-0…

四、客戶端和服務端輸入klist命令,說明輸出結果及其含義

客戶端忘記截圖
服務端截圖如下

網絡身份認證——Kerberos配置及認證

實際上二者並沒有什麼太大的區別

Klist用於顯示 Kerberos 憑證高速緩存或密鑰表的內容,可以理解為查看當前會話狀態。在不輸入任何參數的時候,表示列出在缺省憑證高速緩存中的所有條目。

實驗遇到的問題及解決方案

實驗過程中在服務端和客戶端都出現了問題,分別羅列如下:

1. 服務端

1.1在配置環境中間出錯,不小心在客戶端輸入服務端的配置內容
使用sudo apt-get autoremove --purge krb5-kdc krb5-admin-server卸載重裝。

1.2 按照步驟走完之後多次出現can not connect 的報錯_
之後又出現
kinit:資源暫時不可用while getting initial credentials
的報錯,但是ping 得通
報錯如圖

網絡身份認證——Kerberos配置及認證

經過一系列掙扎,在即將放棄的時候發現,需要對__krb5.conf__文件進行修改,先在__[libdefaults]中設置__default_realm = realm_janet129
然後在__[domain_realm]__中設置自己的domain

最後在hosts中添加一行
192.168.145.129 realm_janet129 janet
IP地址+服務器域名+主機名

2.客戶端

問題與服務端大致相同,但修改的位置不太一樣
修改hosts之後,找不到目標服務器

一番商討之後,我覺得應該是初始安裝的時候,沒有要我配置服務器域名等初始設置導致的,這個步驟被忽略的主要原因,懷疑是之前卸載的時候沒有卸載完全,內存或硬盤中還有對應配置的緩存,所以按照之前的配置方式走了。

在__conf__文件中修改兩步:

 [libdefaults]
default_realm = realm_janet129

以及__[realms]__中添加屬於自己服務器的配置內容

[realms]	
realm_janet129 = {
kdc = janet
admin_server = janet
}
···

相關文章

數據庫實驗4:JDBC&ODBC

C++期末大作業圖書評論和推薦系統

C++課大作業魔獸世界Part2

數據庫實驗3數據定義語言DDL