Kerberos 在 Windows 的應用

更新日期: 2005 年 8 月 19 日

作者:賴榮樞
http://www.goodman-lai.idv.tw

Kerberos 是公開的安全認證標準,Kerberos 第五版是 IETF 組織管轄的公開標準,Windows 2000 Server 及 Windows Server 2003 等 Windows 伺服器是根據 RFC 1510 實作 Kerberos 協定,而傳送 Kerberos 訊息裡的 token,則是根據 RFC 1964 實作。微軟將這項標準應用在 Windows 2000 Server 及 Windows Server 2003 等伺服器平台,當作桌面系統與伺服器、伺服器與伺服器之間的認證(authentication)協定。

本頁內容

執行 Kerberos 的需求
Windows 與 Kerberos
本機登入
跨網域認證
使用者權限
加密演算法
其他的認證方法
Kerberos 的優點

執行 Kerberos 的需求

微軟是從 Windows 2000(包括 Server 版和 Workstation 版)開始加入 Kerberos 功能,隨後的 Windows XP 和 Windows Server 2003 也都支援 Kerberos 協定;也就是說,上述 Windows 版本已經內建支援 Kerberos,其他較舊的 Windows 並無內建 Kerberos 的支援。而 Kerberos 是用於安全認證的協定,在其底層,則必須以 TCP/IP 作為通訊基礎。此外,因為用戶端是以 FQDN(fully qualified domain name)來存取網域控制器,因此網路內必須有 DNS 伺服器讓用戶端取得 FQDN。

Windows 伺服器的網域與 Kerberos 的 Realm 大體上可視為相同的範疇;在實作上,網域的每台網域主控器皆提供金鑰中心(Key Distributed Center)的服務,可以負責網域中所需要的安全認證功能,而相關的帳號資訊,皆儲存在 Active Directory 目錄服務資料庫。也就是說金鑰中心是以 Active Directory 目錄服務資料庫當作安全帳號資料庫,而帳號資料會隨著 Active Directory 的複製,同步儲存在網域中的網域主控器。這代表著必須以 Active Directory 目錄服務的使用者帳號和電腦帳號才能使用 Kerberos 協定,本機帳號和 Windows NT 網域帳號將無法利用 Kerberos 認證。

為了能正確執行 Kerberos,網路內所有的網域和樹系(forest)的時間都必須同步,而 Active Directory 的網域控制器可以擔任時間伺服器,確保整個網域的時間都已同步。此外,Windows 伺服器所執行的服務如果要以 Kerberos 提供認證功能,該服務必須設定過 SPN(Service principal names),否則用戶端將無法在網路裡找到服務,而且如果沒有正確的設定服務的 SPN,Kerberos 也無法運作。以下表格列出了 Windows 系統內建的 SPN。

alerter

http

policyagent

scm

appmgmt

ias

protectedstorage

seclogon

browser

iisad

rasman

snmp

cifs

min

remoteaccess

spooler

cisvc

messenger

replicator

tapisrv

clipsrv

msiserver

rpc

time

dcom

mcsvc

rpclocator

trksvr

dhcp

netdde

rpcss

trkwks

dmserver

netddedsm

rsvp

ups

dns

netlogon

samss

w3svc

dnscache

netman

scardsvr

wins

eventlog

nmagent

scesrv

www

eventsystem

oakley

schedule

 

fax

plugplay

 

 

Windows 與 Kerberos

Kerberos 認證的 Windows 用戶端與伺服端之間有一層「安全支援提供者介面」(security support provider interface,SSPI),而伺服端或用戶端被實作成「安全支援提供者」(security support provider,SSP),並且可以透過 SSPI 加以存取。而 SSP 實際是由 Windows Server 2003 系統所提供的動態連結程式庫(dynamic-link library,DLL),檔名為 Kerberos.dll;而Windows Server 2003 會以 SSP 作為認證的首選。

不過舊版的 Windows只能以 NTLM 認證,因此為了能與這類不支援 Kerberos 的 Windows 相容,Windows Server 2003 也提供了 SSP for NTLM 的認證方式。在預設的情況下,Windows Server 2003 開機時,「本地安全授權」(Local Security Authority,LSA) 會同時將 SSP for Kerberos 和 SSP for NTLM 載入系統,因此 Windows Server 2003 可以視情況擇一進行認證。

也因為 Windows Server 2003 會優先使用 Kerberos 作為認證協定,因此所有與網域相關的服務,都會支援 Kerberos SSP,相關的服務包括了:

  • 用戶端與伺服端之間的認證。

  • 要求使用 LDAP 的 Active Directory 目錄服務。

  • 以遠端程序呼叫管理的伺服器或工作站。

  • 列印服務。

  • 使用 CIFS/SMB(Common Internet File System/server message block)的遠端檔案存取。

  • 分散式檔案系統的管理。

  • IPSec 的安全認證。

  • 網域使用者、電腦的憑證服務。

本機登入

所謂本機登入,指的是使用者坐在電腦前,直接輸入帳號與密碼,供相關金鑰中心認證其身份的過程。如果依照前述設定了正確的 Kerberos 執行環境,使用者就可以透過本機登入認證伺服器,同樣的,伺服器也可以認證用戶端。本機登入時主要的動作有三:

  1. 使用者與金鑰中心先進行認證的動作,隨後金鑰中心核發 TGT 給使用者。這就是先前所提到的 AS Exchange。

  2. 使用者利用 TGT 向金鑰中心取得本機電腦的 Ticket。這就是先前所提到的 TGS Exchange。

  3. 使用者再利用 Ticket 登入本機電腦 (CS Exchange)。

圖 1:Kerberos 規格所定義的六種 Exchange(也稱為子協定)在本機登入時的作用及順序

圖 1:Kerberos 規格所定義的六種 Exchange(也稱為子協定)在本機登入時的作用及順序

以下假設用戶端要從電腦 Comp 登入網域 DomainX (用戶端與 Comp 的帳號皆在 DomainX 中),並詳細說明認證的各項步驟:

  1. 用戶端在 Comp 的登入畫面中,輸入使用者名稱、密碼,並指定要登入 DomainX 網域。這些資訊會傳送到 LSA。

  2. LSA 利用雜湊函數將用戶端的密碼轉為秘鑰 Kclt,並利用 Kclt 來建立 Authenticator,連同一些明文資訊一起放入 KRB_AS_REQ 訊息中,傳送給 DomainX 中的金鑰中心(開始AS認證):

    KRB_AS_REQ:"用戶端, DomainX", Authenticator

  3. DomainX 中的金鑰中心收到 KRB_AS_REQ 之後,可從自身的安全資料庫中找出用戶端的密碼,利用雜湊函數計算得出 Kclt。金鑰中心再利用 Kclt 來解密 KRB_AS_REQ 中的 Authenticator,並藉此確認用戶端的身份。

  4. 金鑰中心建立兩把相同的 Kclt-kdc(用戶端與金鑰中心之間的 Session Key),供用戶端與金鑰中心在後續作業中建立認證與加密之用。其中一把金鑰稍後交由用戶端保管,另一把金鑰則會放入用戶端的 TGT 中。TGT 是由金鑰中心專屬的金鑰 Kkdc 加密而成,其內容除了包含 Kclt-kdc 之外,還會加上用戶端的各項權限資訊:

    TGT:{用戶端的權限資訊, Kclt-kdc}Kkdc

  5. 金鑰中心建立 KRB_AS_REP 訊息後傳送給 Comp 的 LSA。KRB_AS_REP 的內容如下:

    KRB_AS_REP:{Kclt-kdc}Kclt, TGT

  6. LSA 利用 Kclt 可解開 KRB_AS_REP 以 Kclt 加密的部份,進而取得 Kclt-kdc。步驟進行至此,即完成 AS 的全部認證動作。至此,用戶端端與金鑰中心端目前所擁有的項目包括了:

    • 用戶端取得一把 Kclt-kdc(用戶端與金鑰中心之間的 Session Key),用來在後續作業中向金鑰中心申請Ticket。

    • 用戶端取得 TGT,用來在後續作業中向金鑰中心申請 Ticket。

    • 用戶端不用再保留由密碼所建立的 Kclt,因此立即將之摧毀。

    • 金鑰中心不用再保留由密碼所建立的 Kclt,因此立即將之摧毀。

    • 金鑰中心在開始時只有一把自己專屬的秘鑰 Kkdc,在 AS 結束時仍舊是只有一把 Kkdc。

  7. (繼續登入步驟)完成 AS 認證後,LSA 接著要先向金鑰中心申請 Comp 的 Ticket,以便讓用戶端登入 Comp(開始 TGS 程序)。LSA 建立 KRB_TGS_REQ 訊息傳送給金鑰中心:

    KRB_TGS_REQ:"Comp, DomainX", TGT, {用戶端相關資訊} Kclt-kdc

  8. 金鑰中心利用本身所擁有的 Kkdc 解開 TGT,進而取得 Kclt-kdc。金鑰中心利用 Kclt-kdc 確認用戶端的身份。

  9. 金鑰中心建立兩把相同的 Kclt-comp(用戶端與 Comp 之間的 Session Key),以及登入 Comp 所需的 Ticket。Ticket 是由金鑰中心與 Comp 共享的秘鑰 Kcomp 加密而成,其內容如下:

    Ticket:{用戶端的權限資訊, Kclt-comp}Kcomp

  10. 金鑰中心建立 KRB_TGS_REP 傳送給 LSA:

    KRB_TGS_REP:{Kclt-comp}Kclt-kdc, Ticket

  11. LSA 收到上述訊息後,利用 Kclt-kdc 解開 KRB_TGS_REP 訊息中以 Kclt-kdc 加密的部份,進行取得 Kclt-comp。步驟進行至此,即完成 TGS 申請 Ticket 的全部動作。讓我們再檢視一下用戶端端與金鑰中心端目前所擁有的項目:

    • 用戶端仍舊保有 Kclt-kdc 與 TGT。

    • 用戶端取得一把 Kclt-comp (用戶端與 Comp 之間的 Session Key),用來在後續作業中與 Comp 建立認證與加密。

    • 用戶端取得 Comp 的 Ticket,用來在後續作業中與 Comp 建立認證與加密。

    • 金鑰中心維持原來的樣子。

  12. LSA 接著便使用從 KRB_TGS_REP 所得的 Kclt-comp 與 Ticket,讓用戶端登入 Comp(開始 CS 的程序)。LSA 接著會根據 Comp 的 SAM 資料庫中用戶端的權限,連同 Ticket 中用戶端的權限(來自於金鑰中心的用戶端權限記錄),共同建立用戶端的 access token,最後將此 token 傳回給 Winlogon。

跨網域認證

在 Windows 伺服器的網域架構中,父網域 (Parent domain) 與子網域 (Child domain) 之間預設皆為雙向信任關係。而建立信任關係的重點之一即是建立共同的秘鑰,使互信的兩個網域能共享秘鑰。在此前提下,可透過 Kerberos 來進行跨網域的認證。

此外,當用戶端進行跨網域認證時,可能需要透過好幾個金鑰中心才能和目的伺服端進行認證。如此,不僅會耗費較多的時間,也會佔用較多的網路資源。為了解決這個問題,網域架構加入了 Shortcut Trust (信任捷徑)的設計。也就是說,在網域樹 (Domain Treel) 中,除了預設垂直的信任關係外,管理員可以視需求,手動建立網域之間的信任關係,以提高認證的效率。

使用者權限

Kerberos 主要的功能是認證,雖然 Kerberos 也支援認證後的權限設定,但並未規定任何格式,而是開放給應用程式或系統自行規劃。用戶端的權限資訊在認證後會寫入 TGT,並在隨後複製到 Ticket 中。當用戶端拿著 Ticket 向伺服端認證,伺服端便能得知用戶端的權限。

用戶端的權限資訊包括其帳號與所屬安全群組、萬用群組的的各項 SID。帳號與安全群組的 SID 都存放在每台 Domain Controller 的 Active Directory 中,萬用群組的 SID 則存放在 Global Catalog 中。

此外,Kerberos 也可利用 TGT 來進行代理 (Delegation) 的功能。什麼是代理呢?舉例來說,在分散式資料庫的環境中,用戶端通常必須透過 middle-tier 的伺服器 (Server -mt) 來存取後端的資料庫 (Server -db)。所謂代理,就是指 Server -mt 能夠以用戶端的存取權限來存取 Server -db 上的資源。在實際的代理過程中,用戶端會將 TGT 與 Kclt-kdc(也就是用戶端與金鑰中心之間的 Session Key) 傳送給 Server -mt(Msg1)。Server-mt 再利用用戶端傳送過來的 TGT 與 Kclt-kdc 向金鑰中心申請 Server -db 的 Ticket(Msg2)。由於 TGT 記錄了用戶端的權限,因此金鑰中心會將用戶端的權限寫入 Ticket,然後再送回 Server-mt(Msg3)。最後 Server -mt 再拿著 Ticket 向 Server -db 進行認證 (Msg4)。整個代理的程序如下:

圖 2:代理程序

圖 2:代理程序

加密演算法

Kerberos 一般在實作時大部份都採用 DES 作為加密演算法。Windows Server System 支援 DES 與 RC4 兩種演算法,預設則使用 RC4。DES 是 NSA 制訂的官方標準,已行之有年。標準版的 DES 使用 56 位元的秘鑰 (實際運算時是以 64 位元為單位的 Block Cipher),近年來由於電腦運算能力大幅提升,56 位元的 DES 已經不算是很安全的方法了。至於 128 位元的 DES 雖然較為安全,但受制於美國法令,因此僅能在美國地區使用。RC4 則是 RSA Data Security Inc. 所開發的加密技術,目前公開的資料不多,只知道 RC4 使用 Stream Cipher (在加密演算時,是以 bit 或 byte 為單位,逐一進行運算)的技術,因此理論上運算速度會比 Block Cipher 加密法快。

其他的認證方法

Windows Server 2003 預設的認證方法為 Kerberos,但是為了相容或應用時機的不同,Windows Server 2003 也支援下列的認證方式:

  • NTLM:這是 Windows NT 4.0 預設的認證協定。若用戶端使用 Windows 95/98/NT 的系統,則允許用戶端使用 NTLM 來登入。

  • SSL:使用者透過 Internet 以瀏覽器來登入網域時,必須使用 SSL 的憑證 (Certificate) 功能,來確認 client 與 server 雙方的身份。

  • Smart Card:藉由 Smart Card 讀卡機,使用者不再是藉由帳號/密碼來確認身份,而是利用 Smart Card 來驗明正身。由於 Smart Card 本身的特性,在登入系統時必須使用非對稱式加密法(或稱公鑰加密法),與系統進行金鑰交換與證認的工作。因此之故,Microsoft 在實作 Kerberos 時,加入了非對稱式加密法的支援。非對稱式加密法僅應用在一開始登入時,Smart Card 與金鑰中心之間彼此交換資訊,以便建立共同的秘鑰。之後的認證架構,依舊是遵循對稱式加密法的原理。

Kerberos 的優點

Kerberos 第五版是比 NTLM 更安全、更彈性、更有效率的認證方式,尤其在使用 NTLM 認證的時候,伺服器必須先連上網域控制器才能認證每一個用戶端,效率上總是慢了一點。相較於 Kerberos,伺服器並不需要連上網域控制器,只要用戶端取得 Ticket,就可以在網路連線階段重複使用同一張 Ticket 來認證同一個用戶端。

Kerberos 是 IETF(Internet Engineering Task Force)的公開標準,Windows Server 2003 採用 Kerberos 作為認證協定,將能提高與其他系統的相容性。而 Kerberos 除了還具有代理認證的功能之外,也 Kerberos 不止能讓伺服端認證用戶端的身份,更可以讓用戶端認證伺服端的真實性,因此能提供更安全的網路環境。

顯示: