Directory Services(目錄服務)

我們知道，當局域網的規模變的越來越大時，為了方便主機管理，我們使用DHCP來實現IP地址、乙太網地址、主機名和拓撲結構等的集中管理和統一分配。同樣，如果一個區域網內有許多的其它資源時，如印表機、共享資料夾等等，為了方便的定位及查詢它們，一種集中定位管理的方式或許是較好的選擇，DNS和NIS都是用來實現類似管理的方法。

對於區域網內的一個使用者來講，工作等其它應用需要，我們必須憑帳號登入主機、用帳號收發E-mail，甚至為了管理需要公司還需要維護一個電子號碼簿來儲存員工的姓名、地址、電話號碼等資訊。隨著時間的增長，我們會為這些越來越多的帳號和密碼弄的頭暈腦脹。同時，如果一個員工離開，管理員就不得不翻遍所有的記錄帳號資訊的檔案把離職員工的資訊刪除。這些將是一個繁瑣而效率低下的工作。那麼，如果能將此些帳號資訊等統一到一個檔案中進行管理，無疑會大大提高員工及管理員的工作效率。目錄服務（LDAP是其實現的一種）正是基於這些應用實現的。

LDAP

LDAP是Lightweight Directory Access Protocol的縮寫，顧名思義，它是指輕量級目錄訪問協議（這個主要是相對另一目錄訪問協議X.500而言的；LDAP略去了x.500中許多不太常用的功能，且以TCP/IP協議為基礎）。目錄服務和資料庫很類似，但又有著很大的不同之處。資料庫設計為方便讀寫，但目錄服務專門進行了讀優化的設計，因此不太適合於經常有寫操作的資料儲存。同時，LDAP只是一個協議，它沒有涉及到如何儲存這些資訊，因此還需要一個後端資料庫元件來實現。這些後端可以 是bdb(BerkeleyDB)、ldbm、shell和passwd等。

LDAP目錄以樹狀的層次結構來儲存資料（這很類同於DNS），最頂層即根部稱作“基準DN”，形如"dc=mydomain,dc=org"或者"o= mydomain.org"，前一種方式更為靈活也是Windows AD中使用的方式。在根目錄的下面有很多的檔案和目錄，為了把這些大量的資料從邏輯上分開，LDAP像其它的目錄服務協議一樣使用OU （Organization Unit），可以用來表示公司內部機構，如部門等，也可以用來表示裝置、人員等。同時OU還可以有子OU，用來表示更為細緻的分類。

LDAP中每一條記錄都有一個唯一的區別於其它記錄的名字DN（Distinguished Name）,其處在“葉子”位置的部分稱作RDN；如dn:cn=tom,ou=animals,dc=mydomain,dc=org中tom即為 RDN；RDN在一個OU中必須是唯一的。

因為LDAP資料是“樹”狀的，而且這棵樹是可以無限延伸的，假設你要樹上的一個蘋果（一條記錄），你怎麼告訴園丁它的位置呢？當然首先要說明是哪一棵樹（dc，相當於MYSQL的DB），然後是從樹根到那個蘋果所經過的所有“分叉”（ou，呵呵MYSQL裡面好象沒有這 DD），最後就是這個蘋果的名字（uid，記得我們設計MYSQL或其它資料庫表時，通常為了方便管理而加上一個‘id’欄位嗎？）。好了！這時我們可以清晰的指明這個蘋果的位置了，就是那棵“歪脖樹”的東邊那個分叉上的靠西邊那個分叉的再靠北邊的分叉上的半紅半綠的……，暈了！你直接爬上去吧！我還是說說LDAP裡要怎麼定義一個欄位的位置吧，樹（dc=waibo,dc=com)，分叉（ou=bei,ou=xi,ou= dong），蘋果（cn=honglv），好了！位置出來了：

LDAP 協議既是跨平臺的也是基於標準的。這意味著幾乎在任何計算機平臺上執行的任何應用程式都可以從LDAP目錄獲取資訊。另外，無論什麼伺服器作業系統、檔案系統或平臺對於客戶機都是無關緊要的。

LDAP目錄幾乎可以儲存所有型別的資料：電子郵件地址、DNS 資訊、NIS 對映、安全性金鑰、聯絡人資訊列表和計算機名等。如果需要專門的組織單元或項，則可以根據具體實現來定製控制給定欄位可以儲存哪種資訊的規則（稱為模式，稍後將詳細討論）。

大多數 LDAP 伺服器的安裝和配置相對比較簡單，並且可以在很少或沒有維護的情況下執行多年，而且很容易為特定型別的訪問而進行最優化。

可以容易地配置 LDAP 目錄來複制部分或所有目錄樹（使用推(push)或拉(pull)方法）。這可以使系統管理員不必擔心出現單點故障的情況。

可以通過 ACL（訪問控制表，Access Control List）來控制對目錄的訪問。例如，管理員可以根據給定組或位置中的成員資格來限制誰可以看到哪些內容，或者給予特殊使用者在其自己記錄中修改所選欄位的能力。ACL 提供極其細粒度的訪問控制，而且 ACL 將這種控制與 LDAP 安裝結合在一起，而不是與請求資訊的客戶機結合在一起。此外，可以容易地將 LDAP 與大多數現有的安全性層和／或認證系統（例如 SSL、Kerberos 和 PAM 等）整合在一起。

LDIF

LDIF(LDAP Interchange Format)是指儲存LDAP配置資訊及目錄內容的標準文字檔案格式，之所以使用文字檔案來格式來儲存這些資訊是為了方便讀取和修改，這也是其它大多數 服務配置檔案所採取的格式。LDIF檔案常用來向目錄匯入或更改記錄資訊，這些資訊需要按照LDAP中schema的格式進行組織，並會接受schema 的檢查，如果不符合其要求的格式將會出現報錯資訊。LDIF檔案樣例如下：

dn:cn=stan,ou=linux,ou=computer,dc=ourschool,dc=org

objectClass：organizationalPerson

cn:stan

cn:czm

sn:czm

其中，以“#”號開頭的為註釋行；第二行起的行中，冒號左邊為屬性，右邊是屬性的值，這類同於程式設計中的變數及為其所賦的值，但屬性可以被重複賦值。
注意：同一個屬性可以有一個或者多個值，ldap在定址時，可以根據同一個屬性的不同值進行定址，例如上例中可以根據cn屬性的stan和czm進行定址，這樣速度更快。

objectClass 

物件類由 LDAP 目錄使用來定義給定型別的物件可以有哪些屬性。物件類還定義項必須有什麼屬性，以及項可以有什麼屬性。所有物件類都從其父物件類繼承需求，然後新增它們自己的需求。

物件類有五個元件：OID（物件標識）、唯一名稱、父物件（SUP）、任何需要的屬性（MUST）和允許的屬性列表（MAY）。OID是由LDAP目錄的內部資料庫機制使用的資料識別符號。從概念上講，它們與IP地址相似，因為每個物件類都必須有一個唯一數字。並且象DNS和IP之間的關係那樣，由建立它們的個人進行註冊，並由這些人“擁有”。

在LDAP中objectClass分為三種：Abstract，Structural，AUXIALIARY。要定義一個Entry必須包含一個Structural型別的ObjectClass，

其他兩個型別可包括0或多個。其中Top是一個頂級ObjectClass，裡面定義了一個MUST Attribute：ObjectClass，於是也就決定了必須有

一個其它的Structural ObjectClass才能定義一個Entry.其中ObjectClass又可以存在繼承關係，子ObjectClass會繼承父ObjectClass中的

全部Attribute.該繼承關係於Java中有點相似.

在LDAP中每一個ObjectClass都定義了一些Attribute，其Attribute仍然可以是ObjectClass。在這些Attriubte中分為兩種型別MUST，MAY， MUST表示這個Entry必須包括的屬性，MAY為可選。一個ObjectClass的Attribute也包括所有繼承自父ObjectClass和自身定義的ObjectClass。

下面用一個型別進行說明：

objectclass ( 2.5.6.0 NAME 'top' ABSTRACT

    MUST objectClass )

objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'

    DESC 'RFC2247: domain component object'

    SUP top AUXILIARY 

    MUST dc )

上面是兩個objectclass的定義，其中top為ABSTRACT，dcObject為AUXILIARY，這兩個型別都不能定義Entry.

下面這個LDIF檔案在匯入到LDAP時會出錯：

dn: dc=java,dc=com

objectClass:dcObject

dc: java.com

要定義這個Entry必須找到一個STRUCTURAL型別的ObjectClass。

objectClasses: ( 2.5.6.4 NAME 'organization' 

DESC 'RFC2256: an organization' SUP top STRUCTURAL

MUST o 

MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory 

   $ x121Address $ registeredAddress $ destinationIndicator

   $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier

   $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber

   $ street $ postOfficeBox $ postalCode $ postalAddress 

   $ physicalDeliveryOfficeName $ st $ l $ description ) )

這個objectClass的型別為STRUCTURAL，因此可以用來定義Entry.具體定義如下

dn: dc=java,dc=com

objectClass:dcObject

objectClass:organization

dc: java.com

o: java.com

Attribute

Attribute類同於程式語言中的變數，它可以被賦值，就像是可以存放一個單一型別資訊的容器。官方聲明瞭許多常用的 Attribute,如果其中沒有你所需要的，你可以自己定義，但要避免重名。objectClass是一種特殊的Attribute，它包含其它用到的 Attribute以及它自身。常見的Attribute如下：

schema

LDAP中，schema用來指定一個目錄中所包含的objects的型別 （objectClass）以及每一個objectClass中的各個必備（mandatory）和可選（optional）的屬性 （attribute）。因此，Schema是一個數據模型，它被用來決定資料怎樣被儲存，被跟蹤的資料的是什麼型別，儲存在不同的Entry下的資料之間的關係。schema 需要在主配置檔案slapd.conf中指定，以用來決定本目錄中使用到的objectClass。管理員可以自己設計制定schema，一般包括屬性定 義（AttributeDefinition）、類定義（ClassDefinition）以及語法定義（SyntaxDefinition）等部分。   

LDAP V3中在x.500標準的基礎上定義了一個包含了網路中大多常見物件的schema，這些物件包括國家、所在地、組織、人員、小組以及裝置等。同時，LDAP V3中可以很方便的從目錄中提取出schema，它正是一條記錄中關於屬性的宣告部分。

物件識別符號

物件識別符號（ Object Identifiers ）是被LDAP內部資料庫引用的數字標識。Attribute的名字是設計為方便人們讀取的，但為了方便計算機的處理，通常使用一組數字來標識這些物件，這類同於SNMP中的MIB2。例如，當計算機接收到dc這個Attribute時，它會將這個名字轉換為對應的OID： 1.3.6.1.4.1.1466.115.121.1.26。

幾點體會

重大誤解

很多所謂基於LDAP實現的認證都是使用目錄來儲存加密(多數是MD5)後的密碼而已.但是這種密碼很好被暴力破解.於是你的系統的安全狀態有退回到未 shadow過的/etc/passwd時代.在介紹目錄服務的書籍中提到/etc/passwd也算是一種目錄.我們不能說一個文字檔案是用來做認證的吧?

很多LDAP的實現和應用都不使用LDAP來作驗證.如微軟的活動目錄.還有斯坦福大學的目錄都使用了kerberos.配置好的Windows域控制器本身就是一個Kerberos KDC.而斯坦福的目錄也採用了Hedimal的Kerberos實現來做KDC和一個Windows 的KDC.這樣的理由很明顯的.如果要通過過LDAP目錄來實現一個十分安全的認證資訊的儲存要藉助大量的外圍協議.還不如直接使用這些協議本身.長話短說,我們應該讓目錄儲存它改儲存的東西.

產品選擇

產品的選擇取決於你部署目錄服務的目的以及內容.如果活動目錄提供給你的那些的功能足夠你的需要.那麼採用活動目錄好了.因為他一開始就將安全實現的很好(作業系統安全不在討論之列).而且配置簡單.而且和客戶端(windows)相容的較好.

如果你想在深入研究LDAP協議.或者要實現一個高度自定義的目錄.那麼選擇OpenLDAP吧!

安全措施.

儘量少將安全敏感的資訊儲存在目錄中.如果非存不可.一定要編輯ACL嚴格的控制訪問許可權如userPassword等.多數情況下目錄服務還要主要是給其他的服務提供資料儲存.這樣的話應該讓每個伺服器繫結到不通的DN,同時在ACL中賦予他們較高的許可權.而不能讓所有的服務都使用rootdn來繫結.

目錄結構的設計

雖然目錄結構的設計可以比較靈活.但比較有經驗的設計可以使你的目錄結構更加合理,而且可以給你帶來意想不到的好處.儘量參照前人實現的產品一吸收好的思想.分析微軟的設計,在目錄中建立分組的目錄樹是明智的做法.這樣每個帳戶的memberof屬性的值他所屬的組的DN,這樣就可以方便的將基於組的訪問控制列表也實現在目錄結構中.相象如果活動目錄中使用者的memberof屬性是"Aministrators"而不是"CN= Administrators,CN=Builtin,DC=example,DC=edu,DC=cn"的話會給微軟帶來多少麻煩?儘量的將更多的資料以樹的形式組織,同時在欄位中使用更多的DN代替單一的數值,可以最大限度的發揮目錄服務的潛力.
AD和LDAP的關係

參考至：http://doc.linuxpk.com/2293.html
             http://doc.linuxpk.com/2583.html 
             http://doc.linuxpk.com/2586.html 
             http://doc.linuxpk.com/28400.html
             http://bbs.chinaunix.net/thread-889055-1-1.html 
             http://hi.baidu.com/dongyuejiang/item/d2af278125f05d5d26ebd9a0
             http://linux.chinaitlab.com/special/ldap/Index.html 
本文原創，轉載請註明出處
如有錯誤，歡迎指正
郵箱:[email protected]