背景
當公司的內部系統越來越多（諸如：GitLab、Jenkins、Zabbix、YApi ）時，就有可能出現如下情況：
各個系統之間是不是都有獨立的賬戶密碼？
若多個系統，使用用戶名或密碼不一樣，是不是有時想不來這個賬戶或密碼對應哪個系統？
每次引入內部系統，都需要重新維護一套用戶密碼？
維護多套系統的用戶名及密碼是不是非常繁瑣？
那有沒有一套系統能解決上述這樣的問題？答案肯定是：有的；有一個叫“LDAP統一認證服務”即爲上述的情況解決此類問題的。
使用LDAP集成多個系統，只需在LDAP中新增用戶及密碼，則就可以用此一個賬戶登陸Gitlab及Jenkins等其他系統，見下圖：
在瞭解LDAP之前，先了解何爲目錄服務？
目錄服務
1.目錄服務將有關現實世界中的事物（如人、計算機、打印機等等）的信息存儲爲具有描述性屬性的對象
2.目錄服務是一個特殊的數據庫，用來存儲描述性的詳細信息。
3.目錄服務與傳統的數據庫相比，不支持事務、回滾；但它擁有快速查詢或搜索性能，寫入性能較差。
LDAP
LDAP是輕量目錄訪問協議，英文全稱是Lightweight Directory Access Protocol，一般都簡稱爲LDAP。
LDAP 具有兩個標準，分別是 X.500 和 LDAP。OpenLDAP 是基於 X.500 標準的，而且去除了 X.500 複雜的功能並且可以根據自我需求定製額外擴展功能，但與 X.500 也有不同之處，例如 OpenLDAP 支持 TCP/IP 協議等，目前 TCP/IP 是 Internet 上訪問互聯網的協議。
其官方文檔：http://www.openldap.org/doc/admin24/
LDAP的功能
實現賬戶統一集中管理
權限控制管理
主機控制管理
密碼控制管理
同步機制
....
LDAP的架構
LDAP的系統架構爲服務器/客戶端（C/S）模式，其工作模型如下：
ps：Berkeley DB爲簡稱BDB（Berkeley DB是一個開源的文件數據庫，介於關係數據庫與內存數據庫之間，使用方式與內存數據庫類似，它提供的是一系列直接訪問數據庫的函數，而不是像關係數據庫那樣需要網絡通訊、SQL解析等步驟），最初有Sleepycat公司開發，2006年被Oracle公司收購。
LDAP的基本模型
LDAP的基本模型是建立在"條目"（Entry）的基礎上。一個條目是一個或多個屬性的集合，並且具有一個全局唯一的"可區分名稱"（用dn表示）。與關係型數據進行類比，一個條目相當於數據庫中的一條記錄，而dn相當於數據庫中記錄的關鍵字，屬性相當於數據庫中的字段。
然而這些信息，在LDAP中是如何被存儲的呢？
在LDAP中，這些目錄條目是按照層次樹狀結構排列的。如下圖
在上圖所示的樹形結構中，樹的根結點是一個組織的域名（dlw.com），其下分爲3個部分，分別是managers、people和group，可將這3個組看作組織中的3個部門：如managers用來管理所有管理人員，people用來管理登錄系統的用戶，group用來管理系統中的用戶組。當然，在該圖中還可繼續增加其他分支。
對於圖中所示的樹形結構，使用關係數據庫來保存數據的話，需要設置多個表，一層一層分別保存，當需要查找某個信息時，再逐層進行查詢，最終得到結果。
若使用目錄來保存該圖中的數據，則更直觀。圖中每個結點用一個條目來保存，不同類型的結點需要保存的數據可能不同，在LDAP中通過一個稱爲objectClass的類型來控制不同結點需要的數據（稱爲屬性）。
LDAP如何訪問目錄中的條目？
上面提到過，每一個條目都有一個dn，因爲dn是唯一的，因此就可找到需要結點的數據。dn的構造方式如下：
首先得到條目自己的名稱（rdn，稱爲相對dn），然後開始向上逐級查找父結點，一直到根項爲止。
例如，對於上圖中最右下方的結點，其dn爲：
dn: cn=ldap, ou=group, o=dlw.com
LDAP中的Schema
對於LDAP目錄中保存的信息，可以使用LDIF（LDAP Interchange Format）格式來保存。
這是一種標準文本文件格式，使用這種格式保存得的LDAP服務器數據庫中的數據可方便讀取和修改，這也是其他大多數服務配置文件所採取的格式。
在LDAP中，schema用來指定一個目錄中所包含的對象（objects）的類型（objectClass），以及每一個類型（objectClass）中必須提供的屬性（Atrribute）和可選的屬性。可將schema理解爲面向對象程序設計中的類，通過類定義一個具體的對象。LDIF中的數據條目可理解爲是一個具體的對象，是通過schema來規劃創建的。因此，schema是一個數據模型，用來決定數據按什麼方式存儲，並定義存儲在不同的條目（Entry）下的數據之間的關係。schema需要在主配置文件slapd.conf中指定，以用來決定在目錄中可以使用哪些objectClass。
LDAP中常見的屬性
LDAP中聲明瞭許多常用的屬性（用戶也可以自定義屬性），常見的屬性清單如下：
givenName | 指一個人的名字，不能用來指姓 |
sn(surname) | 一個人的姓 |
dn (distinguished name) | 唯一標識名，類似於Linux文件系統中的絕對路徑，每個對象都有唯一標識名。 例如，uid=dpgdy，ou=People，dc=gdy，dc=com |
rdn (relative dn) | 通常指相對標識名，類似於Linux文件系統中的相對路徑。 例如，uid=dpgdy |
uid（user id） | 通常指一個用戶的登錄名稱。 例如，uid=dpgdy，與系統中的uid不是一個概念 |
sn（sur name） | 通常指一個人的姓氏。例如，sn：Guo |
I | 通常指一個地方的地名。例如，I：Shanghai |
objectClass | objectClass是特殊的屬性，包含數據存儲的方式以及相關屬性信息 |
dc (domain component) | 通常指定一個域名。例如，dc=example，dc=com |
o (organization Name) | 通常指定一個組織的名字 |
ou (organization unit) | 通常指定一個組織單元的名稱。 例如，ou=people，dc=example，dc=com |
cn（common name） | 通常指一個對象的名稱，如果是人，需要使用全名 |
通常指登錄賬號的郵箱地址，例如，mail：[email protected] | |
telephoneNumber | 通常指登錄賬號的手機號碼，例如，telephoneNumber：xxxxxxxxxxx |
c（country） | 通常指一個二位國家的名稱，例如CN、US等國家代號。例如，c：CN |
LDAP及phpLDAPAdmin部署
請參閱《LDAP及phpLDAPAdmin部署》
LDAP高可用架構
OpenLDAP同步複製(簡稱syncrepl)機制是消費方的一個複製引擎，能讓消費者服務器維護一個抽取片段的影子副本。
OpenLDAP常用的高可用架構：
syncrepl模式
syncrepl模式是指從(slave)服務器到主(master)服務器以拉的模式同步目錄樹。當主服務器對某個條目或更多條目修改條目屬性時, 從服務器會把修改的整個條目進行同步, 而不是單獨地同步修改的屬性值。
N-Way Multi-Master模式
N-Way Multi-Master主要用於多臺主服務器之間進行LDAP目錄樹信息的同步, 更好的提供了服務器的冗餘性。
MirrorMode模式
MirrorMode屬於鏡像同步模式, 而且主服務器互相以推的方式實現目錄樹條目同步, 最多隻允許且兩臺機器爲主服務器。如果要添加更多的節點, 此時只能增加多臺從服務器, 而不能將添加的節點配置爲主服務器。
當一臺服務器出現故障時, 另一臺服務器立即對外提供驗證服務。當異常服務器恢復正常時, 會自動通過另一個節點所添加或修改的條目信息進行同步, 並應用在本地。
syncrepl Proxy模式
syncrepl Proxy同步模式屬於代理同步, 它將主服務器隱藏起來, 而代理主機上邊通過syncrepl從主服務器上以拉的方式同步目錄樹數據, 當代理主機數據發生改變時, 代理服務器又以推的方式將數據更新到下屬的從LDAP服務器上, 且從LDAP服務器只有對代理LDAP服務器有讀權限。
Delta-syncrepl模式
在Delta-syncrepl同步模式下, 當主服務器對目錄樹上的相關條目進行修改時, 會產生一條日誌信息, 於是這時候, 從服務器會通過複製協議, 將主服務器記錄的日誌應用到從服務器本地, 完成數據同步的過程。但每個消費者獲取和處理完全改變的對象, 都執行同步操作。
LDAP高可用架構部署
待續....