轉載自:http://www.cnblogs.com/artech/archive/2007/07/05/807492.html
前幾天在給人解釋Windows是如何通過Kerberos進行Authentication的時候，講了半天也別把那位老兄講明白，還差點把自己給繞進去。后來想想原因有以下兩點：對于一個沒有完全不了解Kerberos的人來說，Kerberos的整個Authentication過程確實不好理解——一會兒以這個Key進行加密、一會兒又要以另一個Key進行加密，確實很容易把人給弄暈；另一方面是我講解方式有問題，一開始就從Kerberos的3個Sub-protocol全面講述整個Authentication 過程，對于一個完全不了解Kerberos的人來說要求也忒高了點。為此，我花了一些時間寫了這篇文章，盡量以由淺入深、層層深入的方式講述我所理解的基于Kerberos的Windows Network Authentication，希望這篇文章能幫助那些對Kerberos不明就里的人帶來一絲幫助。對于一些不對的地方，歡迎大家批評指正。
一、 基本原理
Authentication解決的是“如何證明某個人確確實實就是他或她所聲稱的那個人”的問題。對于如何進行Authentication，我們采用這樣的方法：如果一個秘密（secret）僅僅存在于A和B，那么有個人對B聲稱自己就是A，B通過讓A提供這個秘密來證明這個人就是他或她所聲稱的A。這個過程實際上涉及到3個重要的關于Authentication的方面：
-
Secret如何表示。
-
A如何向B提供Secret。
-
B如何識別Secret。
基于這3個方面，我們把Kerberos Authentication進行最大限度的簡化：整個過程涉及到Client和Server，他們之間的這個Secret我們用一個Key（KServer-Client）來表示。Client為了讓Server對自己進行有效的認證，向對方提供如下兩組信息：
由于KServer-Client僅僅被Client和Server知曉，所以被Client使用KServer-Client加密過的Client Identity只能被Client和Server解密。同理，Server接收到Client傳送的這兩組信息，先通過KServer-Client對后者進行解密，隨后將機密的數據同前者進行比較，如果完全一樣，則可以證明Client能過提供正確的KServer-Client，而這個世界上，僅僅只有真正的Client和自己知道KServer-Client，所以可以對方就是他所聲稱的那個人。
Keberos大體上就是按照這樣的一個原理來進行Authentication的。但是Kerberos遠比這個復雜，我將在后續的章節中不斷地擴充這個過程，知道Kerberos真實的認證過程。為了使讀者更加容易理解后續的部分，在這里我們先給出兩個重要的概念：
在一般情況下，對于一個Account來說，密碼往往僅僅限于該Account的所有者知曉，甚至對于任何Domain的Administrator，密碼仍然應該是保密的。但是密碼卻又是證明身份的憑據，所以必須通過基于你密碼的派生的信息來證明用戶的真實身份，在這種情況下，一般將你的密碼進行Hash運算得到一個Hash code, 我們一般管這樣的Hash Code叫做Master Key。由于Hash Algorithm是不可逆的，同時保證密碼和Master Key是一一對應的，這樣既保證了你密碼的保密性，有同時保證你的Master Key和密碼本身在證明你身份的時候具有相同的效力。
二、引入Key Distribution: KServer-Client從何而來
上面我們討論了Kerberos Authentication的基本原理：通過讓被認證的一方提供一個僅限于他和認證方知曉的Key來鑒定對方的真實身份。而被這個Key加密的數據包需要在Client和Server之間傳送，所以這個Key不能是一個Long-term Key，而只可能是Short-term Key，這個可以僅僅在Client和Server的一個Session中有效，所以我們稱這個Key為Client和Server之間的Session Key（SServer-Client）。
現在我們來討論Client和Server如何得到這個SServer-Client。在這里我們要引入一個重要的角色：Kerberos Distribution Center-KDC。KDC在整個Kerberos Authentication中作為Client和Server共同信任的第三方起著重要的作用，而Kerberos的認證過程就是通過這3方協作完成。順便說一下，Kerberos起源于希臘神話，是一支守護著冥界長著3個頭顱的神犬，在keberos Authentication中，Kerberos的3個頭顱代表中認證過程中涉及的3方：Client、Server和KDC。
對于一個Windows Domain來說，Domain Controller扮演著KDC的角色。KDC維護著一個存儲著該Domain中所有帳戶的Account Database（一般地，這個Account Database由AD來維護），也就是說，他知道屬于每個Account的名稱和派生于該Account Password的Master Key。而用于Client和Server相互認證的SServer-Client就是有KDC分發。下面我們來看看KDC分發SServer-Client的過程。
通過下圖我們可以看到KDC分發SServer-Client的簡單的過程：首先Client向KDC發送一個對SServer-Client的申請。這個申請的內容可以簡單概括為“我是某個Client，我需要一個Session Key用于訪問某個Server ”。KDC在接收到這個請求的時候，生成一個Session Key，為了保證這個Session Key僅僅限于發送請求的Client和他希望訪問的Server知曉，KDC會為這個Session Key生成兩個Copy，分別被Client和Server使用。然后從Account database中提取Client和Server的Master Key分別對這兩個Copy進行對稱加密。對于后者，和Session Key一起被加密的還包含關于Client的一些信息。
KDC現在有了兩個分別被Client和Server 的Master Key加密過的Session Key，這兩個Session Key如何分別被Client和Server獲得呢？也許你 馬上會說，KDC直接將這兩個加密過的包發送給Client和Server不就可以了嗎，但是如果這樣做，對于Server來說會出現下面 兩個問題：
-
由于一個Server會面對若干不同的Client, 而每個Client都具有一個不同的Session Key。那么Server就會為所有的Client維護這樣一個Session Key的列表，這樣做對于Server來說是比較麻煩而低效的。
-
由于網絡傳輸的不確定性，可能出現這樣一種情況：Client很快獲得Session Key，并將這個Session Key作為Credential隨同訪問請求發送到Server，但是用于Server的Session Key確還沒有收到，并且很有可能承載這個Session Key的永遠也到不了Server端，Client將永遠得不到認證。
為了解決這個問題，Kerberos的做法很簡單，將這兩個被加密的Copy一并發送給Client，屬于Server的那份由Client發送給Server。
可能有人會問，KDC并沒有真正去認證這個發送請求的Client是否真的就是那個他所聲稱的那個人，就把Session Key發送給他，會不會有什么問題？如果另一個人（比如Client B）聲稱自己是Client A，他同樣會得到Client A和Server的Session Key，這會不會有什么問題？實際上不存在問題，因為Client B聲稱自己是Client A，KDC就會使用Client A的Password派生的Master Key對Session Key進行加密，所以真正知道Client A 的Password的一方才會通過解密獲得Session Key。
三、引入Authenticator - 為有效的證明自己提供證據
通過上面的過程，Client實際上獲得了兩組信息：一個通過自己Master Key加密的Session Key，另一個被Sever的Master Key加密的數據包，包含Session Key和關于自己的一些確認信息。通過第一節，我們說只要通過一個雙方知曉的Key就可以對對方進行有效的認證，但是在一個網絡的環境中，這種簡單的做法是具有安全漏洞，為此,Client需要提供更多的證明信息，我們把這種證明信息稱為Authenticator，在Kerberos的Authenticator實際上就是關于Client的一些信息和當前時間的一個Timestamp（關于這個安全漏洞和Timestamp的作用，我將在后面解釋）。
在這個基礎上，我們再來看看Server如何對Client進行認證：Client通過自己的Master Key對KDC加密的Session Key進行解密從而獲得Session Key，隨后創建Authenticator（Client Info + Timestamp）并用Session Key對其加密。最后連同從KDC獲得的、被Server的Master Key加密過的數據包（Client Info + Session Key）一并發送到Server端。我們把通過Server的Master Key加密過的數據包稱為Session Ticket。
當Server接收到這兩組數據后，先使用他自己的Master Key對Session Ticket進行解密，從而獲得Session Key。隨后使用該Session Key解密Authenticator，通過比較Authenticator中的Client Info和Session Ticket中的Client Info從而實現對Client的認證。
為什么要使用Timestamp？
到這里，很多人可能認為這樣的認證過程天衣無縫：只有當Client提供正確的Session Key方能得到Server的認證。但是在現實環境中，這存在很大的安全漏洞。
我們試想這樣的現象：Client向Server發送的數據包被某個惡意網絡監聽者截獲，該監聽者隨后將數據包座位自己的Credential冒充該Client對Server進行訪問，在這種情況下，依然可以很順利地獲得Server的成功認證。為了解決這個問題，Client在Authenticator中會加入一個當前時間的Timestamp。
在Server對Authenticator中的Client Info和Session Ticket中的Client Info進行比較之前，會先提取Authenticator中的Timestamp，并同當前的時間進行比較，如果他們之間的偏差超出一個可以接受的時間范圍（一般是5mins），Server會直接拒絕該Client的請求。在這里需要知道的是，Server維護著一個列表，這個列表記錄著在這個可接受的時間范圍內所有進行認證的Client和認證的時間。對于時間偏差在這個可接受的范圍中的Client，Server會從這個這個列表中獲得最近一個該Client的認證時間，只有當Authenticator中的Timestamp晚于通過一個Client的最近的認證時間的情況下，Server采用進行后續的認證流程。
Time Synchronization的重要性
上述 基于Timestamp的認證機制只有在Client和Server端的時間保持同步的情況才有意義。所以保持Time Synchronization在整個認證過程中顯得尤為重要。在一個Domain中，一般通過訪問同一個Time Service獲得當前時間的方式來實現時間的同步。
雙向認證（Mutual Authentication）
Kerberos一個重要的優勢在于它能夠提供雙向認證：不但Server可以對Client 進行認證，Client也能對Server進行認證。
具體過程是這樣的，如果Client需要對他訪問的Server進行認證，會在它向Server發送的Credential中設置一個是否需要認證的Flag。Server在對Client認證成功之后，會把Authenticator中的Timestamp提出出來，通過Session Key進行加密，當Client接收到并使用Session Key進行解密之后，如果確認Timestamp和原來的完全一致，那么他可以認定Server正式他試圖訪問的Server。
那么為什么Server不直接把通過Session Key進行加密的Authenticator原樣發送給Client，而要把Timestamp提取出來加密發送給Client呢？原因在于防止惡意的監聽者通過獲取的Client發送的Authenticator冒充Server獲得Client的認證。
四、引入Ticket Granting Service
通過上面的介紹，我們發現Kerberos實際上一個基于Ticket的認證方式。Client想要獲取Server端的資源，先得通過Server的認證；而認證的先決條件是Client向Server提供從KDC獲得的一個有Server的Master Key進行加密的Session Ticket（Session Key + Client Info）。可以這么說，Session Ticket是Client進入Server領域的一張門票。而這張門票必須從一個合法的Ticket頒發機構獲得，這個頒發機構就是Client和Server雙方信任的KDC， 同時這張Ticket具有超強的防偽標識：它是被Server的Master Key加密的。對Client來說， 獲得Session Ticket是整個認證過程中最為關鍵的部分。
上面我們只是簡單地從大體上說明了KDC向Client分發Ticket的過程，而真正在Kerberos中的Ticket Distribution要復雜一些。為了更好的說明整個Ticket Distribution的過程，我在這里做一個類比。現在的股事很火爆，上海基本上是全民炒股，我就舉一個認股權證的例子。有的上市公司在股票配股、增發、基金擴募、股份減持等情況會向公眾發行認股權證，認股權證的持有人可以憑借這個權證認購一定數量的該公司股票，認股權證是一種具有看漲期權的金融衍生產品。
而我們今天所講的Client獲得Ticket的過程也和通過認股權證購買股票的過程類似。如果我們把Client提供給Server進行認證的Ticket比作股票的話，那么Client在從KDC那邊獲得Ticket之前，需要先獲得這個Ticket的認購權證，這個認購權證在Kerberos中被稱為TGT：Ticket Granting Ticket，TGT的分發方仍然是KDC。
我們現在來看看Client是如何從KDC處獲得TGT的：首先Client向KDC發起對TGT的申請，申請的內容大致可以這樣表示：“我需要一張TGT用以申請獲取用以訪問所有Server的Ticket”。KDC在收到該申請請求后，生成一個用于該Client和KDC進行安全通信的Session Key（SKDC-Client）。為了保證該Session Key僅供該Client和自己使用，KDC使用Client的Master Key和自己的Master Key對生成的Session Key進行加密，從而獲得兩個加密的SKDC-Client的Copy。對于后者，隨SKDC-Client一起被加密的還包含以后用于鑒定Client身份的關于Client的一些信息。最后KDC將這兩份Copy一并發送給Client。這里有一點需要注意的是：為了免去KDC對于基于不同Client的Session Key進行維護的麻煩，就像Server不會保存Session Key（SServer-Client）一樣，KDC也不會去保存這個Session Key（SKDC-Client），而選擇完全靠Client自己提供的方式。
當Client收到KDC的兩個加密數據包之后，先使用自己的Master Key對第一個Copy進行解密，從而獲得KDC和Client的Session Key（SKDC-Client），并把該Session 和TGT進行緩存。有了Session Key和TGT，Client自己的Master Key將不再需要，因為此后Client可以使用SKDC-Client向KDC申請用以訪問每個Server的Ticket，相對于Client的Master Key這個Long-term Key，SKDC-Client是一個Short-term Key，安全保證得到更好的保障，這也是Kerberos多了這一步的關鍵所在。同時需要注意的是SKDC-Client是一個Session Key，他具有自己的生命周期，同時TGT和Session相互關聯，當Session Key過期，TGT也就宣告失效，此后Client不得不重新向KDC申請新的TGT，KDC將會生成一個不同Session Key和與之關聯的TGT。同時，由于Client Log off也導致SKDC-Client的失效，所以SKDC-Client又被稱為Logon Session Key。
接下來，我們看看Client如何使用TGT來從KDC獲得基于某個Server的Ticket。在這里我要強調一下，Ticket是基于某個具體的Server的，而TGT則是和具體的Server無關的，Client可以使用一個TGT從KDC獲得基于不同Server的Ticket。我們言歸正傳，Client在獲得自己和KDC的Session Key（SKDC-Client）之后，生成自己的Authenticator以及所要訪問的Server名稱的并使用SKDC-Client進行加密。隨后連同TGT一并發送給KDC。KDC使用自己的Master Key對TGT進行解密，提取Client Info和Session Key（SKDC-Client），然后使用這個SKDC-Client解密Authenticator獲得Client Info，對兩個Client Info進行比較進而驗證對方的真實身份。驗證成功，生成一份基于Client所要訪問的Server的Ticket給Client，這個過程就是我們第二節中介紹的一樣了。
五、Kerberos的3個Sub-protocol：整個Authentication
通過以上的介紹，我們基本上了解了整個Kerberos authentication的整個流程：整個流程大體上包含以下3個子過程：
-
Client向KDC申請TGT（Ticket Granting Ticket）。
-
Client通過獲得TGT向DKC申請用于訪問Server的Ticket。
-
Client最終向為了Server對自己的認證向其提交Ticket。
不過上面的介紹離真正的Kerberos Authentication還是有一點出入。Kerberos整個認證過程通過3個sub-protocol來完成。這個3個Sub-Protocol分別完成上面列出的3個子過程。這3個sub-protocol分別為：
-
Authentication Service Exchange
-
Ticket Granting Service Exchange
-
Client/Server Exchange
下圖簡單展示了完成這個3個Sub-protocol所進行Message Exchange。
1． Authentication Service Exchange
通過這個Sub-protocol，KDC（確切地說是KDC中的Authentication Service）實現對Client身份的確認，并頒發給該Client一個TGT。具體過程如下：
Client向KDC的Authentication Service發送Authentication Service Request（KRB_AS_REQ）, 為了確保KRB_AS_REQ僅限于自己和KDC知道，Client使用自己的Master Key對KRB_AS_REQ的主體部分進行加密（KDC可以通過Domain 的Account Database獲得該Client的Master Key）。KRB_AS_REQ的大體包含以下的內容：
-
Pre-authentication data：包含用以證明自己身份的信息。說白了，就是證明自己知道自己聲稱的那個account的Password。一般地，它的內容是一個被Client的Master key加密過的Timestamp。
-
Client name & realm: 簡單地說就是Domain name\Client
-
Server Name：注意這里的Server Name并不是Client真正要訪問的Server的名稱，而我們也說了TGT是和Server無關的（Client只能使用Ticket，而不是TGT去訪問Server）。這里的Server Name實際上是KDC的Ticket Granting Service的Server Name。
AS（Authentication Service）通過它接收到的KRB_AS_REQ驗證發送方的是否是在Client name & realm中聲稱的那個人，也就是說要驗證發送放是否知道Client的Password。所以AS只需從Account Database中提取Client對應的Master Key對Pre-authentication data進行解密，如果是一個合法的Timestamp，則可以證明發送放提供的是正確無誤的密碼。驗證通過之后，AS將一份Authentication Service Response（KRB_AS_REP）發送給Client。KRB_AS_REQ主要包含兩個部分：本Client的Master Key加密過的Session Key（SKDC-Client：Logon Session Key）和被自己（KDC）加密的TGT。而TGT大體又包含以下的內容：
Client通過自己的Master Key對第一部分解密獲得Session Key（SKDC-Client：Logon Session Key）之后，攜帶著TGT便可以進入下一步：TGS（Ticket Granting Service）Exchange。
2． TGS（Ticket Granting Service）Exchange
TGS（Ticket Granting Service）Exchange通過Client向KDC中的TGS（Ticket Granting Service）發送Ticket Granting Service Request（KRB_TGS_REQ）開始。KRB_TGS_REQ大體包含以下的內容：
-
TGT：Client通過AS Exchange獲得的Ticket Granting Ticket，TGT被KDC的Master Key進行加密。
-
Authenticator：用以證明當初TGT的擁有者是否就是自己，所以它必須以TGT的辦法方和自己的Session Key（SKDC-Client：Logon Session Key）來進行加密。
-
Client name & realm: 簡單地說就是Domain name\Client。
-
Server name & realm: 簡單地說就是Domain name\Server，這回是Client試圖訪問的那個Server。
TGS收到KRB_TGS_REQ在發給Client真正的Ticket之前，先得整個Client提供的那個TGT是否是AS頒發給它的。于是它不得不通過Client提供的Authenticator來證明。但是Authentication是通過Logon Session Key（SKDC-Client）進行加密的，而自己并沒有保存這個Session Key。所以TGS先得通過自己的Master Key對Client提供的TGT進行解密，從而獲得這個Logon Session Key（SKDC-Client），再通過這個Logon Session Key（SKDC-Client）解密Authenticator進行驗證。驗證通過向對方發送Ticket Granting Service Response（KRB_TGS_REP）。這個KRB_TGS_REP有兩部分組成：使用Logon Session Key（SKDC-Client）加密過用于Client和Server的Session Key（SServer-Client）和使用Server的Master Key進行加密的Ticket。該Ticket大體包含以下一些內容：
Client收到KRB_TGS_REP，使用Logon Session Key（SKDC-Client）解密第一部分后獲得Session Key（SServer-Client）。有了Session Key和Ticket，Client就可以之間和Server進行交互，而無須在通過KDC作中間人了。所以我們說Kerberos是一種高效的認證方式，它可以直接通過Client和Server雙方來完成，不像Windows NT 4下的NTLM認證方式，每次認證都要通過一個雙方信任的第3方來完成。
我們現在來看看 Client如果使用Ticket和Server怎樣進行交互的，這個階段通過我們的第3個Sub-protocol來完成：CS（Client/Server ）Exchange。
3． CS（Client/Server ）Exchange
這個已經在本文的第二節中已經介紹過，對于重復發內容就不再累贅了。Client通過TGS Exchange獲得Client和Server的Session Key（SServer-Client），隨后創建用于證明自己就是Ticket的真正所有者的Authenticator，并使用Session Key（SServer-Client）進行加密。最后將這個被加密過的Authenticator和Ticket作為Application Service Request（KRB_AP_REQ）發送給Server。除了上述兩項內容之外，KRB_AP_REQ還包含一個Flag用于表示Client是否需要進行雙向驗證（Mutual Authentication）。
Server接收到KRB_AP_REQ之后，通過自己的Master Key解密Ticket，從而獲得Session Key（SServer-Client）。通過Session Key（SServer-Client）解密Authenticator，進而驗證對方的身份。驗證成功，讓Client訪問需要訪問的資源，否則直接拒絕對方的請求。
對于需要進行雙向驗證，Server從Authenticator提取Timestamp，使用Session Key（SServer-Client）進行加密，并將其發送給Client用于Client驗證Server的身份。
六、User2User Sub-Protocol：有效地保障Server的安全
通過3個Sub-protocol的介紹，我們可以全面地掌握整個Kerberos的認證過程。實際上，在Windows 2000時代，基于Kerberos的Windows Authentication就是按照這樣的工作流程來進行的。但是我在上面一節結束的時候也說了，基于3個Sub-protocol的Kerberos作為一種Network Authentication是具有它自己的局限和安全隱患的。我在整篇文章一直在強調這樣的一個原則：以某個Entity的Long-term Key加密的數據不應該在網絡中傳遞。原因很簡單，所有的加密算法都不能保證100%的安全，對加密的數據進行解密只是一個時間的過程，最大限度地提供安全保障的做法就是：使用一個Short-term key（Session Key）代替Long-term Key對數據進行加密，使得惡意用戶對其解密獲得加密的Key時，該Key早已失效。但是對于3個Sub-Protocol的C/S Exchange，Client攜帶的Ticket卻是被Server Master Key進行加密的，這顯現不符合我們提出的原則，降低Server的安全系數。
所以我們必須尋求一種解決方案來解決上面的問題。這個解決方案很明顯：就是采用一個Short-term的Session Key，而不是Server Master Key對Ticket進行加密。這就是我們今天要介紹的Kerberos的第4個Sub-protocol：User2User Protocol。我們知道，既然是Session Key，僅必然涉及到兩方，而在Kerberos整個認證過程涉及到3方：Client、Server和KDC，所以用于加密Ticket的只可能是Server和KDC之間的Session Key（SKDC-Server）。
我們知道Client通過在AS Exchange階段獲得的TGT從KDC那么獲得訪問Server的Ticket。原來的Ticket是通過Server的Master Key進行加密的，而這個Master Key可以通過Account Database獲得。但是現在KDC需要使用Server和KDC之間的SKDC-Server進行加密，而KDC是不會維護這個Session Key，所以這個Session Key只能靠申請Ticket的Client提供。所以在AS Exchange和TGS Exchange之間，Client還得對Server進行請求已獲得Server和KDC之間的Session Key（SKDC-Server）。而對于Server來說，它可以像Client一樣通過AS Exchange獲得他和KDC之間的Session Key（SKDC-Server）和一個封裝了這個Session Key并被KDC的Master Key進行加密的TGT，一旦獲得這個TGT，Server會緩存它，以待Client對它的請求。我們現在來詳細地討論這一過程。
上圖基本上翻譯了基于User2User的認證過程，這個過程由4個步驟組成。我們發現較之我在上面一節介紹的基于傳統3個Sub-protocol的認證過程，這次對了第2部。我們從頭到尾簡單地過一遍：
-
AS Exchange：Client通過此過程獲得了屬于自己的TGT，有了此TGT，Client可憑此向KDC申請用于訪問某個Server的Ticket。
-
這一步的主要任務是獲得封裝了Server和KDC的Session Key（SKDC-Server）的屬于Server的TGT。如果該TGT存在于Server的緩存中，則Server會直接將其返回給Client。否則通過AS Exchange從KDC獲取。
-
TGS Exchange：Client通過向KDC提供自己的TGT，Server的TGT以及Authenticator向KDC申請用于訪問Server的Ticket。KDC使用先用自己的Master Key解密Client的TGT獲得SKDC-Client，通過SKDC-Client解密Authenticator驗證發送者是否是TGT的真正擁有者，驗證通過再用自己的Master Key解密Server的TGT獲得KDC和Server 的Session Key（SKDC-Server），并用該Session Key加密Ticket返回給Client。
-
C/S Exchange：Client攜帶者通過KDC和Server 的Session Key（SKDC-Server）進行加密的Ticket和通過Client和Server的Session Key（SServer-Client）的Authenticator訪問Server，Server通過SKDC-Server解密Ticket獲得SServer-Client，通過SServer-Client解密Authenticator實現對Client的驗證。
這就是整個過程。
七、Kerberos的優點
分析整個Kerberos的認證過程之后，我們來總結一下Kerberos都有哪些優點：
1．較高的Performance
雖然我們一再地說Kerberos是一個涉及到3方的認證過程：Client、Server、KDC。但是一旦Client獲得用過訪問某個Server的Ticket，該Server就能根據這個Ticket實現對Client的驗證，而無須KDC的再次參與。和傳統的基于Windows NT 4.0的每個完全依賴Trusted Third Party的NTLM比較，具有較大的性能提升。
2．實現了雙向驗證（Mutual Authentication）
傳統的NTLM認證基于這樣一個前提：Client訪問的遠程的Service是可信的、無需對于進行驗證，所以NTLM不曾提供雙向驗證的功能。這顯然有點理想主義，為此Kerberos彌補了這個不足：Client在訪問Server的資源之前，可以要求對Server的身份執行認證。
3．對Delegation的支持
Impersonation和Delegation是一個分布式環境中兩個重要的功能。Impersonation允許Server在本地使用Logon 的Account執行某些操作，Delegation需用Server將logon的Account帶入到另過一個Context執行相應的操作。NTLM僅對Impersonation提供支持，而Kerberos通過一種雙向的、可傳遞的（Mutual 、Transitive）信任模式實現了對Delegation的支持。
4．互操作性（Interoperability）
Kerberos最初由MIT首創，現在已經成為一行被廣泛接受的標準。所以對于不同的平臺可以進行廣泛的互操作。