教材：《資訊系統安全概論》
實驗目的
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認證機制如圖
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命令，說明輸出結果及其含義
客戶端忘記截圖
服務端截圖如下
實際上二者並沒有什麼太大的區別
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 得通
報錯如圖
經過一系列掙扎，在即將放棄的時候發現，需要對__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
}
···
複製程式碼