上次文章最后有说到按照之前的思路来转化组织结构是有坑的，我们现在还只是对接 AD域，ldap 协议的其他产品在细节上还会有些许不同

我们是不能直接粗暴的认为 cn 就是对应标识一个用户， cn 是 common name 的意思，他也可以表示我们理解的用户组

orgnizationalUnit 和 container 也可以是组的意思，但是对于 AD 域来说，在他们上面能够配置的属性有差别

那么对于同步组织结构，我们实际上是可以如何做的呢？不能粗暴的按照之前的方式来实现，我们可以如何实现？

先过滤组织

我们可以在 ldap 服务器中可以看到， cn 也可以是组的意思，cn 下面也可以是 ou

因此单单的通过 dn 是无法分辨出哪个 dn 代表的是组，哪个 dn 代表的是用户的

因此在 ldap 中，我们想要获取我们认为的组织结构，那么就需要有一定的方法

• 先过滤组
• 再过滤用户
• 拼装整个组织结构

过滤组织

我们就可以使用例如这样的过滤条件：（|(objectClass=organizationalUnit)(objectClass=organizationalRole)）

筛选出来的 dn 全部都是我们认为的组，根据之前的逻辑将这个组生成一棵树即可，是一棵多叉树

例如效果可能是这样的，先生成一棵树，树的基本雏形就有了

再过滤用户

过滤用户的时候 可以是这样的

（|(objectClass=Person)(objectClass=user)）

当然，这些过滤用户都是可以自己修改的，只是我们的逻辑是，先过滤组，再过滤用户

我们过滤的用户可能有这些

我们这里要注意，这些用户不是所有都要挂到我们的树上面的，需要检验他们是不是我们期望的组

拼装整个组织结构

拼装之后，结果可能是这样的，新增的节点是对应的用户，蓝色的是我们正确加入组织结构里面的用户

橙色的也是我们通过上述 条件 （|(objectClass=Person)(objectClass=user)） 筛选出来的用户，但是不属于我们之前筛选的组里面的成员

因此，不能把 J 和 K 加入到我们的组织结构中

则最终我们的组织结构是这样的才对

对于编码的实现原理，和上一篇的类似，只是在生成树的时候需要调整一下即可，处理 DN 的时候，处理组的 DN 和 处理 用户的 DN 需要分开过滤，分开处理，最后做拼装

欢迎点赞，关注，收藏

朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力

好了，本次就到这里

技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。

我是阿兵云原生，欢迎点赞关注收藏，下次见~