前言

上一篇結尾提到，SAML、OIDC 這類協定負責把「使用者已經通過身分驗證」這件事傳遞給 SP；但在很多企業環境中，背後真正保存帳號、群組、部門等身分資料，並負責使用者登入驗證的，仍然是 LDAP 與 Kerberos 這兩套更早出現的技術，尤其常見於 AD(Active Directory) 環境中。這篇就專門展開這兩個技術的分工，以及為什麼即使現在雲端 SaaS 應用程式盛行，許多企業仍然離不開 AD。

今天內容涵蓋:

1. LDAP 是什麼:目錄服務的協定
2. LDAP 的資料結構:Entry、DN、Attribute
3. LDAP 的常見操作
4. Active Directory:企業最常見的目錄服務實作
5. Kerberos:以票證為基礎的驗證協定
6. LDAP 與 Kerberos 在 AD 裡怎麼分工
7. 企業為什麼離不開 AD

一、LDAP 是什麼:目錄服務的協定

LDAP(Lightweight Directory Access Protocol，輕量級目錄存取協定)，是一種用來存取「目錄服務(Directory Service)」的應用層協定，1993 年發布，運作在 TCP/UDP 389 埠(加密版本 LDAPS 用 636 埠)。

目錄服務可以想成是一種專門拿來查詢的「資料庫」，裡面存放組織內的使用者、群組、電腦、印表機等資源的資訊，功能上很像電話簿——給一個名字，查出對應的號碼(或帳密、部門、Email 等屬性)。LDAP 的前身是 X.500 標準底下的 DAP(Directory Access Protocol)，但 DAP 建立在複雜的 OSI 通訊協定堆疊上，對當時剛興起的 TCP/IP 網路來說太重，所以 Tim Howes 等人在密西根大學做出一套更輕量、直接跑在 TCP/IP 上的替代方案，也就是 LDAP，因此有時也被稱為「X.500 Lite」。

LDAP 最常見的用途，就是提供一個中央位置存放帳號、群組與部門等資料，讓不同應用程式都能查詢同一份集中管理的身分資料，而不用各自維護一套帳號資料庫。這也補上了前幾天較少深入的部分：IdP 或系統本身，實際查詢使用者帳密與屬性時，可能就是透過 LDAP 這類目錄服務完成。

二、LDAP 的資料結構:Entry、DN、Attribute

LDAP 把資料組織成一棵樹狀目錄，樹上的每一個節點稱為一筆 Entry(項目)。核心概念如下:

• Entry:目錄樹上的一個節點，代表一個人、一個群組、一台電腦等實際物件，裡面包含一組屬性(Attribute)。
• Attribute:Entry 底下的屬性，有名稱與一個或多個值，例如 cn(Common Name，姓名)、mail(Email)、telephoneNumber(電話)。屬性的可用範圍由 Schema(綱要) 定義，不同用途的目錄(例如 Linux 帳號、Windows 帳號)會需要不同的 Schema。
• DN(Distinguished Name，識別名稱):每筆 Entry 在整棵樹上的唯一識別位置，概念上很像檔案系統的完整路徑。DN 由該節點自己的 RDN(Relative Distinguished Name) 加上父節點的 DN 組成。
• baseDN:整個目錄樹最頂層的 DN，是查詢、設定 LDAP 系統時第一個要定義的項目。

一筆 Entry 常用 LDIF(LDAP Data Interchange Format) 這種純文字格式表示，例如:

dn: cn=Gloria Chen,dc=example,dc=com
cn: Gloria Chen
givenName: Gloria
sn: Chen
mail: gloria@example.com
telephoneNumber: +1 888 555 6789
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person

上面這筆 Entry 可以這樣拆開來看:

• 第一行 dn: cn=Gloria Chen,dc=example,dc=com 是這筆 Entry 的識別名稱(DN)，也就是它在整棵目錄樹上的完整位置。
• 這個 DN 可以再拆成兩段:cn=Gloria Chen 是這筆 Entry 自己的 RDN(說明「這一節點叫什麼名字」);dc=example,dc=com 則是它父節點的 DN(這裡 dc 代表 Domain Component，對應到 example.com 這個網域)。就像檔案的完整路徑是「文件夹路徑 + 檔名」，這裡的 DN 就是「父節點的 DN + 自己的 RDN」。
• 除了 dn 這一行以外，其他每一行(cn、givenName、sn、mail 等)都是這筆 Entry 的屬性(Attribute)，用來描述這個人的實际資料。

三、LDAP 的常見操作

LDAP 定義了一套用戶端可以對目錄伺服器發出的操作，其中跟身份驗證最相關的是:

• Bind:用一組帳密(或憑證)向 LDAP 伺服器驗證身份，同時指定要用的協定版本。這就是應用程式拿使用者輸入的帳密去問「這個帳號存在嗎？密碼對不對？」的動作。
• Search:在目錄樹裡查詢、取回符合條件的 Entry，例如查某個使用者屬於哪個部門、群組。
• Compare:確認某個 Entry 是否帶有指定的屬性值，不需要把整筆資料取回來。
• Add / Delete / Modify:新增、刪除、修改一筆 Entry。
• Modify DN:搬移或重新命名一筆 Entry(改變它在樹上的位置)。
• Unbind:結束連線。

其中 Bind 是最常被拿來當「登入驗證」用的操作:應用程式收到使用者輸入的帳密後，直接拿去對 LDAP 伺服器發一個 Bind 請求，如果 Bind 成功，就代表帳密正確。這也是 Day04 提過的「LDAP 只負責核對帳密」的具體實作方式。

四、Active Directory:企業最常見的目錄服務實作

LDAP 本身只是一套協定，規範怎麼「跟目錄服務講話」，實際的目錄服務伺服器有很多種實作，企業環境最常見的就是 Microsoft 的 Active Directory(AD)——AD 就是一套以 LDAP 為基礎打造出來的目錄服務，這也是為什麼 LDAP 常常跟 AD 被放在一起講。除了 AD，Linux 陣營也有 OpenLDAP、389 Directory Server、FreeIPA 等實作。

AD 用一套分層的組織模型描述整個企業的身份資料，由大到小分別是:

• Forest(樹林):整個 AD 環境的最大範圍，由一個或多個 Tree 組成，通常對應到一整個公司或組織。
• Tree(樹):由一個或多個 Domain 組成，Domain 之間有連續的命名空間(例如同一個網域下的子網域)。
• Domain(網域):實際管理使用者、電腦、群組等物件的邊界，也是套用密碼原則、安全性設定的基本單位。
• OU(Organizational Unit，組織單位):Domain 底下用來分類物件的容器，可以把使用者、電腦依部門、地區分組，方便套用權限與原則。

以下面這個例子來說明，一間公司(Forest)在法國、美國分別有據點(Tree)，美國據點底下又分成紐約、芝加哥兩個 Domain，芝加哥 Domain 底下再依部門分成 Marketing、Human Resources 兩個 OU，個別放著該部門的使用者:

對照回第二節提過的 Entry、DN、Attribute，AD 裡面每一個 Domain、OU、使用者、電腦，本質上都是 LDAP 目錄樹上的一筆 Entry；Forest、Tree、Domain、OU 這層層包含的關係，則透過 DN 路徑呈現。以下面芝加哥 Domain 底下的 Marketing OU 為例，James 這個使用者的 DN 可能長得像 cn=James,ou=Marketing,dc=chicago,dc=corp,dc=com：從右到左依序是公司網域(dc=corp,dc=com)、城市 Domain(dc=chicago)、部門 OU(ou=Marketing)，最後才是使用者自己的 RDN(cn=James)。

OU 除了用來分類，還有一個很重要的用途:掛載 GPO(Group Policy Object，群組原則物件)。管理員可以把一組原則(例如密碼複雜度規則、桌面鎖定時間、可安裝的軟體)套用在某個 OU 上，OU 底下的使用者、電腦就會自動套用這些原則，不用一台一台手動設定:

這一整套 Forest、Tree、Domain、OU 的分層結構，還有掛在上面的 GPO 原則，就是企業在 AD 上投入多年、累積下來的組織資產——這也是後面第七節要談的「為什麼企業離不開 AD」的重要原因之一。

五、Kerberos:以票證為基礎的驗證協定

Kerberos 是 MIT 在 1988 年設計的網路驗證協定，名字來自希臘神話中守護地獄之門的三頭犬，預設使用 88 埠與 KDC 溝通。跟 LDAP 直接拿帳密去 Bind 不一樣，Kerberos 用「票證(Ticket)」來證明身份，好處是使用者只要在一開始輸入一次密碼，之後存取各種服務都不需要重複輸入，而且密碼本身完全不會被傳到網路上。

Kerberos 的核心角色是 KDC(Key Distribution Center，金鑰分發中心)，底下又分成兩個服務:

• AS(Authentication Server，驗證伺服器):負責驗證使用者一開始輸入的帳密。
• TGS(Ticket Granting Server，票證授予伺服器):負責核發存取特定服務所需的票證。

流程大致如下:

1. 使用者輸入帳密登入，用戶端把使用者帳號送給 AS(這個請求稱為 AS-REQ)，不含明文密碼;現代 Kerberos(v5)還會加上「預先驗證(pre-authentication)」，讓用戶端先用密碼算出的金鑰加密一個時間戳記一併送出，證明自己真的知道密碼，避免有人只憑帳號就對 AS 發起離線暴力破解。
2. AS 確認身份沒問題後，用該帳號的密碼雜湊當金鑰，回傳一組工作階段金鑰，同時核發一張用 TGS 的密鑰加密過的 TGT(Ticket Granting Ticket，票證授予票證)(這兩則訊息合稱 AS-REP)。TGT 本身用戶端無法解密讀取內容，只能原樣拿去用。
3. 之後使用者要存取某個服務(例如檔案伺服器)時，用戶端拿著 TGT 向 TGS 要一張專門給這個服務用的 Service Ticket(服務票證)。
4. TGS 驗證 TGT 有效後，核發 Service Ticket 給用戶端。
5. 用戶端把 Service Ticket 交給目標服務，服務用自己保存的金鑰解密驗證，確認使用者身份無誤後，允許存取。

整個過程中，使用者的密碼只在第一步用過一次，後面存取服務都是拿票證交換，不會重複傳送密碼，也不需要使用者重複輸入。這跟 Day03 介紹過的 Token 概念有點像：服務只要能驗證 TGT 或 Service Ticket 有效，就能相信使用者身分，不用自己保存或反覆核對密碼。

AD 環境底下的 Domain Controller(網域控制站) 本身就同時扮演 KDC 的角色，直接使用 AD DS 資料庫作為安全帳戶資料庫，Kerberos 也因此成為 AD 環境裡預設的驗證協定；只有在用戶端或伺服器不屬於同一個（或互信的）網域時，Windows 才會退回使用較舊的 NTLM 協定。也就是說，同一台 Domain Controller 其實同時扮演目錄服務（LDAP）與驗證服務（KDC）兩種角色，下一節會更完整拆解這兩者怎麼分工。

六、LDAP 與 Kerberos 在 AD 裡怎麼分工

同一個 Domain Controller，其實同時在做兩件不同的事:

• 一部分是目錄服務:用 LDAP 協定，儲存、查詢使用者、群組、電腦等 AD 物件與屬性，包含每個帳號的密碼雜湊值。
• 另一部分是 KDC:用 Kerberos 協定，驗證使用者身份、核發票證。

實務上使用者登入網域電腦時，用戶端走的是 Kerberos 流程:向 AS 換 TGT，再向 TGS 換各種服務的 Service Ticket，全程不會直接把密碼傳給 AD 資料庫比對;但如果是一些比較舊、只支援 LDAP 的應用程式(例如 Day04 提過的 VPN 伺服器、部分內部系統)，就會走LDAP Bind 這條路:應用程式直接拿使用者輸入的帳密向 AD 發 Bind 請求，AD 內部核對通過就回覆成功。

換句話說，LDAP 查的是「這個人是誰、有什麼屬性」，Kerberos 管的是「這次要怎麼證明是這個人」。兩者都以 AD 這份目錄資料為底，但對外提供的能力不同；同一套帳號密碼，可能同時被這兩種協定使用。至於 Authorization(授權)，則是應用程式自己的邏輯，用來決定「這個已驗證身分的人可以做什麼」。關於 Authorization 的細節，會在後面的文章再另外展開說明。

七、企業為什麼離不開 AD

雖然現在多數企業都已經導入不少 SaaS 應用程式，也可能用 Day04 介紹過的 IdP 做雲端 SSO，但 AD 往往還是留在架構裡繼續運作，原因通常包括:

• 歷史投入太深:前面提到的 Forest、Domain、OU、GPO 結構，往往是企業花了十幾年逐步建立、調整出來的組織資產，牽動密碼原則、裝置管理、權限委派等大量設定，重建成本很高。
• 大量舊系統只認 LDAP / Kerberos:內部檔案伺服器、印表機、VPN、部分自建系統，很多都是直接整合 LDAP Bind 或 Kerberos，沒有 SAML、OIDC 介面，換掉代價很高。
• 裝置管理仍依賴 AD:公司配發的 Windows 電腦如果要用 GPO 統一管理(鎖定畫面、軟體安裝限制等)，通常還是得加入 AD 網域。

因為如此，企業與雲端服務商並沒有選擇「整個丟棄 AD」，而是發展出各種橋接方案，讓 AD 可以繼續運作，同時把身份資訊延伸到雲端:

• AD FS(Active Directory Federation Services):讓 AD 可以對外扮演 SAML / WS-Federation 的 IdP 角色，不需要把 AD 本身直接暴露給外部應用程式使用。
• Microsoft Entra Connect(前身為 Azure AD Connect):把內部 AD 的使用者、群組、密碼雜湊同步到雲端的 Microsoft Entra ID，讓同一組帳密同時可以登入內部系統與雲端服務，屬於一種「混合身份(Hybrid Identity)」架構。
• Microsoft Entra Domain Services:提供一個受管理的雲端 AD DS 實例，讓部署在雲端的舊系統仍然可以用原生的 LDAP、Kerberos、NTLM 存取，而不需要企業自己維運網域控制站。
• Microsoft Entra Kerberos:讓 Microsoft Entra ID 直接扮演雲端 KDC，透過 KDC Proxy 協定對 Hybrid Identity 使用者核發 Kerberos 票證(例如存取 Azure Files)，使用者不需要對內部網域控制站有直接連線，也能用 Kerberos 存取雲端資源。
• 雲端 Secure LDAP 代理服務(例如 Google Secure LDAP、JumpCloud、Okta 的 LDAP 介面):讓雲端身份供應商對外提供一個 LDAP 介面，那些只支援 LDAP 的舊應用程式，可以直接指向雲端目錄，不必再依賴自己架設的 AD。

這些方案的共通邏輯都是:讓 AD(或它管理的身份資料)繼續存在，同時想辦法讓雲端與新系統也能用到這份身份資料，而不是強迫企業一次性把所有系統都改寫成支援 SAML、OIDC。

小結

LDAP 與 Kerberos 經常一起出現在 AD 環境裡，但兩者處理的是不同層次的問題：LDAP 負責目錄資料的儲存與查詢，Kerberos 則透過 TGT 與 Service Ticket，讓使用者在不反覆傳送密碼的情況下向不同服務證明自己的身分。

Active Directory 把這兩種能力整合在同一套企業身分基礎設施中，再加上 Forest、Domain、OU、GPO 等組織與裝置管理能力，AD 管理的早已不只是帳號，而是一整套企業內部的身分、權限與管理結構。

以下整理出三個重點：

1. LDAP 解決的是身份資料如何被組織與查詢：Entry 代表目錄裡的物件，DN 標示物件在樹狀結構中的唯一位置，Attribute 則保存帳號、群組、部門等資訊。
2. Kerberos 解決的是如何安全地證明身份：使用者登入後取得 TGT，再用它交換特定服務的 Service Ticket，因此不必每次存取服務都重新輸入或傳送密碼。
3. AD 難以被取代，是因為它承載了企業長期累積的管理結構：除了大量舊系統依賴 LDAP、Kerberos，組織分層、GPO 與裝置管理也都與 AD 緊密結合，因此現代架構通常選擇透過同步、同盟或代理服務與雲端整合，而不是一次全面汰換。

下一篇會把視角從企業內部網路轉向 Web 應用程式，介紹 OAuth 1.0 如何讓第三方應用程式在不取得使用者密碼的前提下存取受保護資源，以及它為什麼最終被重新設計的 OAuth 2.0 取代。

參考資源

• 輕型目錄訪問協議 - 維基百科
• Lightweight Directory Access Protocol - Wikipedia
• 具有 Microsoft Entra 識別碼的 LDAP 驗證 - Microsoft Entra
• 關於安全 LDAP 服務 - Google Workspace 說明中心
• Cloud Identity now provides access to traditional apps with secure LDAP - Google Cloud Blog
• 第十一章、使用 LDAP 統一管理帳號 - 鳥哥私房菜
• What is LDAP & How does it work? - SuperTokens
• What is the Kerberos Ticket Granting Service (TGS)? - JumpCloud
• Hybrid identity with Active Directory and Microsoft Entra ID - Microsoft Learn
• Kerberos 驗證說明 - Fortinet
• Kerberos authentication overview - Windows Server | Microsoft Learn
• Kerberos - 維基百科
• Kerberos (protocol) - Wikipedia
• 利用 kerberos 提供票據加密 - 鳥哥私房菜
• Microsoft Entra Kerberos 簡介 - Microsoft Entra