ldap 对于没有接触过的人而言，想要入门、使用、精通，无疑是有一些难度的，这也是我个人学习历程中的一个体会，因此这个项目在底层设计上，有意针对用户与分组管理进行了简化与固化，本文即是准备把这些设计做一个分享，以便于使用的朋友们在应用本项目的时候，做到心中有数。

首先来说，ldap 的灵活性非常强，也没有所谓适应一切的标准金线，因此我所思考并设计的未必是适合所有人的，但绝对是适用于大部分人的，如果你的确有场景是当下设计无法满足的，可以另外再沟通，或者这个设计你觉得糟糕透了，那请马上关闭这个项目，而不必再耗费你的精力。

接下来进入本项目设计思路的具体分享。

初始数据

要能够接入本平台，首先需要有如下初始数据：

# DC
dc=eryajf,dc=net

# 管理员
cn=admin,dc=eryajf,dc=net

# 用户的组织
ou=people,dc=eryajf,dc=net

# 分组的组织
ou=dingtalkroot,dc=eryajf,dc=net
ou=feishuroot,dc=eryajf,dc=net
ou=wecomroot,dc=eryajf,dc=net

这些数据是项目能够与 ldap 成功交互的基础，如果你的 ldap 部署之后，通过 phpldapadmin 查看的时候，没有这些数据，或者与这些数据不一致，那极大可能会在使用过程中遇到未知问题，我觉得这是没有必要的。

如果你通过项目提供的 docker-compose 方案进行部署，那么 ldap 在启动之后，会自动加载初始化的配置文件 (opens new window)，启动之后看起来应该是这个样子：

• 注意管理员尽可能命名是 admin，如果你非要用 Manager，可能会有问题。

用户的设计

其实也是比较简单的，go-ldap-admin 约定所有的用户全部放在 ou=people,dc=eryajf,dc=net 之下，亦即，叫张三的同学，他的 DN 应该是 uid=zhangsan,ou=people,dc=eryajf,dc=net 。

在这个地方有不少人问为什么用户不用 cn 这个属性来标识呢，即： cn=zhangsan,ou=people,dc=eryajf,dc=net ，关于这个我不做过多的讨论，约定了 uid 就是 uid，并没有太多为什么。

如果你的用户组织没有明确在配置文件 (opens new window)的 user-dn 当中，那么你后续对分组与用户的增删改查都无法顺畅走通，请务必注意这一点。

分组的设计

分组在系统中也可以理解为组织架构，上边初始化的三个是对应的钉钉，飞书，企业微信，如果你完全没有 IM 数据同步到本地的需求，那么可以忽略这三个组织，甚至可以直接删掉，然后创建符合自己公司情况的组织以及分组。

在分组这里，我们预设了两种属性，ou 与 cn，有不少人问起过这两个的区别是什么：

简单一句话讲就是，ou 无法添加人，cn 下可以添加人，使用的建议是，顶级的菜单建议使用 ou，往下的知道里边会有人的可以使用 cn。

分组的应用也非常广泛，其实在某些时候，分组也可以作为一个权限区隔的依据。

最后

有不少同学问到过我，如何支持某某某属性或者方案，其实如上设计已经能够满足你的使用需求，我也着实没有更多精力来满足一些个性化的需求场景了。