Repository navigation
ldap: remnants from previous ldap configuration are undeletable if ldap uid also exists in new ldap configuration #3365
Description
We are using Nextcloud 10.0.1.
We have two ldap services, servicing the same users but with differents attributes and different DNs.
During the setup of our nextcloud instance, I started by using one of our ldap server, let's call it ldap1. Nextcloud populated the ldap user mapping table with the DNs from ldap1 using the uid's as owncloud usernames.
I noticed this server wouldn't do because it lacked the memberOf overlay I needed to filter users, so I changed the server address for ldap2, base dn from ldap2, etc. without deleting the configuration just by modifying the current configuration from the admin interface. Nextcloud, like previously, populated the ldap user mapping table with the content of ldap2 but this time uuids were generated.
So, now, in the ldap user mapping table users from both ldap servers are stored and since both ldap servers had the same users but with different DN and different owncloud_name/directory_uuid:
+-------------------------------+----------------------+-----------------------+
| ldap_dn | owncloud_name | directory_uuid |
+-------------------------------+-----------------------+----------------------+
| uid=doe-j,o=dn1 | doe-j | doe-j |
| uid=doe-j,o=dn2 | 3da3ab4e-..... | 3da3ab4e-.... |
+-------------------------------+-----------------------+----------------------+
occ ldap:show-remnants actually lists users from ldap1
+------------------------+-------------------------+-----------------+-----------------------+
| ownCloud name | Display Name | LDAP UID | LDAP DN ....
+------------------------+-------------------------+-----------------+-----------------------+
| doe-j | John Doe | doe-j | uid=doe-j,o=dn1 ....
+------------------------+-------------------------+-----------------+-----------------------+
but occ user:delete can't delete them:
The specified user could not be deleted. Please check the logs.
and in the log:
{"reqId":"2GT2OrIJgQugOKf6eohL","remoteAddr":"","app":"user_ldap","message":"User 3da3ab4e-..... is not marked as deleted, not cleaning up.","level":1,"time":"2017-02-03T12:40:32+00:00","method":"--","url":"--","user":"--"}
Notice it got the user wrong?
Indeed, the user:delete command does a ldap lookup of the user's loginname against the current ldap configuration to retrieve the user's ldap dn in order to get the owncloud_name from the ldap user mapping table: so nextcloud looks up doe-j in ldap2 which is the current ldap server and gets uid=doe-j,o=dn2 as a result. From this ldap_dn it gets the wrong owncloud_name which is of course not marqued as deleted in the oc_preferences table.
Activity
[-]ldap: remnants from previous ldap configuration are undeletable if uid exists in existing ldap configuration[/-][+]ldap: remnants from previous ldap configuration are undeletable if ldap username also exists in new ldap configuration[/+][-]ldap: remnants from previous ldap configuration are undeletable if ldap username also exists in new ldap configuration[/-][+]ldap: remnants from previous ldap configuration are undeletable if ldap uid also exists in new ldap configuration[/+]MorrisJobke commentedon May 11, 2017
cc @blizzz @GitHubUser4234
blizzz commentedon May 15, 2017
@ArnY did you try to delete both users? From the output it seems you tried to delete against the UUID, but the user is not marked as deleted, but "doe-j" is.
Not really, we don't know the loginname at this point, but the username as used in Nextcloud (which can be the same as the loginname). This is mapped against a DN in that table, and this should be looked up. Tell me if I oversaw anything :)
ArnY commentedon May 20, 2017
Hello,
The thing is that I don't want to remove both users since the "uuid account" is actually active. The bug i'm trying to point to is that, even though the account i'm trying to delete is listed by ldap:remnants, it's undeletable.
That's the bug, I did try to delete "doe-j" but nextcloud, when processing the deletion tries to looks up the user in the current ldap directory and ends up getting the wrong user:
See what I mean?
blizzz commentedon May 22, 2017
OK, I found where it comes from. In https://github.com/nextcloud/server/blob/master/lib/private/User/Manager.php#L153 it is attempted to see whether there is a loginname matching to a user name and because it works, the LDAP user is returned instead.
blizzz commentedon May 22, 2017
Wait, on the other hand this method is bound to the backend and for database this should work in fact. I try to reproduce it.
Merge pull request #6699 from nextcloud/backport-6522-stable12