上次文章最后有说到按照之前的思路来转化组织结构是有坑的，我们现在还只是对接 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 需要分开过滤，分开处理，最后做拼装
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
