# 什么是ldap
LDAP是轻量目录访问协议,英文全称是Lightweight Directory Access Protocol,一般都简称为LDAP。按照我们对文件目录的理解,ldap可以看成一个文件系统,类似目录和文件树。
# ldap的软件
ldap并不是一款软件,而是一个协议。
现在市场上有关LDAP的产品已有很多,各大软件公司都在他们的产品中集成了LDAP服务,如Microsoft的ActiveDirectory、Lotus的Domino Directory、IBM的WebSphere中也集成了LDAP服务。LDAP的开源实现是OpenLDAP,它比商业产品一点也不差,而且源码开放。
OpenLDAP 是最常用的目录服务之一,它是一个由开源社区及志愿者开发和管理的一个开源项目,提供了目录服务的所有功能,包括目录搜索、身份认证、安全通道、过滤器等等。大多数的 Linux 发行版里面都带有 OpenLDAP 的安装包。OpenLDAP 服务默认使用非加密的 TCP/IP 协议来接收服务的请求,并将查询结果传回到客户端。由于大多数目录服务都是用于系统的安全认证部分比如:用户登录和身份验证,所以它也支持使用基于 SSL/TLS 的加密协议来保证数据传送的保密性和完整性。OpenLDAP 是使用 OpenSSL 来实现 SSL/TLS 加密通信的。
# ldap的信息模型
【重要部分】
LDAP的信息模型是建立在"条目"(entries)的基础上。一个条目是一些属性的集合,并且具有一个全局唯一的"可区分名称"DN,一个条目可以通过DN来引用。每一个条目的属性具有一个类型和一个或者多个值。类型通常是容易记忆的名称,比如"cn"是通用名称(common name) ,或者"mail"是电子邮件地址。条目的值的语法取决于属性类型。比如,cn属性可能具有一个值"Babs Jensen" 。一个mail属性可能包含"bbs@kevin.com" 。一个jpegphoto属性可能包含一幅JPEG(二进制)格式的图片。
LDAP的objectClass
LDAP通过属性objectClass来控制哪一个属性必须出现或允许出现在一个条目中,它的值决定了该条目必须遵守的模式 规则。可以理解为关系数据库的表结构。接下来会用到的objectClass有
objectClass | 含义 |
---|---|
olcGlobal | 全局配置文件类型, 主要是cn=config.ldif 的配置项 |
top | 顶层的对象 |
organization | 组织,比如公司名称,顶层的对象 |
organizationalUnit | 重要, 一个目录节点,通常是group,或者部门这样的含义 |
inetOrgPerson | 重要, 我们真正的用户节点类型,person类型, 叶子节点 |
groupOfNames | 重要, 分组的group类型,标记一个group节点 |
olcModuleList | 配置模块的对象 |
LDAP常用关键字列表
ldap的entry是由各种字段构成,可以理解为关系数据库的字段。
关键字 | 英文全称 | 含义 |
---|---|---|
dc | Domain Component | 域名的部分,其格式是将完整的域名分成几部分,如域名为example.com变成dc=example,dc=com |
uid | User Id | 用户ID,如“tom” |
ou | Organization Unit | 组织单位,类似于Linux文件系统中的子目录,它是一个容器对象,组织单位可以包含其他各种对象(包括其他组织单元),如“market” |
cn | Common Name | 公共名称,如“Thomas Johansson” |
sn | Surname | 姓,如“Johansson” |
dn | Distinguished Name | 惟一辨别名,类似于Linux文件系统中的绝对路径,每个对象都有一个惟一的名称,如“uid= tom,ou=market,dc=example,dc=com”,在一个目录树中DN总是惟一的 |
rdn | Relative dn | 相对辨别名,类似于文件系统中的相对路径,它是与目录树结构无关的部分,如“uid=tom”或“cn= Thomas Johansson” |
c | Country | 国家,如“CN”或“US”等。 |
o | Organization | 组织名,如“Example, Inc.” |
这里,我们把dn当做用户唯一主键, cn是common name,应该等同于用户名,因为用户名必须唯一,通常为邮箱前缀 ,比如ryan.miao. sn作为姓氏, uid作为用户id。通常用户id也是唯一的。所以在使用ldap做认证的时候, 大概逻辑如下:
- 配置ldap host, admin, admin pass
- 用户登录时传递username
- 读取配置的ldap信息,查询cn或者uid等于username的数据
- 取出第一个记录, 获得dn, 根据dn和password再次去ldap服务器认证。即我们必须保证cn或uid是全局唯一的, 认证通常需要进行两次。原因就在于dn没办法根据用户名计算出来。
一个ldap用户组织可能是这样的:
# ldap使用docker compose安装
version: "3"
services:
# 1.安装openldap
openldap:
container_name: openldap
image: docker.mirrors.sjtug.sjtu.edu.cn/osixia/openldap:1.4.0
restart: always
environment:
LDAP_ORGANISATION: "9quant openldap"
LDAP_DOMAIN: "9quant.com"
LDAP_ADMIN_PASSWORD: "123456"
LDAP_CONFIG_PASSWORD: "123456"
volumes:
- /data/openldap/data:/var/lib/ldap
- /data/openldap/slapd.d:/etc/ldap/slapd.d
ports:
- '389:389'
# 2.安装phpldapadmin
phpldapadmin:
container_name: phpldapadmin
image: docker.mirrors.sjtug.sjtu.edu.cn/osixia/phpldapadmin:0.9.0
restart: always
environment:
PHPLDAPADMIN_HTTPS: "false"
PHPLDAPADMIN_LDAP_HOSTS: openldap
ports:
- '30004:80'
depends_on:
- openldap