LDAP主要特點
1.LDAP目錄服務可以有效地解決眾多網路服務的用戶賬戶問題。
2.LDAP目錄服務規定了統一的身份信息資料庫、身份認證機制和接口，實現了資源和信息的統一管理，保證了數據的一致性和完整性。
3.LDAP目錄服務是以樹狀的層次結構來描述數據信息的，此種模型適應了眾多行業套用的業務組織結構。
跨平台
可以在任何計算機平台上，用很容易獲得的而且數目不斷增加的LDAP的客戶端程式訪問LDAP目錄。而且也很容易定製應用程式為它加上LDAP的支持。
LDAP協定是跨平台的和標準的協定，因此應用程式就不用為LDAP目錄放在什麼樣的伺服器上操心了。實際上，LDAP得到了業界的廣泛認可，因為它是Internet的標準。產商都很願意在產品中加入對LDAP的支持，因為他們根本不用考慮另一端（客戶端或服務端）是怎么樣的。LDAP伺服器可以是任何一個開發原始碼或商用的LDAP目錄伺服器（或者還可能是具有LDAP界面的關係型資料庫），因為可以用同樣的協定、客戶端連線軟體包和查詢命令與LDAP伺服器進行互動。與LDAP不同的是，如果軟體產商想在軟體產品中集成對DBMS的支持，那么通常都要對每一個資料庫伺服器單獨定製。
費用低、維護簡單
不象很多商用的關係型資料庫，用戶不必為LDAP的每一個客戶端連線或許可協定付費。大多數的LDAP伺服器安裝起來很簡單，也容易維護和最佳化。
複製技術
LDAP伺服器可以用“推”或“拉”的方法複製部分或全部數據，例如：可以把數據“推”到遠程的辦公室，以增加數據的安全性。複製技術是內置在LDAP伺服器中的而且很容易配置。如果要在DBMS中使用相同的複製功能，資料庫產商就會要求支付額外的費用，而且也很難管理。
允許使用ACL
LDAP允許根據需要使用ACL（訪問控制列表）控制對數據讀和寫的許可權。例如，設備管理員可以有權改變員工的工作地點和辦公室號碼，但是不允許改變記錄中其它的域。ACL可以根據誰訪問數據、訪問什麼數據、數據存在什麼地方以及其它對數據進行訪問控制。因為這些都是由LDAP目錄伺服器完成的，所以不用擔心在客戶端的應用程式上是否要進行安全檢查。
存儲數據
LDAP存儲什麼數據
LDAP對於數據需要從不同的地點讀取，但是不需要經常更新，這些信息存儲在LDAP目錄中是十分有效的，例如：
公司員工的電話號碼簿和組織結構圖
客戶的聯繫信息
計算機管理需要的信息，包括NIS映射/、email/名稱等
軟體包的配置信息
公用證書和安全密匙
什麼時候用LDAP存儲數據
大多數的LDAP伺服器都為讀密集型的操作進行專門的最佳化。因此，當從LDAP伺服器中讀取數據的時候會比從專門為OLTP最佳化的關係型資料庫中讀取數據快一個數量級。也是因為專門為讀的性能進行最佳化，大多數的LDAP目錄伺服器並不適合存儲需要經常改變的數據。例如，用LDAP伺服器來存儲電話號碼是一個很好的選擇，但是它不能作為電子商務站點的資料庫伺服器。
基本模型
信息模型：描述LDAP的信息表示方式
在LDAP中信息以樹狀方式組織，在樹狀信息中的基本數據單元是條目，而每個條目由屬性構成，屬性中存儲有屬性值；LDAP中的信息模式，類似於面向對象的概念，在LDAP中每個條目必須屬於某個或多個對象類（Object Class），每個Object Class由多個屬性類型組成，每個屬性類型有所對應的語法和匹配規則；對象類和屬性類型的定義均可以使用繼承的概念。每個條目創建時，必須定義所屬的對象類，必須提供對象類中的必選屬性類型的屬性值，在LDAP中一個屬性類型可以對應多個值。
在LDAP中把對象類、屬性類型、語法和匹配規則統稱為Schema，在LDAP中有許多系統對象類、屬性類型、語法和匹配規則，這些系統Schema在LDAP標準中進行了規定，同時不同的套用領域也定義了自己的Schema，同時用戶在套用時，也可以根據需要自定義Schema。這有些類似於XML，除了XML標準中的XML定義外，每個行業都有自己標準的DTD或DOM定義，用戶也可以自擴展；也如同XML，在LDAP中也鼓勵用戶儘量使用標準的Schema，以增強信息的互聯互通。
在Schema中最難理解的是匹配規則，這是LDAP中為了加快查詢的速度，針對不同的數據類型，可以提供不同的匹配方法，如針對字元串類型的相等、模糊、大於小於均提供自己的匹配規則。
命名模型：描述LDAP中的數據如何組織
LDAP中的命名模型，也即LDAP中的條目定位方式。在LDAP中每個條目均有自己的DN和RDN。DN是該條目在整個樹中的唯一名稱標識，RDN是條目在父節點下的唯一名稱標識，如同檔案系統中，帶路徑的檔案名稱就是DN，檔案名稱就是RDN。
功能模型：描述LDAP中的數據操作訪問
在LDAP中共有四類10種操作：查詢類操作，如搜尋、比較；更新類操作，如添加條目、刪除條目、修改條目、修改條目名；認證類操作，如綁定、解綁定；其它操作，如放棄和擴展操作。除了擴展操作，另外9種是LDAP的標準操作；擴展操作是LDAP中為了增加新的功能，提供的一種標準的擴展框架，當前已經成為LDAP標準的擴展操作，有修改密碼和STARTTLS擴展，在新的RFC標準和草案中正在增加一些新的擴展操作，不同的LDAP廠商也均定義了自己的擴展操作。
安全模型：描述LDAP中的安全機制
LDAP中的安全模型主要通過身份認證、安全通道和訪問控制來實現。
1.身份認證
在LDAP中提供三種認證機制，即匿名、基本認證和SASL（Simple Authentication and Secure Layer）認證。匿名認證即不對用戶進行認證，該方法僅對完全公開的方式適用；基本認證均是通過用戶名和密碼進行身份識別，又分為簡單密碼和摘要密碼認證；SASL認證即LDAP提供的在SSL和TLS安全通道基礎上進行的身份認證，包括數字證書的認證。
2.通訊安全
在LDAP中提供了基於SSL/TLS的通訊安全保障。SSL/TLS是基於PKI信息安全技術，是目前Internet上廣泛採用的安全服務。LDAP通過StartTLS方式啟動TLS服務，可以提供通訊中的數據保密性、完整性保護；通過強制客戶端證書認證的TLS服務，同時可以實現對客戶端身份和伺服器端身份的雙向驗證。
3.訪問控制
雖然LDAP目前並無訪問控制的標準，但從一些草案中或是事實上LDAP產品的訪問控制情況，我們不難看出：LDAP訪問控制異常的靈活和豐富，在LDAP中是基於訪問控制策略語句來實現訪問控制的，這不同於現有的關係型資料庫系統和套用系統，它是通過基於訪問控制列表來實現的，無論是基於組模式或角色模式，都擺脫不了這種限制。
在使用關係型資料庫系統開發套用時，往往是通過幾個固定的資料庫用戶名訪問資料庫。對於套用系統本身的訪問控制，通常是需要建立專門的用戶表，在套用系統內開發針對不同用戶的訪問控制授權代碼，這樣一旦訪問控制策略變更時，往往需要代碼進行變更。總之一句話，關係型資料庫的套用中用戶數據管理和資料庫訪問標識是分離的，複雜的數據訪問控制需要通過套用來實現。而對於LDAP，用戶數據管理和訪問標識是一體的，套用不需要關心訪問控制的實現。這是由於在LDAP中的訪問控制語句是基於策略語句來實現的，無論是訪問控制的數據對象，還是訪問控制的主體對象，均是與這些對象在樹中的位置和對象本身的數據特徵相關。
在LDAP中，可以把整個目錄、目錄的子樹、制定條目、特定條目屬性集或符合某過濾條件的條目作為控制對象進行授權；可以把特定用戶、屬於特定組或所有目錄用戶作為授權主體進行授權；最後，還可以定義對特定位置（例如IP位址或DNS名稱）的訪問權。
數據結構
LDAP是實現了指定的數據結構的存貯，它包括以下可以用關係資料庫實現的結構要求：樹狀組織、條目認證、類型定義、許可樹形記錄拷貝。
樹狀組織
無論是X500還是LDAP都是採用樹狀方式進行記錄。每一個樹目錄都有一個樹根的入口條目，子記錄全部是這一根條目的子孫。這是目錄與關係數據類型最大的區別（關係資料庫的套用結構也可實現樹狀記錄）。因此，把目錄看作是更高級的樹狀資料庫也未嘗不可，只不過除此外，它不能實現關係存貯的重要功能。
條目和條目認證
LDAP是以條目作為認證的根據。ROOT的許可權認證與目錄本身無關，但除此外所有條目的認證許可權由條目本身的密碼進行認證。LDAP可以配置成各種各樣不同的父子條目許可權繼承方式。
每一個條目相當於一個單一的平面文本記錄，由條目自身或指定的條目認證進行訪問控制。因此，LDAP定義的存貯結構等同於一批樹狀組織的平面資料庫，並提供相應的訪問控制。
條目中的記錄以名-值對的形式存在，每一個名值對必須由數據樣式schema預定義。因此，LDAP可以看作是以規定的值類型以名值對形式存貯在一系列以樹狀組織的平面資料庫的記錄的集合。
數據樣式
數據樣式schema是針對不同的套用，由用戶指定（設計）類和屬性類型預定義，條目中的類(objectclass)和屬性必須在在LDAP伺服器啟動時載入記憶體的schema已有定義。因此，AD活動目錄中的條目記錄就必須符合Active Directory的schema中。如果已提供的schema中的定義不夠用，用戶可以自行定義新的schema。
對象類型
因為LDAP目錄可以定製成存儲任何文本或二進制數據，到底存什麼要由用戶自己決定。LDAP目錄用對象類型（objectclass）的概念來定義運行哪一類的對象使用什麼屬性。在幾乎所有的LDAP伺服器中，都要根據自己的需要擴展基本的LDAP目錄的功能，創建新的對象類型或者擴展現存的對象類型。
條目中的記錄通過objectclass實現分類，objectClass是一個繼承性的類定義，每一個類定義指定必須具備的屬性。如某一條目指定必須符合某個類型，則它必須具備超類所指定的屬性。
通過objectclass分類，分散的條目中的記錄就實際上建立了一個索引結構，為高速的讀查詢打下了基礎。Objectclass也是過濾器的主要查詢對象。
過濾器和語法
LDAP是一個查詢為主的記錄結構，無論是何種查詢方式，最終都由過濾器缺點查詢的條件。過濾器相當於SQL中的WHERE子句。任何LDAP的類過濾和字元串都必須放在括弧內，如（objectclass=*）,指列出所有類型的記錄。
基本 LDAP 語法
• =（等於）
此 LDAP 參數表明某個屬性等於某個值的條件得到滿足。例如，如果希望查找“名“屬性為“John”的所有對象，可以使用：
(givenName=John)
這會返回“名”屬性為“John”的所有對象。圓括弧是必需的，以便強調 LDAP 語句的開始和結束。
• &（邏輯與）
如果具有多個條件並且希望全部條件都得到滿足，則可使用此語法。例如，如果希望查找居住在 Dallas 並且“名”為“John”的所有人員，可以使用：
(&(givenName=John)(l=Dallas))
請注意，每個參數都被屬於其自己的圓括弧括起來。整個 LDAP 語句必須包括在一對主圓括弧中。操作符 & 表明，只有每個參數都為真，才會將此篩選條件套用到要查詢的對象。
• !（邏輯非）
此操作符用來排除具有特定屬性的對象。假定需要查找“名”為“John”的對象以外的所有對象。則應使用如下語句：
(!givenName=John)
此語句將查找“名”不為“John”的所有對象。請注意：! 操作符緊鄰參數的前面，並且位於參數的圓括弧內。由於本語句只有一個參數，因此使用圓括弧將其括起以示說明。
• *（通配符）
可使用通配符表示值可以等於任何值。使用它的情況可能是：希望查找具有職務頭銜的所有對象。為此，可以使用：
(title=*)
這會返回“title”屬性包含內容的所有對象。另一個例子是：知道某個對象的“名”屬性的開頭兩個字母是“Jo”。那么，可以使用如下語法進行查找：
(givenName=Jo*)
這會返回“名”以“Jo”開頭的所有對象。
典型套用
由於LDAP所具有的查詢效率高、樹狀的信息管理模式、分散式的部署框架以及靈活而細膩的訪問控制，使LDAP廣泛地套用於基礎性、關鍵性信息的管理，如用戶信息、網路資源信息等。LDAP的套用主要涉及幾種類型。
信息安全類：數字證書管理、授權管理、單點登錄；
科學計算類：DCE (Distributed Computing Envirionment，分散式計算環境)、UDDI （Universal Description，Discovery and Integration, 統一描述、發現和集成協定）；
網路資源管理類：MAIL系統、DNS系統、網路用戶管理、電話號碼簿；電子政務
資源管理類：區域網路組織信息服務、電子政務目錄體系、人口基礎庫、法人基礎庫。
LDAP提供很複雜的不同層次的訪問控制或者ACI。因這些訪問可以在伺服器端控制，這比用客戶端的軟體保證數據的安全可安全多了。例如使用用LDAP的ACL，可以完成：
1. 給予用戶改變他們自己的電話號碼和家庭地址的許可權，但是限制他們對其它數據（如，職務名稱，登錄名等）只有“唯讀”許可權。
2. 給予“HR-admins”組中的所有人許可權以改變下面這些用戶的信息：經理、工作名稱、員工號、部門名稱和部門號。但是對其它域沒有寫許可權。
3. 禁止任何人查詢LDAP伺服器上的用戶口令，但是可以允許用戶改變他自己的口令。
4. 給予經理訪問他們上級的家庭電話的唯讀許可權，但是禁止其他人有這個許可權。
5. 給予“host-admins”組中的任何人創建、刪除和編輯所有保存在LDAP伺服器中的與計算機主機有關的信息
6. 通過Web，允許“foobar-sales”組中的成員有選擇地給予或禁止他們自己讀取一部分客戶聯繫數據的讀許可權。這將允許他們把客戶聯繫信息下載到本地的筆記本電腦或個人數字助理（PDA）上。
7. 通過Web，允許組的所有者刪除或添加他們擁有的組的成員。例如：可以允許銷售經理給予或禁止銷售人員改變Web 頁的許可權。也可以允許郵件別名（mail aliase）的所有者不經過IT技術人員就直接從郵件別名中刪除或添加用戶。
8. “公用”的郵件列表應該允許用戶從郵件假名中添加或刪除自己（但是只能是自己）。也可以對IP位址或主機名加以限制。例如，某些域只允許用戶IP位址以192.168.200.*開頭的有讀的許可權，或者用戶反向查找DNS得到的主機名必須為*.foobar.com。
與X.500的比較
從目錄服務技術的發展來看，LDAP標準實際上是在X.500標準基礎上產生的一個簡化版本，兩者之間的關係與那種為解決同一個問題出現的兩個獨立發展的技術有很大的不同之處，因此需要在此基礎上對這兩個標準進行理解和分析。
首先，作為IETF（Internet Engineering Task Force）一個正式的標準，LDAP是X.500標準中的目錄訪問協定DAP的一個子集，可用於建立X.500目錄。因此這兩個目錄服務技術標準有著許多的共同之處，即在平台上，都實現了一個通用的平台結構，提供了一個作業系統和應用程式需要的信息服務類型，可以被許多平台和應用程式接收和實現；在信息模型上，都使用了項、對象類、屬性等概念和模式來描述信息；在命名空間方面，都使用了目錄信息樹結構和層次命名模型；在功能模型上，都使用了相似的操作命令來管理目錄信息；在認證框架方面，都可以實現用戶名稱和密碼，或者基於安全加密方式的認證機制；在靈活性上，它們的目錄規模都可大可小，大到全球目錄樹，小到只有一台目錄伺服器；在分布性方面，目錄信息都可以分布在多個目錄伺服器中，這些伺服器可以由各組織管理，既保證了目錄信息總體結構一致性，又滿足了分級管理的需要。
LDAP與X.500的DAP相同之處是，LDAP也是被設計用來從分層目錄中提取信息。但與之不同的是，為保持網路的頻寬， LDAP對來自X.500目錄詢問的應答次數加以限制。最初LDAP只是一種訪問X.500目錄的簡單方法，是X.500的功能子集，但隨著它的成熟和獨立發展，已經增加了許多在X.500中沒有的新特性。現在的LDAP既可以為X.500目錄服務提供一個輕型前端，也可以實現一個獨立的目錄服務。
LDAP的獨特之處主要表現在如下幾個方面：
1. AP（Access Protocol）既是一個X.500的訪問協定，又是一個靈活的可以獨立實現的目錄系統。
2. DAP（Directory Access Protocol）基於Internet協定，X.500基於OSI（開放式系統互聯）協定：建立在套用層上的X.500 目錄訪問協定DAP，需要在OSI會話層和表示層上進行許多的建立連線和包處理的任務，需要特殊的網路軟體實現對網路的訪問；LDAP則直接運行在更簡單和更通用的TCP/IP或其它可靠的傳輸協定層上，避免了在OSI會話和表示層的開銷，使連線的建立和包的處理更簡單、更快，對於網際網路和企業網套用更理想。
3. LDAP協定更為簡單：LDAP繼承了X.500最好的特性，同時去掉了它的複雜性。LDAP通過使用查找操作實現列表操作和讀操作，另一方面省去了X.500中深奧的和很少使用的服務控制和安全特性，只保留常用的特性，簡化了LDAP的實現。
4. LDAP通過引用機制實現分散式訪問：X.500 DSA通過伺服器之間的鏈操作實現分散式的訪問，這樣查詢的壓力集中於伺服器端；而LDAP通過客戶端API實現分散式操作（對於套用透明）平衡了負載；
5. LDAP實現具有低費用、易配置和易管理的特點。經過性能測試，LDAP比X.500具有更少的回響時間；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: [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目錄伺服器為他們完成了所有的數據交換工作。
