初識ldap

什麼是LDAP? 
LDAP的英文全稱是Lightweight Directory Access Protocol，通常都簡稱爲LDAP。它是基於X.500標準的， 
可是簡單多了而且能夠根據須要定製。與X.500不一樣，LDAP支持TCP/IP，這對訪問Internet是必須的。LDAP 
的核心規範在RFC中都有定義，全部與LDAP相關的RFC均可以在LDAPman RFC網頁中找到。如今LDAP技術不只 
發展得很快並且也是激動人心的。在企業範圍內實現LDAP可讓運行在幾乎全部計算機平臺上的全部的應 
用程序從LDAP目錄中獲取信息。LDAP目錄中能夠存儲各類類型的數據：電子郵件地址、郵件路由信息、人力 
資源數據、公用密匙、聯繫人列表，等等。經過把LDAP目錄做爲系統集成中的一個重要環節，能夠簡化員工 
在企業內部查詢信息的步驟，甚至連主要的數據源均可以放在任何地方。 

LDAP目錄的優點 

若是須要開發一種提供公共信息查詢的系統通常的設計方法多是採用基於WEB的數據庫設計方式，即前端 
使用瀏覽器然後端使用WEB服務器加上關係數據庫。後端在Windows的典型實現多是Windows NT + IIS + Acess 
數據庫或者是SQL服務器，IIS和數據庫之間經過ASP技術使用ODBC進行鏈接，達到經過填寫表單查詢數據的功能； 

後端在Linux系統的典型實現多是Linux+ Apache + postgresql，Apache和數據庫之間經過PHP3提供的函數進 
行鏈接。使用上述方法的缺點是後端關係數據庫的引入致使系統總體的性能下降和系統的管理比較繁瑣，由於需 
要不斷的進行數據類型的驗證和事務的完整性的確認；而且前端用戶對數據的控制不夠靈活，用戶權限的設置一 
般只能是設置在表一級而不是設置在記錄一級。 

目錄服務的推出主要是解決上述數據庫中存在的問題。目錄與關係數據庫類似，是指具備描述性的基於屬性的記 
錄集合，但它的數據類型主要是字符型，爲了檢索的須要添加了BIN（二進制數據）、CIS（忽略大小寫）、CES 
（大小寫敏感）、TEL（電話型）等語法（Syntax），而不是關係數據庫提供的整數、浮點數、日期、貨幣等類型， 
一樣也不提供象關係數據庫中廣泛包含的大量的函數，它主要面向數據的查詢服務（查詢和修改操做比通常是大於 
10:1），不提供事務的回滾（rollback）機制，它的數據修改使用簡單的鎖定機制實現All-or-Nothing，它的目標 
是快速響應和大容量查詢而且提供多目錄服務器的信息複製功能。 

如今該說說LDAP目錄到底有些什麼優點了。如今LDAP的流行是不少因數共同做用的結果。可能LDAP最大的優點是： 
能夠在任何計算機平臺上，用很容易得到的並且數目不斷增長的LDAP的客戶端程序訪問LDAP目錄。並且也很容易 
定製應用程序爲它加上LDAP的支持。 

LDAP協議是跨平臺的和標準的協議，所以應用程序就不用爲LDAP目錄放在什麼樣的服務器上操心了。實際上，LDAP 
獲得了業界的普遍承認，由於它是Internet的標準。產商都很願意在產品中加入對LDAP的支持，由於他們根本不用 
考慮另外一端（客戶端或服務端）是怎麼樣的。LDAP服務器能夠是任何一個開發源代碼或商用的LDAP目錄服務器（或 
者還多是具備LDAP界面的關係型數據庫），由於能夠用一樣的協議、客戶端鏈接軟件包和查詢命令與LDAP服務器 
進行交互。與LDAP不一樣的是，若是軟件產商想在軟件產品中集成對DBMS的支持，那麼一般都要對每個數據庫服務 
器單獨定製。不象不少商用的關係型數據庫，你沒必要爲LDAP的每個客戶端鏈接或許可協議付費 大多數的LDAP服務 
器安裝起來很簡單，也容易維護和優化。 

LDAP服務器能夠用「推」或「拉」的方法複製部分或所有數據，例如：能夠把數據「推」到遠程的辦公室，以增長 
數據的安全性。複製技術是內置在LDAP服務器中的並且很容易配置。若是要在DBMS中使用相同的複製功能，數據庫 
產商就會要你支付額外的費用，並且也很難管理。 

LDAP容許你根據須要使用ACI（通常都稱爲ACL或者訪問控制列表）控制對數據讀和寫的權限。例如，設備管理員可 
以有權改變員工的工做地點和辦公室號碼，可是不容許改變記錄中其它的域。ACI能夠根據誰訪問數據、訪問什麼數 
據、數據存在什麼地方以及其它對數據進行訪問控制。由於這些都是由LDAP目錄服務器完成的，因此不用擔憂在客 
戶端的應用程序上是否要進行安全檢查。 

LDAP（Lightweight Directory Acess Protocol）是目錄服務在TCP/IP上的實現（RFC 1777 V2版和RFC 2251 

V3版）。它是對X500的目錄協議的移植，可是簡化了實現方法，因此稱爲輕量級的目錄服務。在LDAP中目錄是按照 
樹型結構組織，目錄由條目（Entry）組成，條目至關於關係數據庫中表的記錄；條目是具備區別名DN（Distinguished 

Name）的屬性（Attribute）集合，DN至關於關係數據庫表中的關鍵字（Primary 

Key）；屬性由類型（Type）和多個值（Values）組成，至關於關係數據庫中的域（Field）由域名和數據類型組成， 
只是爲了方便檢索的須要，LDAP中的Type能夠有多個Value，而不是關係數據庫中爲下降數據的冗餘性要求實現的各 
個域必須是不相關的。LDAP中條目的組織通常按照地理位置和組織關係進行組織，很是的直觀。LDAP把數據存放在 
文件中，爲提升效率可使用基於索引的文件數據庫，而不是關係數據庫。LDAP協議集還規定了DN的命名方法、存 
取控制方法、搜索格式、複製方法、URL格式、開發接口等 

LDAP對於這樣存儲這樣的信息最爲有用，也就是數據須要從不一樣的地點讀取，可是不須要常常更新。 

例如，這些信息存儲在LDAP目錄中是十分有效的： 

l 公司員工的電話號碼簿和組織結構圖 

l 客戶的聯繫信息 

l 計算機管理須要的信息，包括NIS映射、email假名，等等 

l 軟件包的配置信息 

l 公用證書和安全密匙 

何時該用LDAP存儲數據 

大多數的LDAP服務器都爲讀密集型的操做進行專門的優化。所以，當從LDAP服務器中讀取數據的時候會比從專門爲 
OLTP優化的關係型數據庫中讀取數據快一個數量級。也是由於專門爲讀的性能進行優化，大多數的LDAP目錄服務器 
並不適合存儲須要須要常常改變的數據。例如，用LDAP服務器來存儲電話號碼是一個很好的選擇，可是它不能做爲 
電子商務站點的數據庫服務器。 

若是下面每個問題的答案都是「是」，那麼把數據存在LDAP中就是一個好主意。 

l 須要在任何平臺上都能讀取數據嗎？ 

l 每個單獨的記錄項是否是每一天都只有不多的改變？ 

l 能夠把數據存在平面數據庫（flat database）而不是關係型數據庫中嗎？換句話來講，也就是無論什麼範式不 
範式的，把全部東西都存在一個記錄中（差很少只要知足第一範式）。 

最後一個問題可能會唬住一些人，其實用平面數據庫去存儲一些關係型的數據也是很通常的。例如，一條公司員工 
的記錄就能夠包含經理的登陸名。用LDAP來存儲這類信息是很方便的。一個簡單的判斷方法：若是能夠把保數據存 
在一張張的卡片裏，就能夠很容易地把它存在LDAP目錄裏。 


安全和訪問控制 

LDAP提供很複雜的不一樣層次的訪問控制或者ACI。因這些訪問能夠在服務器端控制，這比用客戶端的軟件保證數據的 
安全可安全多了。 

用LDAP的ACI，能夠完成： 

l 給予用戶改變他們本身的電話號碼和家庭地址的權限，可是限制他們對其它數據（如，職務名稱，經理的登陸名， 
等等）只有「只讀」權限。 

l 給予「HR-admins"組中的全部人權限以改變下面這些用戶的信息：經理、工做名稱、員工號、部門名稱和部門號。 
可是對其它域沒有寫權限。 

l 禁止任何人查詢LDAP服務器上的用戶口令，可是能夠容許用戶改變他或她本身的口令。 

l 給予經理訪問他們上級的家庭電話的只讀權限，可是禁止其餘人有這個權限。 

l 給予「host-admins"組中的任何人建立、刪除和編輯全部保存在LDAP服務器中的與計算機主機有關的信息 

l 經過Web，容許「foobar-sales"組中的成員有選擇地給予或禁止他們本身讀取一部分客戶聯繫數據的讀權限。這 
將容許他們把客戶聯繫信息下載到本地的筆記本電腦或我的數字助理（PDA）上。（若是銷售人員的軟件都支持LDAP， 
這將很是有用） 

l 經過Web，容許組的全部者刪除或添加他們擁有的組的成員。例如：能夠容許銷售經理給予或禁止銷售人員改變Web 
頁的權限。也能夠容許郵件假名（mail aliase）的全部者不通過IT技術人員就直接從郵件假名中刪除或添加用戶。 
「公用」的郵件列表應該容許用戶從郵件假名中添加或刪除本身（可是隻能是本身）。也能夠對IP地址或主機名加以 
限制。例如，某些域只容許用戶IP地址以192.168.200.*開頭的有讀的權限，或者用戶反向查找DNS獲得的主機名必須 
爲*.foobar.com。 

LDAP目錄樹的結構 

LDAP目錄以樹狀的層次結構來存儲數據。若是你對自頂向下的DNS樹或UNIX文件的目錄樹比較熟悉，也就很容易掌握 
LDAP目錄樹這個概念了。就象DNS的主機名那樣，LDAP目錄記錄的標識名（Distinguished Name，簡稱DN）是用來讀取 
單個記錄，以及回溯到樹的頂部。後面會作詳細地介紹。 

爲何要用層次結構來組織數據呢？緣由是多方面的。下面是可能遇到的一些狀況： 

l 若是你想把全部的美國客戶的聯繫信息都「推」到位於到西雅圖辦公室（負責營銷）的LDAP服務器上，可是你不想 
把公司的資產管理信息「推」到那裏。 

l 你可能想根據目錄樹的結構給予不一樣的員工組不一樣的權限。在下面的例子裏，資產管理組對「asset-mgmt"部分有完 
全的訪問權限，可是不能訪問其它地方。 

l 把LDAP存儲和複製功能結合起來，能夠定製目錄樹的結構以下降對WAN帶寬的要求。位於西雅圖的營銷辦公室須要每 
分鐘更新的美國銷售情況的信息，可是歐洲的銷售狀況就只要每小時更新一次就好了。 

刨根問底：基準DN 

LDAP目錄樹的最頂部就是根，也就是所謂的「基準DN"。基準DN一般使用下面列出的三種格式之一。假定我在名爲FooBar 
的電子商務公司工做，這家公司在Internet上的名字是foobar.com。 

o="FooBar, Inc.", c=US 

（以X.500格式表示的基準DN） 

在這個例子中，o=FooBar, Inc. 表示組織名，在這裏就是公司名的同義詞。c=US 表示公司的總部在美國。之前，通常 
都用這種方式來表示基準DN。可是事物老是在不斷變化的，如今全部的公司都已經（或計劃）上Internet上。隨着 
Internet的全球化，在基準DN中使用國家代碼很容易讓人產生混淆。如今，X.500格式發展成下面列出的兩種格式。 

o=foobar.com 

（用公司的Internet地址表示的基準DN） 

這種格式很直觀，用公司的域名做爲基準DN。這也是如今最經常使用的格式。 

dc=foobar, dc=com 

（用DNS域名的不一樣部分組成的基準DN） 

就象上面那一種格式，這種格式也是以DNS域名爲基礎的，可是上面那種格式不改變域名（也就更易讀），而這種格式 
把域名：foobar.com分紅兩部分 dc=foobar, dc=com。在理論上，這種格式可能會更靈活一點，可是對於最終用戶來講 
也更難記憶一點。考慮一下foobar.com這個例子。當foobar.com和gizmo.com合併以後，能夠簡單的把「dc=com"看成基 
準DN。把新的記錄放到已經存在的dc=gizmo, dc=com目錄下，這樣就簡化了不少工做（固然，若是foobar.com和wocket.edu 
合併，這個方法就不能用了）。若是LDAP服務器是新安裝的，我建議你使用這種格式。再請注意一下，若是你打算使用活動 
目錄（Actrive Directory），Microsoft已經限制你必須使用這種格式。 

更上一層樓：在目錄樹中怎麼組織數據 

在UNIX文件系統中，最頂層是根目錄（root）。在根目錄的下面有不少的文件和目錄。象上面介紹的那樣，LDAP目錄也是 
用一樣的方法組織起來的。 

在根目錄下，要把數據從邏輯上區分開。由於歷史上（X.500）的緣由，大多數LDAP目錄用OU從邏輯上把數據分開來。OU 
表示「Organization Unit"，在X.500協議中是用來表示公司內部的機構：銷售部、財務部，等等。如今LDAP還保留ou=這 
樣的命名規則，可是擴展了分類的範圍，能夠分類爲：ou=people, ou=groups, ou=devices，等等。更低一級的OU有時用 
來作更細的歸類。例如：LDAP目錄樹（不包括單獨的記錄）可能會是這樣的： 

dc=foobar, dc=com 

ou=customers 

ou=asia 

ou=europe 

ou=usa 

ou=employees 

ou=rooms 

ou=groups 

ou=assets-mgmt 

ou=nisgroups 

ou=recipes 

單獨的LDAP記錄 

DN是LDAP記錄項的名字 

在LDAP目錄中的全部記錄項都有一個惟一的「Distinguished Name"，也就是DN。每個LDAP記錄項的DN是由兩個部分 
組成的：相對DN（RDN）和記錄在LDAP目錄中的位置。 

RDN是DN中與目錄樹的結構無關的部分。在LDAP目錄中存儲的記錄項都要有一個名字，這個名字一般存在cn（Common Name） 
這個屬性裏。由於幾乎全部的東西都有一個名字，在LDAP中存儲的對象都用它們的cn值做爲RDN的基礎。若是我把最喜歡的 
吃燕麥粥食譜存爲一個記錄，我就會用cn=Oatmeal Deluxe做爲記錄項的RDN。 

l 個人LDAP目錄的基準DN是dc=foobar,dc=com 

l 我把本身的食譜做爲LDAP的記錄項存在ou=recipes 

l 個人LDAP記錄項的RDN設爲cn=Oatmeal Deluxe 

上面這些構成了燕麥粥食譜的LDAP記錄的完整DN。記住，DN的讀法和DNS主機名相似。下面就是完整的DN： 

cn=Oatmeal Deluxe,ou=recipes,dc=foobar,dc=com 

舉一個實際的例子來講明DN 

如今爲公司的員工設置一個DN。能夠用基於cn或uid（User ID），做爲典型的用戶賬號。例如，FooBar的員工Fran Smith 
（登陸名：fsmith）的DN能夠爲下面兩種格式： 

uid=fsmith,ou=employees,dc=foobar,dc=com 

（基於登陸名） 

LDAP（以及X.500）用uid表示「User ID"，不要把它和UNIX的uid號混淆了。大多數公司都會給每個員工惟一的登陸名， 
所以用這個辦法能夠很好地保存員工的信息。你不用擔憂之後還會有一個叫Fran Smith的加入公司，若是Fran改變了她的 
名字（結婚？離婚？或宗教緣由？），也用不着改變LDAP記錄項的DN。 

cn=Fran Smith,ou=employees,dc=foobar,dc=com 

（基於姓名） 

能夠看到這種格式使用了Common Name（CN）。能夠把Common Name當成一我的的全名。這種格式有一個很明顯的缺點就是： 
若是名字改變了，LDAP的記錄就要從一個DN轉移到另外一個DN。可是，咱們應該儘量地避免改變一個記錄項的DN。 

定製目錄的對象類型 

你能夠用LDAP存儲各類類型的數據對象，只要這些對象能夠用屬性來表示，下面這些是能夠在LDAP中存儲的一些信息： 

l 員工信息：員工的姓名、登陸名、口令、員工號、他的經理的登陸名，郵件服務器，等等。 

l 物品跟蹤信息：計算機名、IP地址、標籤、型號、所在位置，等等。 

l 客戶聯繫列表：客戶的公司名、主要聯繫人的電話、傳真和電子郵件，等等。 

l 會議廳信息：會議廳的名字、位置、能夠坐多少人、電話號碼、是否有投影機。 

l 食譜信息：菜的名字、配料、烹調方法以及準備方法。 

由於LDAP目錄能夠定製成存儲任何文本或二進制數據，到底存什麼要由你本身決定。LDAP目錄用對象類型 
（object classes）的概念來定義運行哪一類的對象使用什麼屬性。在幾乎全部的LDAP服務器中，你都要根據 
本身的須要擴展基本的LDAP目錄 
的功能，建立新的對象類型或者擴展示存的對象類型。 

LDAP目錄以一系列「屬性對」的形式來存儲記錄項，每個記錄項包括屬性類型和屬性值（這與關係型數據庫 
用行和列來存取數據有根本的不一樣）。下面是我存在LDAP目錄中的一部分食譜記錄： 

dn: cn=Oatmeal Deluxe, ou=recipes, dc=foobar, dc=com 

cn: Instant Oatmeal Deluxe 

recipeCuisine: breakfast 

recipeIngredient: 1 packet instant oatmeal 

recipeIngredient: 1 cup water 

recipeIngredient: 1 pinch salt 

recipeIngredient: 1 tsp brown sugar 

recipeIngredient: 1/4 apple, any type 

請注意上面每一種配料都做爲屬性recipeIngredient值。LDAP目錄被設計成象上面那樣爲一個屬性保存多個值的， 
而不是在每個屬性的後面用逗號把一系列值分開。 

由於用這樣的方式存儲數據，因此數據庫就有很大的靈活性，沒必要爲加入一些新的數據就從新建立表和索引。更 
重要的是，LDAP目錄沒必要花費內存或硬盤空間處理「空」域，也就是說，實際上不使用可選擇的域也不會花費你 
任何資源。 
做爲例子的一個單獨的數據項 

讓咱們看看下面這個例子。咱們用Foobar, Inc.的員工Fran Smith的LDAP記錄。這個記錄項的格式是LDIF，用來 
導入和導出LDAP目錄的記錄項。 

dn: uid=fsmith, ou=employees, dc=foobar, dc=com 

objectclass: person 

objectclass: organizationalPerson 

objectclass: inetOrgPerson 

objectclass: foobarPerson 

uid: fsmith 

givenname: Fran 

sn: Smith 

cn: Fran Smith 

cn: Frances Smith 

telephonenumber: 510-555-1234 

roomnumber: 122G 

o: Foobar, Inc. 

mailRoutingAddress: fsmith@foobar.com 

mailhost: mail.foobar.com 

userpassword: {crypt}3x1231v76T89N 

uidnumber: 1234 

gidnumber: 1200 

homedirectory: /home/fsmith 

loginshell: /usr/local/bin/bash 

屬性的值在保存的時候是保留大小寫的，可是在默認狀況下搜索的時候是不區分大小寫的。某些特殊的屬性 
（例如，password）在搜索的時候須要區分大小寫。 

讓咱們一點一點地分析上面的記錄項。 

dn: uid=fsmith, ou=employees, dc=foobar, dc=com 

這是Fran的LDAP記錄項的完整DN，包括在目錄樹中的完整路徑。LDAP（和X.500）使用uid（User ID），不要 
把它和UNIX的uid號混淆了。 

objectclass: person 

objectclass: organizationalPerson 

objectclass: inetOrgPerson 

objectclass: foobarPerson 

能夠爲任何一個對象根據須要分配多個對象類型。person對象類型要求cn（common name）和sn（surname） 
這兩個域不能爲空。persion對象類型容許有其它的可選域，包括givenname、telephonenumber，等等。 
organizational Person給person加入更多的可選域，inetOrgPerson又加入更多的可選域（包括電子郵件信息）。 
最後，foobarPerson是爲Foobar定製的對象類型，加入了不少定製的屬性。 

uid: fsmith 

givenname: Fran 

sn: Smith 

cn: Fran Smith 

cn: Frances Smith 

telephonenumber: 510-555-1234 

roomnumber: 122G 

o: Foobar, Inc. 

之前說過了，uid表示User ID。當看到uid的時候，就在腦殼裏想想「login"。 

請注意CN有多個值。就象上面介紹的，LDAP容許某些屬性有多個值。爲何容許有多個值呢？假定你在用 
公司的LDAP服務器查找Fran的電話號碼。你可能只知道她的名字叫Fran，可是對人力資源處的人來講她的 
正式名字叫作Frances。由於保存了她的兩個名字，因此用任何一個名字檢索均可以找到Fran的電話號碼、 
電子郵件和辦公房間號，等等。 

mailRoutingAddress: fsmith@foobar.com 

mailhost: mail.foobar.com 

就象如今大多數的公司都上網了，Foobar用Sendmail發送郵件和處理外部郵件路由信息。Foobar把全部用戶 
的郵件信息都存在LDAP中。最新版本的Sendmail支持這項功能。 

Userpassword: {crypt}3x1231v76T89N 

uidnumber: 1234 

gidnumber: 1200 

gecos: Frances Smith 

homedirectory: /home/fsmith 

loginshell: /usr/local/bin/bash 

注意，Foobar的系統管理員把全部用戶的口令映射信息也都存在LDAP中。FoobarPerson類型的對象具備這 
種能力。再注意一下，用戶口令是用UNIX的口令加密格式存儲的。UNIX的uid在這裏爲uidnumber。提醒你一下， 
關於如何在LDAP中保存NIS信息，有完整的一份RFC。在之後的文章中我會談一談NIS的集成。 

LDAP複製 

LDAP服務器可使用基於「推」或者「拉」的技術，用簡單或基於安全證書的安全驗證，複製一部分或者所 
有的數據。 

例如，Foobar有一個「公用的」LDAP服務器，地址爲ldap.foobar.com，端口爲389。Netscape Communicator 
的電子郵件查詢功能、UNIX的「ph"命令要用到這個服務器，用戶也能夠在任何地方查詢這個服務器上的員工 
和客戶聯繫信息。公司的主LDAP服務器運行在相同的計算機上，不過端口號是1389。 

你可能即不想讓員工查詢資產管理或食譜的信息，又不想讓信息技術人員看到整個公司的LDAP目錄。爲了解決 
這個問題，Foobar有選擇地把子目錄樹從主LDAP服務器複製到「公用」LDAP服務器上，不復制須要隱藏的信息。 
爲了保持數據始終是最新的，主目錄服務器被設置成即時「推」同步。這些種方法主要是爲了方便，而不是安全， 
由於若是有權限的用戶想查詢全部的數據，能夠用另外一個LDAP端口。 

假定Foobar經過從奧克蘭到歐洲的低帶寬數據的鏈接用LDAP管理客戶聯繫信息。能夠創建從ldap.foobar.com:1389 
到munich-ldap.foobar.com:389的數據複製，象下面這樣： 

periodic pull: ou=asia,ou=customers,o=sendmail.com 

periodic pull: ou=us,ou=customers,o=sendmail.com 

immediate push: ou=europe,ou=customers,o=sendmail.com 

「拉」鏈接每15分鐘同步一次，在上面假定的狀況下足夠了。「推」鏈接保證任何歐洲的聯繫信息發生了變化就 
當即被「推」到Munich。 
用上面的複製模式，用戶爲了訪問數據須要鏈接到哪一臺服務器呢？在Munich的用戶能夠簡單地鏈接到本地服務 
器。若是他們改變了數據，本地的LDAP服務器就會把這些變化傳到主LDAP服務器。而後，主LDAP服務器把這些變化 
「推」回本地的「公用」LDAP服務器保持數據的同步。這對本地的用戶有很大的好處，由於全部的查詢（大多數是讀）都在本地的服務器上進行，速度很是快。當須要改變信息的時候，最終用戶不須要從新配置客戶端的軟件，由於LDAP目錄服務器爲他們完成了全部的數據交換工做。