Repository navigation
ldap: remnants from previous ldap configuration are undeletable if ldap uid also exists in new ldap configuration #3365
Description
Activity
- changed the title
[-]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[/+]on Feb 3, 2017 - changed the title
[-]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[/+]on Feb 3, 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.
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.
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 :)
Hello,
did you try to delete both users?
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.
From the output it seems you tried to delete against the UUID, but the user is not marked as deleted, but "doe-j" is.
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:
# sudo -u www-data php /var/www/nextcloud/occ ldap:show-remnants | grep doe-j | doe-j | John Doe | doe-j | uid=doe-j,ou=.... | 21 novembre 2016 | /var/www/ceph-data/doe-j | N |# sudo -u www-data php /var/www/nextcloud/occ user:delete doe-j The specified user could not be deleted. Please check the logs. # tail -n1 -f ../ceph-data/nextcloud.log {"reqId":"lumiAF5ZoIGi5ByjlN0V","remoteAddr":"","app":"user_ldap","message":"User 3db05af6-2c94-1028-8677-cbf3daf58c2c is not marked as deleted, not cleaning up.","level":1,"time":"2017-05-20T15:56:33+00:00","method":"--","url":"--","user":"--","version":"11.0.1.2"}See what I mean?
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.
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.
- added a commit that references this issue
on Nov 7, 2017
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:
occ ldap:show-remnants actually lists users from ldap1
but occ user:delete can't delete them:
and in the log:
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.