Open kernstock opened 5 months ago
Did you try https://docs.nextcloud.com/server/latest/admin_manual/configuration_user/user_auth_ldap_cleanup.html?
You mean reactivate the LDAP user backend and set ldapUserCleanupInterval
? Actually, I am hesitant doing this because the LDAP backend has a history of making the entire instance completely inaccessible when a malfunctioning configuration is present. I am unsure whether our old directory config is still present somewhere in the database. When the directory disappeared, I had to disable the LDAP backend with occ
only to be able to log in with the admin user (which did not come from the directory server).
To use occ ldap:show-remnants
the user_ldap app must be enabled.
Did you see the part "Deleting local Nextcloud users" that explains how to delete the remnants?
To use
occ ldap:show-remnants
the user_ldap app must be enabled.
Yes, I am aware of that (see above).
Did you see the part "Deleting local Nextcloud users" that explains how to delete the remnants?
Yes, trying to delete a remnant this way gives me "User does not exist":
> occ user:delete 042E7FA3-6B7D-45BD-A764-197079C316C9
User does not exist
To delete a user who belongs to the ldap user backend, the user_ldap app must be enabled.
There are also a couple of occ commands to manage the ldap configuration, just in case that enabling the user_ldap app makes your instance unusable.
@kesselb Thanks. In this case, I will have to announce downtime, try reactivating the user_ldap app (which is currently not possible it seems; "The library ldap is not available"). I will report back.
just in case that enabling the user_ldap app makes your instance unusable.
How is this even a thing? In case you accidentally screwed your LDAP config, or - this may happen as we know - the directory disappears. Why is then nobody able to log in to the instance to eventually disable the user_ldap app? In cases where you have Nextcloud provided by a service provider and have no access to the server's command line, this completely locks everyone out out of everything. And leaves instance admins hanging in the providers service queues.
To delete a user who belongs to the ldap user backend, the user_ldap app must be enabled.
It is not sufficient if user_ldap
is enabled. For me the manual delete with occ user:delete UID
does not work even when the app is enabled:
User does not exist
I had to configure an LDAP server to delete a user. This does not make sense to me but that is the way it is implemented as of now.
cc @nextcloud/ldap
It is expected that the user_ldap
application should be enabled in order to delete its users, we cannot do otherwise if we want the deletion to be clean.
https://docs.nextcloud.com/server/latest/admin_manual/configuration_user/user_auth_ldap_cleanup.html is the correct reference here.
The user_ldap
application is supporting multiple configuration and I expect this is why when there is no configurations at all it misbehaves and say the user does not exist. You may open an issue for that but I see it as low priority as it’s quite a corner case and can be worked around easily.
@come-nc Thanks for your answer. I agree that this is quite an edge case. But how can it be worked around easily? Admins that have remnants from a disappeared directory, will they have to spin up an empty directory for the user_ldap
app to be able to recognize and delete them? This doesn't seem practicable to me.
Hum yeah you’re right, I thought an empty configuration would be enough but user_ldap needs an active configuration to behave correctly. We should make user:delete more robust to empty ldap configuration.
That would mean moving userExists
from User_LDAP
to User_Proxy
directly I’d say, since it does not depend on anything configuration specific, apart from cache currently but caching that globally would be fine.
I do not have time to look more into it for now.
⚠️ This issue respects the following points: ⚠️
Bug description
The directory server of our organization has let's say disappeared. We continued to use the Nextcloud instance but with the built-in user backend.
We now still see account remnants of the disappeared directory in terms of rows in the
oc_accounts
table as well as user directories in the data directory.We also see entries in the log where it says "User 042E7FA3-6B7D-45BD-A764-197079C316C9 still has unscanned files after running background scan, background scan might be stopped prematurely"
I tried
occ user:sync-account-data
but without success. Alsoocc user:list
does not show the remnants.Is there a safe, manual way to get rid of these remnants?
Steps to reproduce
Expected behavior
Users/accounts from the directory should be purged. At least
occ user:sync-account-data
command should notice and purge the accounts.Installation method
Community Manual installation with Archive
Nextcloud Server version
27
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Nginx
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
No response
Additional info
No response