構建基於 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]http://bbs.chinaunix.net/forum/uploadfile/dctree.jpg[/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:
[email protected]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 和許多可從 www.openldap.org 獲得的 FAQ
您需要一個 OID 號來創建您自己的對象類嗎？答案取決於您的目錄服務器軟件 — 有的允許而有的不允許。有關詳細信息，請查看 LDAP 文檔。有關已定義的對象類及其屬性的更多信息，請查看 LDAPman 模式參考頁面或極其有用的 LDAP 模式查看器網站
您或許會問什麼是模式？模式只是按照相似性進行分組的對象類集合。例如，inetOrgPerson 模式包含 departmentNumber、employeeType、givenName、homePhone 和 manager 等的對象類。inetOrgPerson 模式還繼承了其它“父”模式的許多對象類。
小結
本章以很短的篇幅討論了許多基礎知識。雖然在安裝和配置 LDAP 服務器（下一章主題）之前不需要了解這些所討論的內容，但至少大致掌握一下 LDAP 目錄服務背後的基本概念可幫助管理員更好地理解 LDAP 操作後面的原理。有關 LDAP 結構、對象類和屬性的更多信息，請參考 OpenLDAP Administrator's Guide 和許多可從 www.openldap.org 獲得的 FAQ
