背景
当公司的内部系统越来越多（诸如：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高可用架构部署
待续....