[Bug]: User cannot authenticate with LDAP backend if multiple LDAP servers are configured

[sakwe]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

After update from 24.0.6 to 24.0.7 : User cannot authenticate with LDAP backend if multiple LDAP servers are configured

It seems that the LDAP authentication proccess continue to check the user login on the next LDAP server even if authentication success. :

• If the user is in the last LDAP server of the list, the authentication is successful
• Authentication for all other LDAP servers fails with : "No user available for the given login name on [host:port]"

Steps to reproduce

1. Having multiple LDAP servers configured for user authentication (user A in server 1, user B in server 2)
2. Update from 24.0.6 to 24.0.7
3. Authentication fails with user A (and all users from server 1) but success with user B (and all users from server 2)
4. Add a copy of server 1 as server 3 in the LDAP server list
5. Authentication fails with user B (and all users from server 2) but success with user A (and all users from server 3 [copy of 1])
6. Desactivate server 3 and user B can authenticate again ... but not user A ...

Expected behavior

Authentication must be successful for users of server #1, #2 or #3

Installation method

No response

Operating system

Debian/Ubuntu

PHP engine version

PHP 7.4

Web server

Apache (supported)

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Updated from a minor version (24.0.6 to 24.0.7)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "cloud.7160.be",
            "webmail.chapelle-lez-herlaimont.be",
            "webmail.7160.be",
        ],
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "debug": false,
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "overwrite.cli.url": "https:\/\/cloud.chapelle-lez-herlaimont.be",
        "forcessl": true,
        "forceSSLforSubdomains": true,
        "dbtype": "mysql",
        "version": "25.0.1.1",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "installed": true,
        "default_language": "fr",
        "ldapIgnoreNamingRules": false,
        "ldapProviderFactory": "\\OCA\\User_LDAP\\LDAPProviderFactory",
        "maintenance": false,
        "loglevel": 0,
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpmode": "smtp",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "465",
        "updater.release.channel": "stable",
        "twofactor_enforced": "false",
        "twofactor_enforced_groups": [],
        "twofactor_enforced_excluded_groups": [],
        "app_install_overwrite": [
            "mail",
            "external",
            "apporder"
        ],
        "mysql.utf8mb4": true,
        "mail_sendmailmode": "smtp",
        "default_phone_region": "BE",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_smtpsecure": "ssl",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "theme": "",
        "updater.secret": "***REMOVED SENSITIVE VALUE***"
    }
}

List of activated Apps

Enabled:
  - activity: 2.17.0
  - admin_audit: 1.15.0
  - appointments: 1.14.0
  - apporder: 0.15.0
  - audioplayer: 3.3.1
  - bookmarks: 11.0.4
  - bruteforcesettings: 2.5.0
  - calendar: 4.1.0
  - cloud_federation_api: 1.8.0
  - comments: 1.15.0
  - contacts: 5.0.1
  - contactsinteraction: 1.6.0
  - dashboard: 7.5.0
  - dav: 1.24.0
  - deck: 1.8.1
  - event_update_notification: 2.0.0
  - external: 5.0.0
  - federatedfilesharing: 1.15.0
  - federation: 1.15.0
  - files: 1.20.1
  - files_downloadactivity: 1.15.0
  - files_external: 1.17.0
  - files_pdfviewer: 2.6.0
  - files_rightclick: 1.4.0
  - files_sharing: 1.17.0
  - files_trashbin: 1.15.0
  - files_versions: 1.18.0
  - firstrunwizard: 2.14.0
  - groupfolders: 13.0.0
  - logreader: 2.10.0
  - lookup_server_connector: 1.13.0
  - nextcloud_announcements: 1.14.0
  - notes: 4.6.0
  - notifications: 2.13.1
  - notify_push: 0.5.0
  - oauth2: 1.13.0
  - password_policy: 1.15.0
  - photos: 2.0.0
  - polls: 4.0.0
  - previewgenerator: 5.1.0
  - privacy: 1.9.0
  - provisioning_api: 1.15.0
  - quota_warning: 1.15.0
  - recommendations: 1.4.0
  - related_resources: 1.0.3
  - richdocuments: 7.0.1
  - serverinfo: 1.15.0
  - settings: 1.7.0
  - sharebymail: 1.15.0
  - spreed: 15.0.1
  - support: 1.8.0
  - survey_client: 1.13.0
  - systemtags: 1.15.0
  - tasks: 0.14.5
  - text: 3.6.0
  - theming: 2.0.1
  - twofactor_backupcodes: 1.14.0
  - updatenotification: 1.15.0
  - user_ldap: 1.15.0
  - user_status: 1.5.0
  - viewer: 1.9.0
  - weather_status: 1.5.0
  - workflowengine: 2.7.0
Disabled:
  - announcementcenter: 6.3.1
  - circles: 0.21.4
  - documentserver_community: 0.1.12
  - encryption
  - extract: 1.3.5
  - files_accesscontrol: 1.14.1
  - impersonate: 1.11.0
  - jitsi: 0.15.0
  - mail: 1.11.6
  - onlyoffice: 7.3.0
  - richdocumentscode: 21.11.103
  - socialsharing_email: 2.5.0
  - socialsharing_facebook: 2.5.0
  - suspicious_login
  - twofactor_totp
  - workflow_script: 1.8.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

No response

Additional info

No response

[michel-nicol]

I run into the exact same bug.
I upgraded to 24.0.7 and then directly to 25.0.1.
Then my server started to act weird.
Asking for the full list of users ends up with an empry list, while selecting users from a specific group shows the users, from the last LDAP server but not from any other LDAP.
Using the CLI, I was getting the full list of users in every cases. So the bug seems to be for the GUI only.
I had to revert to 24.0.6 after two days of hair pulling tests...
Reverting to 24.0.6 corrected the bug instantly.

[sakwe]

I have upgraded from 24.0.7 to 25.0.1 because I ran out of idea ... I confirm the same issue with 25.0.1 too.

[michel-nicol]

While this is far from ideal, I suggest to downgrade to 24.0.6 until this bug has been fixed.
the updater places a backup in data/updater-xxxxxx/backups/nextcloud-xx.x.x.timestamp
If you have a backup of the database, the process is rather straightforward:
stop apache/nginx
restore you DB from the last backup before the upgrade
copy data/updater-xxxxx/backups/nexcloud-24.0.6-yyyyyyy over your nextcloud directory
run occ upgrade (should get you back to 24.0.6)
start apache/nginx

[sakwe]

Thanks a lot for your suggestions and instructions.
I have made a workaround that preserve me to downgrade : I used the capability of OpenLDAP server (slapd-meta) to "merge" mutliple ldap/ad servers and act as a proxy. So I have now only one LDAP server configured in Nextcloud and everybody can login into Nextcloud 25 tomorow morning ;-)

Anyway, this configuration is only a workaround witch use an additional vpn tunel to operate with the other ldap server... Will see this in production ... Cross the fingers !

[apg1980]

suddenly all ldap users have no data inside the webui, on the filesystem all data is available.
issue is, after logon a ldap user no data is there (usage 0 of xxx GB).
we need fixed this soon.
no errors in the log

update i found the reason, user_ldap is not respecting the folder name settings (samaccountname instead of guid) anymore, the path within the ldap users will connect to an guid instead the configured samaccountname.

[Commifreak]

I upgraded to 24.0.7 and LDAP stopped working, because $attrs do not contain displayName anymore and thus I get LDAP Login: Could not get user object for DN myDN. Maybe the LDAP entry has no set display name attribute?

And yes: displayname is not being requested. $attrs =

Array
(
    [0] => entryuuid
    [1] => nsuniqueid
    [2] => objectguid
    [3] => guid
    [4] => ipauniqueid
    [5] => dn
    [6] => uid
    [7] => samaccountname
    [8] => memberof
    [9] => mail
    [10] => cn
    [11] => jpegphoto
    [12] => thumbnailphoto
)

s01ldap_display_name => displayname - nothing changed there and was working before.

EDIT: Multiple domains in use
EDIT2: Even with hardcoded, added displayname as attribute: The value is now there, but the plugin is still not able to get a user. Error remains the same.
EDIT3: A 24.0.7 instance with just one domain do not have any issues.

[Commifreak]

Downgrading JUST the user_ldap app (from 24.0.6 package) fixed the issue for now.

[michel-nicol]

Strangely enough, the user_ldap app version is 1.14.1 in NC 24.0.6 AND in NC 24.0.7 but the code is different... That's why I didn't looked into this component at first... I just looked at the version number, and since it was the exact same, I assumed the code was identical and the bug was elsewhere...

[Commifreak]

There are just a few changes in the app between the two versions but something small affect the functionality :/

[Dennis1993]

I can confirm this issue. I updated from 25.0.0 to 25.0.1 and no user can log in after the upgrade. The log is empty.
PHP 8.1 with MariaDB 10.3