A. 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.e
合並，這個方法就不能用了）。如果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: [email protected]
mailhost: mail.foobar.com
userpassword: 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: [email protected]
mailhost: mail.foobar.com
就象現在大多數的公司都上網了，Foobar用Sendmail發送郵件和處理外部郵件路由信息。Foobar把所有用戶
的郵件信息都存在LDAP中。最新版本的Sendmail支持這項功能。
Userpassword: 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目錄伺服器為他們完成了所有的數據交換工作。
B. 郵件伺服器採用mysql 和ldap比較 效率怎麼樣
我覺得沒什麼區別，但是一般郵件伺服器對資料庫的支持會更好一點。
但是ldap如果你架設成功的話，還可以直接作為地址簿，outlook，foxmail等客戶端可以嘗試直接讀取，這個是資料庫做不到的。
C. 什麼是LDAP認證
LDAP是底層資料庫，提供用戶信息用的，並沒有認證功能，認證功能是又Radius完成的，Radius通過查詢LDAP資料庫，判斷用戶信息是否匹配。
Ldap是個類似月資料庫的東西：
不少LDAP開發人員喜歡把LDAP與關系資料庫相比，認為是另一種的存貯方式，然後在讀性能上進行比較。實際上，這種對比的基礎是錯誤的。LDAP和關系資料庫是兩種不同層次的概念，後者是存貯方式（同一層次如網格資料庫，對象資料庫），前者是存貯模式和訪問協議。LDAP是一個比關系資料庫抽象層次更高的存貯概念，與關系資料庫的查詢語言SQL屬同一級別。LDAP最基本的形式是一個連接資料庫的標准方式。該資料庫為讀查詢作了優化。因此它可以很快地得到查詢結果，不過在其它方面，例如更新，就慢得多。
D. LDAP是什麼
LDAP是輕量目錄訪問協議，英文全稱是Lightweight Directory Access Protocol，一般都簡稱為LDAP。它是基於X.500標準的，但是簡單得多並且可以根據需要定製。
LDAP由互聯網工程任務組（IETF）的文檔RFC定義，使用了描述語言ASN.1定義。最新的版本是版本3，由RFC 4511所定義。例如，一個用語言描述的LDAP的搜索如：「在公司郵件目錄中搜索公司位於那什維爾名字中含有「Jessy」的有郵件地址的所有人。請返回他們的全名，電子郵件，頭銜和簡述。」
(4)ldap協議和sql協議比較擴展閱讀：
LDAP-開發方式
如果需要開發一種提供公共信息查詢的系統一般的設計方法可能是採用基於WEB的資料庫設計方式，即前端使用瀏覽器而後端使用WEB伺服器加上關系資料庫。後端在Windows的典型實現可能是Windows NT + IIS + Acess資料庫或者是SQL SERVER，IIS和資料庫之間通過ASP技術使用ODBC進行連接，達到通過填寫表單查詢數據的功能；
E. 協議ldaps和ldap的區別
curl是libcurl這個庫支持的，wget是一個純粹的命令行命令。
2.curl支持更多的協議。curl supports FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS, FILE, POP3, IMAP, SMTP and RTSP at the time of this writing. Wget supports HTTP, HTTPS and FTP.
3.curl 默認支持HTTP1.1（也支持1.0），而wget僅僅支持HTTP1.0規范。
4.curl在指定要的鏈接時能夠支持URL的序列或集合，而wget則不能這樣;
5.wget支持遞歸，而curl則沒有這個功能。（這是wget的一個主要好處，wget也是有優勢的）
F. 我的電腦偶爾會出現錯誤提示：ldap ：///windows無法訪問指定設備、路徑、文件......
介紹LDAP
原文：http://ldapman.org/articles/intro_to_ldap.html
原文作者：Michael Donnelly
翻譯：Brimmer
http://www.linuxaid.com.cn/engineer/brimmer/html/LDAP.htm
如果你在計算機行業工作，那麼對LDAP可能早有耳聞了。想深入地了解LDAP嗎？那麼可以好好地讀一下這篇文章。這篇介紹性的文章是一系列介紹如何在企業中設計、實現和集成LDAP環境的文章的頭一篇。主要是先讓你熟悉一下LDAP的基本概念，那些比較困難的細節問題將放到以後討論。在這篇文章中我們將要介紹：
什麼是LDAP?
什麼時候該用LDAP存儲數據？
LDAP目錄樹的結構
單獨的LDAP記錄
作為例子的一個單獨的數據項
LDAP復制
安全和訪問控制
現在LDAP技術不僅發展得很快而且也是激動人心的。在企業范圍內實現LDAP可以讓運行在幾乎所有計算機平台上的所有的應用程序從LDAP目錄中獲取信息。LDAP目錄中可以存儲各種類型的數據：電子郵件地址、郵件路由信息、人力資源數據、公用密匙、聯系人列表，等等。通過把LDAP目錄作為系統集成中的一個重要環節，可以簡化員工在企業內部查詢信息的步驟，甚至連主要的數據源都可以放在任何地方。如果Oracle、Sybase、Informix或Microsoft SQL資料庫中已經存儲了類似的數據，那麼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目錄）中的信息的協議。更為確切和正式的說法應該是象這樣的：「通過使用LDAP，可以在信息目錄的正確位置讀取（或存儲）數據」。但是，也沒有必要吹毛求疵，盡管表達得不夠准確，我們也都知道對方在說什麼。
LDAP目錄是資料庫嗎？
就象Sybase、Oracle、Informix或Microsoft的資料庫管理系統（DBMS）是用於處理查詢和更新關系型資料庫那樣，LDAP伺服器也是用來處理查詢和更新LDAP目錄的。換句話來說LDAP目錄也是一種類型的資料庫，但是不是關系型資料庫。不象被設計成每分鍾需要處理成百上千條數據變化的資料庫，例如：在電子商務中經常用到的在線交易處理（OLTP）系統，LDAP主要是優化數據讀取的性能。
LDAP目錄的優勢
現在該說說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對於這樣存儲這樣的信息最為有用，也就是數據需要從不同的地點讀取，但是不需要經常更新。例如，這些信息存儲在LDAP目錄中是十分有效的：
l 公司員工的電話號碼簿和組織結構圖
l 客戶的聯系信息
l 計算機管理需要的信息，包括NIS映射、email假名，等等
l 軟體包的配置信息
l 公用證書和安全密匙
什麼時候該用LDAP存儲數據？
大多數的LDAP伺服器都為讀密集型的操作進行專門的優化。因此，當從LDAP伺服器中讀取數據的時候會比從專門為OLTP優化的關系型資料庫中讀取數據快一個數量級。也是因為專門為讀的性能進行優化，大多數的LDAP目錄伺服器並不適合存儲需要需要經常改變的數據。例如，用LDAP伺服器來存儲電話號碼是一個很好的選擇，但是它不能作為電子商務站點的資料庫伺服器。
如果下面每一個問題的答案都是「是」，那麼把數據存在LDAP中就是一個好主意。
l 需要在任何平台上都能讀取數據嗎？
l 每一個單獨的記錄項是不是每一天都只有很少的改變？
l 可以把數據存在平面資料庫（flat database）而不是關系型資料庫中嗎？換句話來說，也就是不管什麼範式不範式的，把所有東西都存在一個記錄中（差不多隻要滿足第一範式）。
最後一個問題可能會唬住一些人，其實用平面資料庫去存儲一些關系型的數據也是很一般的。例如，一條公司員工的記錄就可以包含經理的登錄名。用LDAP來存儲這類信息是很方便的。一個簡單的判斷方法：如果可以把保數據存在一張張的卡片里，就可以很容易地把它存在LDAP目錄里。
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.e合並，這個方法就不能用了）。如果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: [email protected]
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: [email protected]
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目錄伺服器為他們完成了所有的數據交換工作。
安全和訪問控制
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目錄進行怎樣的訪問控制，實際上真正實現起來需要做的工作比這多得多。在以後的文章中我會詳細地討論訪問控制。
G. ldap是什麼
簡單的說來，LDAP是一個得到關於人或者資源的集中、靜態數據的快速方式。
LDAP是一個用來發布目錄信息到許多不同資源的協議。通常它都作為一個集中的地址被使用，不過根據組織者的需要，它可以做得更加強大。
LDAP其實是一個電話簿，類似於我們所使用諸如NIS(Network Information Service)、DNS (Domain Name Service)等網路目錄，也類似於你在花園中所看到的樹木。
不少LDAP開發人員喜歡把LDAP與關系資料庫相比，認為是另一種的存貯方式，然後在讀性能上進行比較。實際上，這種對比的基礎是錯誤的。LDAP和關系資料庫是兩種不同層次的概念，後者是存貯方式（同一層次如網格資料庫，
對象資料庫），前者是存貯模式和訪問協議。LDAP是一個比關系資料庫抽象層次更高的存貯概念，與關系資料庫的查詢語言SQL屬同一級別。LDAP最基本
的形式是一個連接資料庫的標准方式。該資料庫為讀查詢作了優化。因此它可以很快地得到查詢結果，不過在其它方面，例如更新，就慢得多。
特殊的資料庫
從另一個意義上 LDAP是實現了指定的數據結構的存貯，它是一種特殊的資料庫。但是LDAP和一般的資料庫不同，明確這一點是很重要的。 LDAP對查詢進行了優化，與寫性能相比LDAP的讀性能要優秀很多。
就象Sybase、Oracle、Informix或Microsoft的資料庫管理系統（DBMS）是用於處理查詢和更新關系型資料庫那樣，LDAP伺服器也是用來處理查詢和更新LDAP目錄的。換句話來說LDAP目錄也是一種類型的資料庫，但不是關系型資料庫。要特別注意的是，LDAP通常作為一個 hierarchical資料庫使用，而不是一個關系資料庫。因此，它的結構用樹來表示比用表格好。正因為這樣，就不能用SQL語句了。
21世紀的LDAP技術發展很快。 幾乎所有計算機平台上的所有的應用程序都可以從LDAP目錄中獲取信息。LDAP目錄中可以存儲各種類型的數據：電子郵件地址、郵件路由信息、人力資源數據、公用密匙、聯系人列表，等等。通過把LDAP目錄作為系統集成中的一個重要環節，可以簡化員工在企業內部查詢信息的步驟，甚至連主要的數據源都可以放在任何地方。
伺服器
LDAP伺服器可以用「推」或「拉」的方法復制部分或全部數據，例如：可以把數據「推」到遠程的辦公室，以增加數據的安全性。復制技術是內置在LDAP伺服器中的而且很容易配置。如果要在DBMS中使用相同的復制功能，資料庫廠商就會要你支付額外的費用，而且也很難管理。
H. 在電子政務方案中看到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.e合並，這個方法就不能用了）。如果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: [email protected]
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: [email protected]
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目錄伺服器為他們完成了所有的數據交換工作。
I. ldap是什麼意思
LDAP指輕型目錄訪問協議。
輕型目錄訪問協議（英文：Lightweight Directory Access Protocol，縮寫：LDAP，／ˈɛldæp/）是一個開放的，中立的，工業標準的應用協議，通過IP協議提供訪問控制和維護分布式信息的目錄信息。
目錄服務在開發內部網和與互聯網程序共享用戶、系統、網路、服務和應用的過程中占據了重要地位。例如，目錄服務可能提供了組織有序的記錄集合，通常有層級結構，例如公司電子郵件目錄。同理，也可以提供包含了地址和電話號碼的電話簿。
協議內容
LDAP目錄與普通資料庫的主要不同之處在於數據的組織方式，它是一種有層次的、樹形結構。所有條目的屬性的定義是對象類object class的組成部分，並組成在一起構成schema；那些在組織內代表個人的schema被命名為white pages schema。