一，部分LDAP專用名詞的解釋
Objectclass
LDAP對象類，是LDAP內置的數據模型。每種objectClass有自己的數據結構，比如我們有一種叫“電話薄”的objectClass，肯定會內置很多屬性(attributes)，如姓名(uid)，身份證號(uidNumber)，單位名稱(gid)，家庭地址(homeDirectory)等，同時，還有一種叫“同學錄”的objectClass，具備“電話薄”裏的一些attributes(如uid、homeDirectory)，還會具有“電話薄”沒有的attributes(如description等)。
Entry
entry可以被稱爲條目，一個entry就是一條記錄，是LDAP中一個基本的存儲單元；也可以被看作是一個DN和一組屬性的集合。注意，一條entry可以包含多個objectClass，例如zhang3可以存在於“電話薄”中，也可以同時存在於“同學錄”中。
DN
Distinguished Name，LDAP中entry的唯一辨別名，一條完整的DN寫法：uid=zhang3,ou=People,dc=163,dc=com。LDAP中的entry只有DN是由LDAP Server來保證唯一的。
LDAP Search filter
使用filter對LDAP進行搜索。 Filter一般由 (attribute=value) 這樣的單元組成，比如：(&(uid=ZHANGSAN)(objectclass=person)) 表示搜索用戶中，uid爲ZHANGSAN的LDAP Entry．再比如：(&(|(uid= ZHANGSAN)(uid=LISI))(objectclass=person))，表示搜索uid爲ZHANGSAN, 或者LISI的用戶；也可以使用*來表示任意一個值，比如(uid=ZHANG*SAN)，搜索uid值以 ZHANG開頭SAN結尾的Entry。更進一步，根據不同的LDAP屬性匹配規則，可以有如下的Filter： (&（createtimestamp>=20050301000000）(createtimestamp<=20050302000000))，表示搜索創建時間在20050301000000和20050302000000之間的entry。
Filter中 “&” 表示“與”；“!”表示“非”；“|”表示“或”。根據不同的匹配規則，我們可以使用“=”，“~=”，“>=”以及“<=”，更多關於LDAP Filter讀者可以參考LDAP相關協議。
Base DN
一條Base DN可以是“dc=163,dc=com”，也可以是“dc=People,dc=163,dc=com”。執行LDAP Search時一般要指定basedn，由於LDAP是樹狀數據結構，指定basedn後，搜索將從BaseDN開始，我們可以指定Search Scope爲：只搜索basedn（base），basedn直接下級（one level），和basedn全部下級（sub tree level）。
二，objectClass介紹
LDAP中，一個條目(Entry)必須包含一個對象類(objectClass)屬性，且需要賦予至少一個值。每一個值將用作一條LDAP條目進行數據存儲的模板；模板中包含了一個條目必須被賦值的屬性和可選的屬性。
objectClass有着嚴格的等級之分，最頂層是top和alias。例如，organizationalPerson這個objectClass就隸屬於person，而person又隸屬於top。
objectClass可分爲以下3類：
結構型（Structural）：如account、inetOrgPerson、person和organizationUnit；
輔助型（Auxiliary）：如extensibeObject；
抽象型（Abstract）：如top，抽象型的objectClass不能直接使用。
每種objectClass有自己的數據結構，比如我們有一種叫“電話薄”的objectClass，肯定會內置很多屬性(attributes)，如姓名(uid)，身份證號(uidNumber)，單位名稱(gid)，家庭地址(homeDirectory)等，這些屬性(attributes)中，有些是必填的，例如，account就要求userid是必填項，而inetOrgPerson則要求cn(common name,常用名稱)和sn(sure name,真實名稱)是必填項。
accout內置的attributes有：userid、description、host、localityName、organizationName、organizationalUnitName、seeAlso；
inetOrgPerson內置的attributes有cn、sn、description、seeAlso、telephoneNumber、userPassword、destinationIndicator、facsimileTelephoneNumber、internationaliSDNNumber、l、ou、physicalDeliveryOfficeName、postOfficeBox、postalAddress、postalCode、preferredDeliveryMethod、registeredAddress、st、street、telephoneNumber、teletexTerminalIdentifier、telexNumber、title、x121Address、audio、usinessCategory、carLicense、departmentNumber、isplayName、employeeNumber、employeeType、givenName、homePhone、homePostalAddress、initials、jpegPhoto、labeledURI、mail、manager、mobile、o、pager、photo、preferredLanguage、roomNumber、secretary、uid、userCertificate等；
由上可見，accout僅僅預置了幾個必要且實用的屬性（完成登陸驗證肯定是夠了），而inetOrgPerson內置了非常之多的屬性，例如電話號碼、手機號碼、街道地址、郵箱號碼，郵箱地址，房間號碼，頭像，經理，僱員號碼等等。
因此，在配置LDAP時，如果僅僅是基於驗證登陸的目的，建議將objectClass類型設置爲accout，而如果希望打造一個大而全的員工信息寶庫，建議將objectClass設置爲inetOrgPerson。
當然，對於一個Entry來說，僅僅有accout或者inetOrgPerson是不夠的，在安裝配置LDAP時，本文介紹了使用migrationtools工具，將Linux系統用戶轉化爲ldif格式的文件，進而導入到LDAP中。在這個過程裏，導出的user，會同時具備accout、posixAccount、shadowAccount、top這4個objectClass，而導出的group，則會同時具備和posixGroup、top兩個objectClass。
上面已經寫出，account的必要屬性是userid，而
posixAccount的必要屬性是cn、gidNumber、homeDirectory、uid、uidNumber；
shadowAccount的必要屬性是uid，可選屬性有shadowExpire、shadowInactive、shadowMax、shadowMin、userPassword等；
top必要屬性是objectClass（可見，top和其它objectClass是繼承的關係）。
========================================
2016.02.03補充：今天在Ubuntu14.04系統上，使用migrationtools工具Linux系統用戶轉化爲ldif格式的文件時，發現導出的user僅僅具備accout、posixAccount、top這3個objectClass（已經最終測試過，可以完成正常登陸功能），而根據Ubuntu官方的OpenLDAP配置guide，建立新增的用戶具備inetOrgPerson、posixAccount、shadowAccount這3個objectClass。看來，在配置OpenLDAP時，需要注意的地方還是很多。