目录
业务需求
最近接了个任务,要同步ldap下的用户信息,组织架构,还要能够域认证,当然这对nodejs是有这个技术的支持的
在网上也确实找到了一个不错的三方模块链接: node-ldap
模块使用补充
搜索部门
组织A : 餐饮有限公司 canying.com
组织B: 汽修有限公司 www.qixiu.com
那么base如何填写呢?
用组织A来说:
canying.com/餐饮有限公司/IT部
ou=IT部,ou=餐饮有限公司,dc=canying,dc=com
ou代表目录,查找IT部目录下的所有子目录(下级部门),假设IT部没有下级不能则返回的数组长度为0
而组织B如何填:
www.qixiu.com/汽修有限公司/修理部
ou=修理部,ou=汽修有限公司,dc=www,dc=qixiu,dc=com
所以我们要找到所有组织架构实则就是类似与查找某个根文件目录下面的所有子目录
平时我们用的方法就是递归查找,后面会补充
搜索部门 ----查找父亲目录(上级部门)的所有子文件夹(下级部门)
client.searchOU('dc=ad,dc=yliyun,dc=com').then(function(ous) {
console.log(ous);
}).catch(function(err) {
console.error(err);
});
我们发现部门的返回值中部门集合里面只有两个字段ldapDn,deptName
这里是可以修改的,怎么做呢?
首先我们先找到node_modules/node-ldap/lib/ldap.js中,
我用的vscode下载了插件,所以我按下ctrl+鼠标左键点击跳转到client.searchOU
在client.searchOU我们可以看到实际返回值来自_parseOU
同样的我们找到它,
很明显我们
function _parseOU(entry) {
var ou = {
ldapDn: entry.dn,
deptName: entry.displayName
};
if (!ou.deptName) {
ou.deptName = entry.name;
}
if (!ou.deptName) {
ou.deptName = entry.ou;
}
return ou;
}
修改为
function _parseOU(entry) {
var ou = {
ldapDn: entry.dn,
deptName: entry.displayName,
...entry
};
if (!ou.deptName) {
ou.deptName = entry.name;
}
if (!ou.deptName) {
ou.deptName = entry.ou;
}
return ou;
}
就可以看到部门的全部信息了
搜索用户
搜索用户—查找当前部门(目录下)的所有员工
类似与查找当前目录下的文件,不包括文件夹
client.searchUser('ou=IT部,ou=餐饮有限公司,dc=canying,dc=com').then(function(users) {
console.log(users);
}).catch(function(err) {
console.error(err);
});
用户集合中也是只有四个字段,如何显示用户更多信息如上面一样修改_parseUser
function _parseUser(entry) {
var user = {
//dn: entry.dn,
ldapDn: entry.userPrincipalName,
userName: entry.sAMAccountName,
realName: entry.displayName,
mail: entry.userPrincipalName,
//...entry
};
if (!user.realName) {
user.realName = entry.name;
}
if (!user.realName) {
user.realName = entry.cn;
}
return user;
}
同步组织架构遇到的思考
我们ldap同步过来的组织架构可能有几种变化
增删改
如果我们在客户端这边已经同步过来的组织架构已经被绑定了资源,
这时候服务端的组织架构再次变动,会有什么影响呢?
①服务端的部门被删除了
拆分查询部门列表 LIMIT 0,3,然后用for循环
举个例子: 服务端这边IT部被删除了,客户端这边IT部下面已经绑定了资源,这个时候同步,客户端的IT部被逻辑删除,那么该部门下面的资源就不在新的组织架构里面了
答:
所以我觉得应当做好与部门绑定的所有资源管理,如果部门被逻辑删除,应当把相关资源管控起来,开放接口后续转移,类似于转移档案一样。
②服务端部门被删除又创建回来
底层而言这虽然名字一样,但是他们底层的objectId是不一样了,从底层看他们就算都叫IT部,他们也是两个部门
执行同步时,依旧会逻辑删除原有的IT部,重新创建一个IT部,此IT部非彼IT部,那旧IT部资源去哪了
很多人说抓名字,都叫IT部的部门 ,旧的资源应该转移到新的IT部,哥哥呀,够呛。名字长短不好把控,而且错别字怎么办呢,漏打少打也有可能。模糊比对吗?那更加糟糕,旧部门制造部,新部门叫制造研发部,制造维护部,你说他们资源给谁。所以在同步过程中将资源转移也不太行呀
答:还是一样,跟问题①一样,将资源管控起来方便转移
③服务端部门改名,改上级部门
没变化,就底层而言ObjectID还是一样,所以资源不会漂浮
④无归属的部门资源能不能被删除?
尽量不开,如果非要开最好加个回收站,删除的无归属资源可以被放入回收站,这个时候给回收站设置个时间,
当天时间一个月(可以自己定义规则)之前的资源真的将其移除,当然可以的话这些定时程序最好夜间操作 。
同步用户列表遇到的思考
①服务端用户被删除了
查询用户列表同样使用拆分查询,LIMIT 0,3;
服务端用户被删除了,客户端的用户被逻辑删除,资源依旧在其名下
②服务端用户修改名字
因为用户的objectId没变依旧是那个用户
③服务端用户被删除了又创建
这里面因为ObjectId不一样了,会产生新的用户,旧用户的资源一直保留,
考虑到一些信息的唯一性,如电话,邮箱,产生的代码,逻辑限定,这里可以考虑一下用户合并或者转移
获取所有部门列表
1.部门集合信息