基于Confluence或Jira的用户迁移至OpenLDAP用户的方法

跳槽便是脱坑的结束以及入坑的开始,每每入职一家公司以后都会有一大堆的大坑需要你去埋掉,可惜的是,本屌便是喜欢挖坑不埋坑的人,然后的然后便是把自己坑进去了,再聪慧,没有记录,便没有传承,文明不会进步,给自己敲个警钟。

so ... 简述下这个坑的物理属性:

公司有若干内部系统,Confluence、Jira、Jumpserver、Gitlab等等的系统,随着业务的发展以及人员的增加,账号的管理开始麻烦起来,先不说记得这么多的账号密码,每来(跑路)一个新人,都要增加(删除),每天都不用工作了,光是增加,删除账号就够你喝一壶了,于是乎便有了打一个域控的想法,由于出于强迫症的毛病选择了OpenLDAP,不要问我为啥不用微软的AD,我不会告诉你我被微软的反盗版骚扰过,被泄露了个人信息给微软,然后各种勒索,骚扰个人,有法律经验的同学,喜欢折腾的,可以反告微软一把,所以本屌极其鄙视微软这种下流的公司。

然后问题来了:Confluence 、Jira 原本就有用户,而且这两个系统也没有直接可以迁移用户的功能,只是兼容两种用户登录而已,各登各的,所以一下子没有特别好的方法解决:

  • 不能删除用户,然后再新建用户,这两个系统,如果用户在非本空间内存在编辑或者新建文件的类似操作。是无法删除用户的,只能禁用
  • 不能让其他用户换另外的名字注册登录,这样体验不好,搞不好被人骂死
  • 用crowd 只能解决atlassian自身的登录,集成不了其他的应用

于是想到了既然界面上不能改,那我直接改后台数据库,然后发现了一丝希望:

进入数据库,找到一张叫 cwd_user的表,里面包含了所有用户的登录账号以及信息,其中有个字段为directory_id的,光从名字上看已经很耀眼了,就是我们目录服务器的ID号码,里面分别有包括了两组的数字一组为内置的用户目录,也是系统默认的目录ID,第二组即LDAP的ID。

得到了这个数据以后再往下走,查看这两数据对应的含义,搞清楚,哪个对应LDAP,哪个对应内置用户服务。

再次找寻一个表,cwd_directory的表,打开以后,里面大家一看就一目了然了吧,ID 、目录簿的名称都有了,有了这个就可以直接开始修改用户的属性了。

此时屡下思路:

  1. 需要把本地用户转成LDAP用户的前提是LDAP存在这个用户,所以需要在LDAP中建立用户,账号必须是对应的,密码无所谓,统一密码即可
  2. 进入cwd_user表,找到对应用户,其中应该是存在两个一样的用户,一个为系统本身的目录,还有一个是存在于LDAP的用户:
  • 记住LDAP目录ID,然后,删除LDAP的那个用户的整条记录  为什么呢? 因为我们要伪装的是原本系统自带的目录服务器,所以原来编辑的文件或内容都为原先的这个用户ID,这个所有的才做应该是做好数据库关联的,贸然删除是非常危险的操作。
  • 修改directory_id 为LDAP的ID,还有一个需要修改的地方为CREDENTIAL的字段,把它修改为nopass

然后就这么完了,最后系统重启confluence或jira ,如果不重启,配置不一定会生效,看人品,亲测。

原文地址:http://blog.51cto.com/luweiv998/2091736

时间: 2024-10-07 22:17:04

基于Confluence或Jira的用户迁移至OpenLDAP用户的方法的相关文章

Jira 6.3.6使用openldap进行认证——方法二

上一篇中Jira通过openldap进行认证是第一种方式,在这一篇将介绍另外一种方式,两种方式的不同是由于配置中用户组模板配置和Membership Schema Settings的不同决定的,上一篇中用户组模板配置中Group object class使用的属性是postsixGroup,而这一次的配置中在用户组模板配置中Group object class使用的属性是groupOfNames,默认情况下,openldap在安装完成后是没有这一属性的,关于如何扩展该属性,请参考之前的一篇文章:

基于OpenLDAP的Confluence、Jira、Gitlab的用户集成姿势

笔者上一篇已经介绍过如何把Confluence以及Jira用户系统集成到LDAP,这里就不在赘述,于是乎我们再来加点料: 你司有Gitlab.Confluence 以及 Jira 的系统用户参差不齐,这个系统的用户在哪个系统里不存在,各种操蛋(没错这就是现实) 现在代码库Gitlab也需要集成到LDAP 缩小任何的风险的可能,用户无感知 欲把这三个系统的用户登录集成在一起,有三个前提: 列取的用户列表三组:Gitlab用户组.Confluence用户组.Jira用户组(数据库里) 如果用户同时存

Confluence与Jira安装及后期迁移问题记录

Confluence与Jira 由于线上jira和confluence之前互相关联,confluence的登录用户全部关联自jira的用户,confluence安装时会提示是否关联jira,由于这个问题,我们必须先安装jira,后安装confluence. confluence环境: 1.  /Data/apps/atlassian-confluence-5.8.10        #程序文件 2. /Data/apps/atlassian-confluence-5.8.10/bin/start

Confluence 6 给一个从 Jira Service Desk 的非许可证用户访问权限

如果你正在使用 Confluence 为 Jira 服务桌面(Jira Service Desk)的知识库,你可以选择允许所有活动的用户和客户(客户是可以登录的用户,但是这些用户是没有 Confluence 许可证的)来查看特定的空间.这个仅对 Jira Service Desk 有效,请参考 turned on via JIRA Service Desk 页面中的内容. 当空间是能够对所有活动用户开发访问的,你将会在空间的权限页面中看到下面的提示.  这个权限将会覆盖所有已经存在的空间权限,因

confluence与jira账号对接、查看到期时间及问题总结

安装顺序:先安装Jira,然后安装Confluence,在Confluence安装过程中去连接jira,既Confluence用户目录会主动同步jira的用户目录.这样,在jira里创建用户就会自动同步到Confluence里,双方登陆的用户是一样的(最好是先在jira里创建用户,然后同步到Confluence里).在同一个session环境下,可以使用同样的账号登陆jira和Confluence.(但是在切换登陆时仍然需要输入密码,要想切换登陆时不需要登陆密码,即实现单点登录,则需要基于Cro

基于域名虚拟主机及主站迁移

第二章实验(二):基于域名虚拟主机及主站迁移 1.配置BIND支持多域名解析:在实际工作中需要申请多个域名,并做好解析. 登录到192.168.100.100(已经提供了linuxfan.cn的解析) [[email protected] ~]# vim /var/named/chroot/etc/named.conf   ##在该文件末尾添加如下内容 zone "sggfu.com" IN { type master; file "sggfu.com.zone";

liunx系统用户迁移

很多企业在网站发布前,在linux测试机上测试服务,很多程序员用户目录也在linux测试机上测试程序.然而,随着项目的进行,出现了测试机卡死的状况.用df -h命令查看,结果吓一跳,根目录上资源占用竟然达到了100%,不卡死才怪呢,,,而其他磁盘挂载的目录空间几乎没有用!!! 怎么解决呢,首先通知所有用户,让他们删除自己工作目录中的那些没用的文件,效果还是有的,不一会就腾出了差不多6个G的空间...可惜好景不长,没过几天,再次卡死,这次还是来个彻底点的解决办法吧,迁移!!!方案如下: /home

活动目录父子域用户迁移之:TFS&SharePoint问题汇总(一)

前段时间做了个项目,是关于父子域合并的,其实无非就是使用ADMT把域用户,计算机等从子域迁移到父域上,看似迁移用户很简单.But--生产环境啊,Exchange,TFS,Sharepoint,还有其余乱七八糟的东西,都使用了域账号,牵一发动全身的节奏,迁移账号出点儿问题相关用户就可以坐在那打酱油了,迁移前在他们生产环境中新建测试账号迁移,但是这种测试账号相对理想的环境,测试过程中很多问题不容易发现,很多问题是迁移了客户生产用户账号时出现了问题,但是于对于TFS一窍不通,sharepoint大多不

活动目录父子域用户迁移之:TFS&SharePoint问题汇总(二)

接着上一篇文章,继续汇总遇到的问题 四:Sharepoint账户名未自动更新 问题描述: 用户迁移后,账户名称处仍显示原有的登陆名 问题处理: 迁移后,在SharePoint服务器上运行命令: stsadm -o migrateuser -oldlogin olddomain\XXX -newlogin newdomain\xxx –ignoresidhistory 这个问题处理起来还是比较简单的,如果用户比较多,直接批量的脚本进行处理 五:TFS用户账户迁移 关于用户账户的迁移,迁移过去后,在