構建基於LDAP的地址薄之一 基礎篇(轉)

構建基於LDAP的地址薄之一 基礎篇(轉)[@more@]

構建基於 LDAP 的地址簿

本教程向您演示瞭如何建立一個基於 LDAP 的後端來儲存多個應用程式可以方便共享的聯絡人資訊。同時，我們提供了 LDAP 基礎知識的概述，並向您介紹了一個預先構建的聯絡人管理工具，該工具將幫助您著手使用這一開放技術。

預備知識

讀者應基本掌握一般管理任務方面的知識及其概念。包括諸如設定許可權、管理使用者賬戶、移動和複製檔案、建立符號連結等任務。

要執行本教程中的示例，您必需正確安裝和配置 Linux 系統和下列軟體：

Red Hat Linux 7.3。作業系統特定的說明是基於 Red Hat Linux 7.3 的。 因為 Red Hat Linux 很受歡迎並且大多數管理員／使用者至少熟悉它的系統佈局和一些約定，所以我們選擇它。

OpenLDAP。OpenLDAP 用作 LDAP 目錄伺服器。 OpenLDAP 是基於開放標準的開放原始碼，可以免費下載。然而，在很大程度上，我們所討論的結構、佈局和管理任務可很容易地轉移到商用目錄伺服器，如 IBM 的 SecureWay Server 和 Netscape 的 Directory Server 產品。

LDAP入門

概述：

首字母縮略 LDAP 代表輕量級目錄訪問協議（Lightweight Directory Access Protocol）。與某些計算機術語不同，術語 LDAP 的自我描述性真是令人驚異。

LDAP 是一種部分基於 X.500 目錄標準的開放標準，但更簡單、更精練且可擴充套件性更好 — 與某些其它通訊協議相比，它是輕量級的。LDAP 標準的規範是以一系列 RFC（或註釋請求，Request For Comment）的形式編排的。有關與 LDAP 相關的 RFC 的更多資訊，請參閱參考資料中列出的 LDAPman RFC 頁面。

資訊被集中儲存在伺服器上的 LDAP 目錄中。LDAP 目錄是一種資料庫；然而，它不是關聯式資料庫。它的目錄或資料庫的結構與 UNIX 檔案系統非常相似：資料按層次儲存；有“根”或“基本 DN”（專有名稱，Distinguished Name）；目錄被進一步細分成組織單元（Organization Units 或 OU）；在這些 OU 中是包含資料的項。這種樹-葉結構不僅使 LDAP 變得可擴充套件，而且當進行簡單的搜尋或查詢時，比傳統的關聯式資料庫更快。

透過使用 LDAP 協議，客戶機將查詢傳送給 LDAP 伺服器（從技術上講，LDAP 沒有“讀”功能；客戶機透過將搜尋請求傳送給伺服器來“讀”目錄項）。伺服器檢查客戶機許可權（即，客戶機有權訪問資料庫嗎？可以讀被請求的樹嗎？可以將資訊寫入資料庫嗎？可以刪除項嗎？），然後返回請求資訊。幾乎所有的現代程式語言都有 LDAP API，這意味著幾乎任何一個軟體都可以支援 LDAP。

遺憾的是，術語 LDAP 經常在沒有上下文的情況下或在不適當的上下文中使用。而目前又有多種使用該術語的方法（LDAP 協議、LDAP 伺服器或 LDAP 客戶機），那些不熟悉 LDAP 世界的人很可能會被搞糊塗。出於本教程的目的，我已經做了所有努力以確保說明了上下文或者使上下文明顯有別於相關的討論。

為什麼使用LADP

在過去兩三年中，LDAP 實現已經從相對不為人知的技術變成“當今的熱門主題”。其突然受歡迎的原因可以大致概括為兩個詞：可擴充套件性和靈活性。

LDAP 協議既是跨平臺的也是基於標準的。這意味著幾乎在任何計算機平臺上執行的任何應用程式都可以從 LDAP 目錄獲取資訊。另外，無論什麼伺服器作業系統、檔案系統或平臺對於客戶機都是無關緊要的。

LDAP 目錄幾乎可以儲存所有型別的資料：電子郵件地址、DNS 資訊、NIS 對映、安全性金鑰、聯絡人資訊列表和計算機名等。如果需要專門的組織單元或項，則可以根據具體實現來定製控制給定欄位可以儲存哪種資訊的規則（稱為模式，稍後將詳細討論）。

大多數 LDAP 伺服器的安裝和配置相對比較簡單，並且可以在很少或沒有維護的情況下執行多年，而且很容易為特定型別的訪問而進行最最佳化。

可以容易地配置 LDAP 目錄來複制部分或所有目錄樹（使用推(push)或拉(pull)方法）。這可以使系統管理員不必擔心出現單點故障的情況。

可以透過 ACL（訪問控制表，Access Control List）來控制對目錄的訪問。例如，管理員可以根據給定組或位置中的成員資格來限制誰可以看到哪些內容，或者給予特殊使用者在其自己記錄中修改所選欄位的能力。ACL 提供極其細粒度的訪問控制，而且 ACL 將這種控制與 LDAP 安裝結合在一起，而不是與請求資訊的客戶機結合在一起。此外，可以容易地將 LDAP 與大多數現有的安全性層和／或認證系統（例如 SSL、Kerberos 和 PAM 等）整合在一起。

LDAP目錄結構：基本DN

目前為止，我們已經討論了什麼是 LDAP、它（在高階別上）是如何工作的、LDAP 目錄的一般結構以及為什麼 LDAP 實現如此受歡迎。現在，應該更深入地研究項本身的各種元件了。正如上一頁所提到的那樣，LDAP 目錄樹的“根”或頂部是基本 DN。基本 DN 通常有兩種形式：organization=（例如，o=syroidmanor.com），或者從組織的 DNS 域元件派生的 DN（dc=syroidmanor,dc=com）。

對於大多數安裝，後者是首選格式，只因為它將兩個截然不同的元件分隔開。如果將來您的公司決定與另一家公司合併，那麼不必修改現有結構；然後，基本 DN 變成 dc=com 和 com 樹的兩個公司分支（當然，如果 syroidmanor.com 與 syroidmanor.com 合併，這樣就不會有多大幫助）。

所有這些都給我們帶來了兩個非常重要的提示：(1) 成功的 LDAP 實現的 99% 在於為您的組織預先規劃一個可擴充套件且有效的結構，(2) 從某種程度上講，每個 LDAP 安裝都是唯一的；換句話說，對於結構佈局沒有一成不變的規則。

下圖顯示了“dc”（與“organization”相對比）LDAP 目錄結構的示例。

[myimg][/myimg]

LDAP目錄結構：組織單元

在目錄基本 DN 的下面是容器或組織單元（OU），它們從邏輯上對您的資料進行分隔或分組。這裡的選項通常由您業務或安裝的組織結構確定。另外，第二層 OU 可用來進一步分隔資料。例如，國際企業可以使用下列結構：

dc=foobar,dc=com

ou=customers

ou=northamerica

ou=southamerica

ou=asia

ou=europe

ou=employees

ou=group

ou=projects

ou=accounting

ou=resource

ou=service

一般的經驗方法可以使您的組織結構儘可能地保持簡單，並且不危及將來的可擴充套件性。還要緊記一點，您將結構容器巢狀得越深，它返回查詢所用的時間就越長。

LDAP目錄結構：個別項

在 LDAP 結構的組織單元下面是實際的項。下面是以 LDIF 格式顯示的示例（填充 LDAP 目錄中有更多 LDIF 格式的示例）。

dn: cn=Tom Syroid, ou=employee, dc=syroidmanor, dc=com

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson

cn: Tom Syroid

cn: Thomas Syroid

sn: Syroid

givenName: Tom

initials: TMS

title: Project Manager

uid: tsyroid

mail: tom@syroidmanor.com

telephoneNumber: 306 555 1212

mobile: 306 555 1999

roomNumber: 115

employeeNumber: 33

employeeType: full time

首先，請注意下列事實：

項只是儲存屬性的地方。

屬性是可用來將一種型別的資訊儲存在目錄中的容器。

每個屬性都有一種型別和一個或多個值。

所以，cn: Tom Syroid 是項的一個屬性，cn 是型別，與該型別相關聯的值是“Tom Syroid”和“Thomas Syroid”。

現在，讓我們仔細研究上述項的屬性。第一行包含項的 DN 或“專有名稱”。LDAP 目錄中的每個項都有唯一的 DN，每個 DN 都由兩部分組成 —“相對專有名稱”（或 RDN）和對 LDAP 目錄結構中儲存記錄的位置的引用。幾乎儲存在 LDAP 目錄中的所有資料都有一個唯一名稱，這個名稱通常儲存在 cn 屬性中。在上面的示例中，用於唯一標識或區別記錄的 cn 值是“Tom Syroid”。注：也可以使用“Thomas Syroid”，只要提供的 dn 對於資料庫中的所有其它項是唯一的即可。後面的 ou 和 dc 值指向目錄結構中記錄的位置。

物件類

物件類由 LDAP 目錄使用來定義給定型別的物件可以有哪些屬性。物件類還定義項必須有什麼屬性，以及項可以有什麼屬性。所有物件類都從其父物件類繼承需求，然後新增它們自己的需求。下面是一個物件類示例：

objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL

MUST ( sn $ cn )

MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

物件類有五個元件：OID（物件標識）、唯一名稱、父物件（SUP）、任何需要的屬性（MUST）和允許的屬性列表（MAY）。OID 是由 LDAP 目錄的內部資料庫機制使用的資料識別符號。從概念上講，它們與 IP 地址相似，因為每個物件類都必須有一個唯一數字。並且象 DNS 和 IP 之間的關係那樣，由建立它們的個人進行註冊，並由這些人“擁有”。有關注冊 OID 的更多資訊，請參閱 Internet Assigned Numbers Authority（或 IANA）。

您需要一個 OID 號來建立您自己的物件類嗎？答案取決於您的目錄伺服器軟體 — 有的允許而有的不允許。有關詳細資訊，請檢視 LDAP 文件。有關已定義的物件類及其屬性的更多資訊，請檢視 LDAPman 模式參考頁面或極其有用的 LDAP 模式檢視器網站

您或許會問什麼是模式？模式只是按照相似性進行分組的物件類集合。例如，inetOrgPerson 模式包含 departmentNumber、employeeType、givenName、homePhone 和 manager 等的物件類。inetOrgPerson 模式還繼承了其它“父”模式的許多物件類。

小結

本章以很短的篇幅討論了許多基礎知識。雖然在安裝和配置 LDAP 伺服器（下一章主題）之前不需要了解這些所討論的內容，但至少大致掌握一下 LDAP 目錄服務背後的基本概念可幫助管理員更好地理解 LDAP 操作後面的原理。有關 LDAP 結構、物件類和屬性的更多資訊，請參考 OpenLDAP Administrator's Guide 和許多可從 獲得的 FAQ