上次文章最后有说到按照之前的思路来转化组织结

上次文章最后有说到按照之前的思路来转化组织结构是有坑的，我们现在还只是对接 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 需要分开过滤，分开处理，最后做拼装

欢迎点赞，关注，收藏

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

好了，本次就到这里

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

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