该用户已离职或者未同步在ldap，无法重置密码，如有疑问，请联系管理员

[uuwang]

您使用的版本？

v0.5.17

您使用的场景？

钉钉同步过来后，再同步到ldap

您做了什么操作？

用户密码重置一直报错：该用户已离职或者未同步在ldap，无法重置密码，如有疑问，请联系管理员，同步用户，又是：SyncUser向LDAP同步用户失败：LDAP Result Code 68 "Entry Already Exists"，最终导致系统没法使用。

您遇到了什么问题？

操作数据库，强制设置同步状态：UPDATE users set sync_state=1 WHERE sync_state=2，但是差不多1分钟后，又被系统全部改回来了，最后写了循环脚步，3s，执行一次强制修改用户状态，总算让系统能用了。

您期望的结果是怎样的？

没有日志输出日志，所以不清楚自动设置不同步内部的逻辑是什么，这是不是一个BUG呢？其实用户密码的设置，在企业里是最基本的操作，希望这个能简便，管理员重置用户密码是非常需要的，非常感谢能得到帮助。

[eryajf]

您好 @uuwang👋，我已收到您的反馈，我将安排时间考虑您提交的信息并进行回复。-- 这条信息是由自动回复的机器人发出的。

Hello @uuwang. I have received your feedback, and I will arrange time to consider the information you submitted and reply. -- This message is sent by an automatic reply robot.

[eryajf]

造成这个问题的根本原因应该是不知道什么原因，导致的MySQL与ldap数据不一致，从而会存在同步用户时提示ldap已存在。但重置密码时又失败了。

关于管理员重置用户密码这个功能，已经在规划中了，最近空了我会补充下这个能力

[uuwang]

请教大佬，具体哪里不同步，出现这种情况后还有解决的办法吗？我尝试在ldap把people entry和组的uniqueMember 删掉，同步成功，但是马上状态就会变成2，回到开始这种情况。这个不同步的判断规则是什么呢？

[eryajf]

我先解释一下变成2的原因，程序在运行之后，会自动启动一个数据对齐检测，就是MySQL和ldap数据是否一致，如果该用户在MySQL存在，但在ldap搜不到，就会把状态改为2

[uuwang]

我可以明确，用户在ldap都是有的，再次同步 LDAP Result Code 68 "Entry Already Exists" 报错也能佐证，而且我把ldap里用户及组删除后手工同步完，一会就回变成2，那这个问题是不是出现在用户存在的判断上了吧。

[eryajf]

我可以明确，用户在ldap都是有的，再次同步 LDAP Result Code 68 "Entry Already Exists" 报错也能佐证，而且我把ldap里用户及组删除后手工同步完，一会就回变成2，那这个问题是不是出现在用户存在的判断上了吧。

有一种可能性，是MySQL与ldap存的dn不一致。可以看下你这个状态变成2的用户，在两个地方的dn是否一致

[uuwang]

感谢大佬指点，问题找到了并解决了，原因是数据库的 ou=people 是小写，ldap里的ou=People 是首字母是大写。我做了数据库批量操作： UPDATE users SET user_dn=replace(user_dn, 'people', 'People') 。

[eryajf]

好的，看看配置文件那里是不是也没写对，这里好像是拼接的那里的配置，以免后续还会出现偏差

[uuwang]

配置文件默认 people，一般 ldap 服务器配置的是用是使用 People，各类教程，包括官方文档（https://ubuntu.com/server/docs/install-and-configure-ldap）， ldap 搜索好像是忽略大小写的，这里确实是一个实际使用中会碰到的问题，大佬把关一下。

[eryajf]

恩恩，我理解，不过这里目前来说相当于使用字符串来做的判断，一时半会儿还不太好改：https://github.com/eryajf/go-ldap-admin/blob/f556f0a0ff41f0a35eac541c50047f3cfa6ed063/logic/sqlToLdap_login.go#L172-L186

我想到的是遍历数据库用户，然后逐个查询ldap是否存在，但是这样如果用户多了之后，对ldap的系统不太友好。所以这里就暂时先保持吧。