介紹LDAP
介紹LDAP
原文：http://ldapman.org/articles/intro_to_ldap.html
原文作者：Michael Donnelly
翻譯：Brimmer
如果你在電腦行業工作，那麼對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通常使用下面列出的三種格式之一。假定我在名為Bueno的電子商務公司工作，這家公司在Internet上的名字是Bueno.com。
o="Bueno, Inc.", c=US
（以X.500格式表示的基準DN）
在這個例子中，o=Bueno, Inc. 表示組織名，在這裡就是公司名的同義詞。c=US 表示公司的總部在美國。以前，一般都用這種方式來表示基準DN。但是事物總是在不斷變化的，現在所有的公司都已經（或計劃）上Internet上。隨著Internet的全球化，在基準DN中使用國家程式碼很容易讓人產生混淆。現在，X.500格式發展成下面列出的兩種格式。
o=Bueno.com
（用公司的Internet位址表示的基準DN）
這種格式很直觀，用公司的域名作為基準DN。這也是現在最常用的格式。
dc=Bueno, dc=com
（用DNS域名的不同部分組成的基準DN）
就像上面那一種格式，這種格式也是以DNS域名為基礎的，但是上面那種格式不改變域名（也就更易讀），而這種格式把域名：Bueno.com分成兩部分 dc=Bueno, dc=com。在理論上，這種格式可能會更靈活一點，但是對於最終用戶來說也更難記憶一點。考慮一下Bueno.com這個例子。當Bueno.com和gizmo.com合併之後，可以簡單的把「dc=com」當作基準DN。把新的記錄放到已經存在的dc=gizmo, dc=com目錄下，這樣就簡化了很多工作（當然，如果Bueno.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=Bueno, 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=Bueno,dc=com
l 我把自己的食譜作為LDAP的記錄項存在ou=recipes
l 我的LDAP記錄項的RDN設為cn=Oatmeal Deluxe
上面這些構成了燕麥粥食譜的LDAP記錄的完整DN。記住，DN的讀法和DNS主機名類似。下面就是完整的DN：
cn=Oatmeal Deluxe,ou=recipes,dc=Bueno,dc=com
舉一個實際的例子來說明DN
現在為公司的員工設定一個DN。可以用關於cn或uid（User ID），作為典型的用戶帳號。例如，Bueno的員工Fran Grace（登入名：fGrace）的DN可以為下面兩種格式：
uid=fGrace,ou=employees,dc=Bueno,dc=com
（關於登入名）
LDAP（以及X.500）用uid表示「User ID」，不要把它和UNIX的uid號混淆了。大多數公司都會給每一個員工唯一的登入名，因此用這個辦法可以很好地儲存員工的信息。你不用擔心以後還會有一個叫Fran Grace的加入公司，如果Fran改變了她的名字（結婚？離婚？或宗教原因？），也用不著改變LDAP記錄項的DN。
cn=Fran Grace,ou=employees,dc=Bueno,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=Bueno, 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目錄不必花費記憶體或硬碟空間處理「空」域，也就是說，實際上不使用可選項的域也不會花費你任何資源。
作為例子的一個單獨的資料項
讓我們看看下面這個例子。我們用Bueno, Inc.的員工Fran Grace的LDAP記錄。這個記錄項的格式是LDIF，用來匯入和匯出LDAP目錄的記錄項。
dn: uid=fGrace, ou=employees, dc=Bueno, dc=com
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: BuenoPerson
uid: fGrace
givenname: Fran
sn: Grace
cn: Fran Grace
cn: Frances Grace
telephonenumber: 510-555-1234
roomnumber: 122G
o: Bueno, Inc.
mailRoutingAddress: fGrace@Bueno.com
mailhost: mail.Bueno.com
userpassword: {crypt}3x1231v76T89N
uidnumber: 1234
gidnumber: 1200
homedirectory: /home/fGrace
loginshell: /usr/local/bin/bash
內容的值在儲存的時候是保留大小寫的，但是在預設情況下搜尋的時候是不區分大小寫的。某些特殊的內容（例如，password）在搜尋的時候需要區分大小寫。
讓我們一點一點地分析上面的記錄項。
dn: uid=fGrace, ou=employees, dc=Bueno, dc=com
這是Fran的LDAP記錄項的完整DN，包括在目錄樹中的完整路徑。LDAP（和X.500）使用uid（User ID），不要把它和UNIX的uid號混淆了。
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: BuenoPerson
可以為任何一個對像根據需要分配多個對象類型。person對像類型要求cn（common name）和sn（surname）這兩個域不能為空。persion對像類型允許有其它的可選域，包括givenname、telephonenumber，等等。organizational Person給person加入更多的可選域，inetOrgPerson又加入更多的可選域（包括電子郵件信息）。最後，BuenoPerson是為Bueno定制的對象類型，加入了很多定制的內容。
uid: fGrace
givenname: Fran
sn: Grace
cn: Fran Grace
cn: Frances Grace
telephonenumber: 510-555-1234
roomnumber: 122G
o: Bueno, Inc.
以前說過了，uid表示User ID。當看到uid的時候，就在腦袋裡想一想「login」。
請注意CN有多個值。就像上面介紹的，LDAP允許某些內容有多個值。為什麼允許有多個值呢？假定你在用公司的LDAP伺服器搜尋Fran的電話號碼。你可能只知道她的名字叫Fran，但是對人力資源處的人來說她的正式名字叫做Frances。因為儲存了她的兩個名字，所以用任何一個名字檢索都可以找到Fran的電話號碼、電子郵件和辦公房間號，等等。
mailRoutingAddress: fGrace@Bueno.com
mailhost: mail.Bueno.com
就像現在大多數的公司都上網了，Bueno用Sendmail傳送郵件和處理外部郵件路由信息。Bueno把所有用戶的郵件信息都存在LDAP中。最新版本的Sendmail支持這項功能。
Userpassword: {crypt}3x1231v76T89N
uidnumber: 1234
gidnumber: 1200
gecos: Frances Grace
homedirectory: /home/fGrace
loginshell: /usr/local/bin/bash
注意，Bueno的系統管理員把所有用戶的密碼映射信息也都存在LDAP中。BuenoPerson類型的對象具有這種能力。再注意一下，用戶密碼是用UNIX的密碼加密格式存儲的。UNIX的uid在這裡為uidnumber。提醒你一下，關於如何在LDAP中儲存NIS信息，有完整的一份RFC。在以後的文章中我會談一談NIS的集成。
LDAP複製
LDAP伺服器可以使用關於「推」或者「拉」的技術，用簡單或關於安全證書的安全驗證，複製一部分或者所有的資料。
例如，Bueno有一個「公用的」LDAP伺服器，位址為ldap.Bueno.com，連接埠為389。Netscape Communicator的電子郵件查詢功能、UNIX的「ph」指令要用到這個伺服器，用戶也可以在任何地方查詢這個伺服器上的員工和客戶聯繫信息。公司的主LDAP伺服器執行在相同的電腦上，不過連接埠號是1389。
你可能即不想讓員工查詢資產管理或食譜的信息，又不想讓信息技術人員看到整個公司的LDAP目錄。為了解決這個問題，Bueno有選項地把子目錄樹從主LDAP伺服器複製到「公用」LDAP伺服器上，不複製需要隱藏的信息。為了保持資料始終是最新的，主目錄伺服器被設定成即時「推」同步。這些種方法主要是為了方便，而不是安全，因為如果有權限的用戶想查詢所有的資料，可以用另一個LDAP連接埠。
假定Bueno通過從奧克蘭到歐洲的低帶寬資料的連接用LDAP管理客戶聯繫信息。可以建立從ldap.Bueno.com:1389到munich-ldap.Bueno.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，允許「Bueno-sales」組中的成員有選項地給予或禁止他們自己讀取一部分客戶聯繫資料的讀權限。這將允許他們把客戶聯繫信息下載到本機的筆記型電腦或個人數字助理（PDA）上。（如果銷售人員的軟體都支持LDAP，這將非常有用）
l 通過Web，允許組的所有者刪除或增加他們擁有的組的成員。例如：可以允許銷售經理給予或禁止銷售人員改變Web頁的權限。也可以允許郵件假名（mail aliase）的所有者不經過IT技術人員就直接從郵件假名中刪除或增加用戶。「公用」的郵件列表應該允許用戶從郵件假名中增加或刪除自己（但是只能是自己）。也可以對IP位址或主機名加以限制。例如，某些域只允許用戶IP位址以192.168.200.*開頭的有讀的權限，或者用戶反向搜尋DNS得到的主機名必須為*.Bueno.com。
這不過是讓你瞭解一下可以對LDAP目錄進行怎樣的訪問控制，實際上真正實現起來需要做的工作比這多得多。在以後的文章中我會詳細地討論訪問控制。
留言列表
