Cant login with local user after LDAP config change


I’m trying to setup LDAP authentication but find if the LDAP config becomes unusable, or the LDAP server becomes unavailable you cannot login even with your local user.

On a fresh install of 19 with LDAP user and group backend, while configuring LDAP on the users tab, “only these object classes” - “inetorgperson” was selected with a working configuration. When I deselected it, the configuration still said ok, but moving to another section resulted in page errors and trying to login in again was impossible, even with a local account.

On another working install (with inetorgperson still selected) I stopped slapd and found again that all users, including local ones were unavailable.

using http:// gets a forgot password result, and https:// gives an internal server error.

Is this usual behaviour? How do you resolve once locked out?

Ok, in the terminal navigated to the nextcloud directory and used occ to identify the LDAP config # and delete;
(using Ubuntu 20.04)
sudo -u www-data php occ ldap:show-config
sudo -u www-data php occ ldap:delete-config s01
Where s01 is the config number.
I could then log in as local user again and set up LDAP again.

Surely the local user being unavailable when LDAP is unavailable is a bug?

1 Like

@clivey_za - you’re a steely-eyed missile man.

I had this same problem with CentOS 8.2, and basically did exactly as you did (once I was cd’d into my nextcloud/ directory):

sudo -u apache php occ ldap:show-config
sudo -u apache php occ ldap:delete-config s01

Same problem here.
If ldap becomes unavailable, local users can not login anymore.
This is a serious problem, because the system becomes unusable.
Deleting the ldap config over cli can’t be a serious solution.
Nextcloud 20.8
Windows 2012 R2 AD ldap

Still an issue with, I can’t access the WebGUI (of a docker instance) with the locally created admin account (using the docker environment variable) in a testing environment where the production LDAP is not available.

EDIT: found a solution - though it still needs CLI access:
Find the name of your active configuration with

occ ldap:show-config 


| Configuration                     | s01           |
| hasMemberOfFilterSupport        | 0             |
| homeFolderNamingRule             |               |

The name is in the second column of the header row that says “Configuration”. By default new configs seem to be called “s01” as seen above, though mine was a legacy config, its name was just empty (use "" later on). With config “s01”, call:

occ ldap:set-config "s01" "ldapConfigurationActive" "0"

This deactivates but doesn’t delete the config, it just unticks the “Activated” box in the WebGUI. You can now log in with your local admin account, and edit it in the WebGUI to fix it.

1 Like

Super helpful, thank you!