Unable to delete LDAP remnants

Yomark1 commented 6 years ago

We are running OwnCloud/Nextcloud for a long time now, and at the moment we have about 100 old employees that are deleted from LDAP but are still referenced in Nextcloud. We are running Nextcloud 13.04 now, but this issue is there for a long time. I believe this is a bug. At least for our particular LDAP configuration.

Steps to reproduce

Run "sudo -u www-data php occ ldap:show-remnants"
Delete a user from the above list with : sudo -u www-data php occ user:delete uid Note: both "NextCloud name" and " LDAP UID" are samAccountName(LDAP) in our case . Not sure if this is standard.
Error "User does not exist" is shown. However, it is still listed in "occ ldap:show-remnants" and in the oc_ldap_user_mapping mysql table(and possibly others).

Expected behaviour

User and data should be deleted like in the manual(https://docs.nextcloud.com/server/13/admin_manual/configuration_user/user_auth_ldap_cleanup.html) suggests.

Actual behaviour

Nothing changed. Data folder is still there. User is still shown in show-remnants, and occasionally shown in the nextcloud log files.

Server configuration

Operating system: Ubuntu 16.04.4 LTS

Web server: Apache/2.4.18 (Ubuntu)

Database: mysqld 10.0.34-MariaDB-0ubuntu0.16.04.1

PHP version: PHP 7.0.30-0ubuntu0.16.04.1

Nextcloud version: (see Nextcloud admin page) 13.04

Updated from an older Nextcloud/ownCloud or fresh install: Yes, from Owncloud 7 or 8 to the current nextcloud applying most minor releases an all mayor releases.

Where did you install Nextcloud from: Online download.

No failed integrity files.

List of activated apps:

App list

``` sudo -u www-data php occ app:list root@srvowncloud:/var/www/html# sudo -u www-data php occ app:list Enabled: - activity: 2.6.1 - admin_audit: 1.3.0 - announcementcenter: 3.2.1 - bruteforcesettings: 1.0.3 - comments: 1.3.0 - dav: 1.4.7 - federatedfilesharing: 1.3.1 - federation: 1.3.0 - files: 1.8.0 - files_downloadactivity: 1.2.0 - files_external: 1.4.1 - files_pdfviewer: 1.2.1 - files_sharing: 1.5.0 - files_texteditor: 2.5.1 - files_trashbin: 1.3.0 - files_versions: 1.6.0 - files_videoplayer: 1.2.0 - gallery: 18.0.0 - logreader: 2.0.0 - lookup_server_connector: 1.1.0 - nextcloud_announcements: 1.2.0 - notifications: 2.1.2 - oauth2: 1.1.1 - password_policy: 1.3.0 - provisioning_api: 1.3.0 - richdocuments: 2.0.9 - serverinfo: 1.3.0 - sharebymail: 1.3.0 - systemtags: 1.3.0 - theming: 1.4.5 - twofactor_backupcodes: 1.2.3 - twofactor_totp: 1.4.1 - updatenotification: 1.3.0 - user_ldap: 1.3.1 - workflowengine: 1.3.0 Disabled: - encryption - firstrunwizard - survey_client - user_external root@srvowncloud:/var/www/html# ```

Nextcloud configuration:

Config report

``` If you have access to your command line run e.g.: root@srvowncloud:/var/www/html# sudo -u www-data php occ config:list system { "system": { "instanceid": "***REMOVED SENSITIVE VALUE***", "passwordsalt": "***REMOVED SENSITIVE VALUE***", "trusted_domains": [ "ocloud.blabla.nl", "srvowncloud.dommel.local", "srvowncloud", "10.1.0.134" ], "datadirectory": "***REMOVED SENSITIVE VALUE***", "dbtype": "mysql", "version": "13.0.4.0", "dbname": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbtableprefix": "oc_", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "installed": true, "preview_libreoffice_path": "\/usr\/bin\/libreoffice", "preview_office_cl_parameters": " --headless --invisible", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_smtpmode": "smtp", "mail_domain": "***REMOVED SENSITIVE VALUE***", "trashbin_retention_obligation": "14, 30", "log_rotate_size": 104857600, "log_authfailip": true, "singleuser": false, "maintenance": false, "forcessl": false, "secret": "***REMOVED SENSITIVE VALUE***", "appcodechecker": false, "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "25", "overwritehost": "ocloud.blabla.nl", "overwriteprotocol": "https", "loglevel": 2, "updater.release.channel": "production", "memcache.local": "\\OC\\Memcache\\Memcached", "filelocking.enabled": "true", "memcache.distributed": "\\OC\\Memcache\\Redis", "memcache.locking": "\\OC\\Memcache\\Redis", "redis": { "host": "***REMOVED SENSITIVE VALUE***", "port": 6379, "timeout": 0, "dbindex": 0, "password": "***REMOVED SENSITIVE VALUE***" }, "ldapProviderFactory": "\\OCA\\User_LDAP\\LDAPProviderFactory", "activity_expire_days": 365, "skeletondirectory": "\/var\/www\/html\/data\/skeleton", "lost_password_link": "https:\/\/ocloud.blabla.nl\/passwordreset.html", "overwrite.cli.url": "https:\/\/ocloud.blabla.nl", "auth.bruteforce.protection.enabled": false } } root@srvowncloud:/var/www/html# ```

Are you using external storage, if yes which one: local/smb/sftp/... Yes, some SMB shares.

Are you using encryption: no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/... LDAP

LDAP configuration (delete this part if not used)

LDAP config

Client configuration

Browser: not relevant

Operating system:

Edit: Typo's

MorrisJobke commented 6 years ago

cc @nextcloud/ldap

blizzz commented 6 years ago

@Yomark1 it is not standard, but should not play a role. You use what happens on a sudo -u www-data php occ ldap:check-user $UID With the delete command, you used exactly the same value as it was reported in the "Nextcloud name" column?

smuns commented 6 years ago

Stumbled upon the same issue.

sudo -u www-data php occ ldap:check-user $UID should result in "The user does not exists on LDAP anymore."

Additional info: User can be deleted, if LDAP-Mapping is cleared (LDAP DN empty in show-remnants)

blizzz commented 6 years ago

@smuns clearing LDAP Mappings on a production env is a great idea. Not.

smuns commented 6 years ago

@blizz For sure, i did not claim this to be a workaround or anything more than just "additional info" from debugging the same issue on dev system. Also it includes the answer to your question to Yomark1 btw.

blizzz commented 6 years ago

@smuns sorry, I don't spot the answer?

smuns commented 6 years ago

"sudo -u www-data php occ ldap:check-user $UID" results in "The user does not exists on LDAP anymore." $UID was the value of "Nextcloud name"-column.

Yomark1 commented 6 years ago

@blizz : yes, I use the exact output. Thanks everyone for looking into this(and confirming the issue).

rtheys commented 5 years ago

We are experiencing the same issue. In our case we do a check-user to trigger the check. Afterwards the account shows up in the show-remnant output.

If we immediately do the user:delete it will show "No user found".

If we then wait a while (10+ minutes) and rerun the user:delete command, it will successfully delete the user.

It seems there's a cache somewhere that is not cleared yet when we initially run the command.

blizzz commented 5 years ago

If we then wait a while (10+ minutes) and rerun the user:delete command, it will successfully delete the user.

It seems there's a cache somewhere that is not cleared yet when we initially run the command.

Yupp, it's a cache thing. And, if I remember correctly since I looked into, not straight forward solvable because there are different paths involved (resp. the required cache instance unvailable from that layer).

scroom commented 5 years ago

We experienced this on 15.0.7 and then produced other problems like this: https://github.com/nextcloud/server/issues/11551

szaimen commented 3 years ago

I'm closing this issue due to inactivity. If this is still happening please make sure to upgrade to the latest version. After that, feel free to reopen.

nextcloud / server