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

sakwe · 2022-11-06T16:08:07Z

⚠️ 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

Having multiple LDAP servers configured for user authentication (user A in server 1, user B in server 2)
Update from 24.0.6 to 24.0.7
Authentication fails with user A (and all users from server 1) but success with user B (and all users from server 2)
Add a copy of server 1 as server 3 in the LDAP server list
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])
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 · 2022-11-06T18:17:22Z

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 · 2022-11-06T18:35:18Z

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 · 2022-11-06T19:07:10Z

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 · 2022-11-06T19:31:23Z

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 · 2022-11-07T06:42:30Z

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 · 2022-11-07T08:32:29Z

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 · 2022-11-07T09:01:33Z

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

michel-nicol · 2022-11-07T12:28:34Z

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 · 2022-11-07T12:30:58Z

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

Dennis1993 · 2022-11-07T21:00:55Z

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

solracsf · 2022-11-08T07:46:31Z

There are 2 PR that affect LDAP on new versions:
#34730
#34795

Maybe on of them is the faulty one?

florian-obradovic · 2022-11-08T10:06:30Z

Same here 24.0.6 > 24.0.7 and having two LDAP servers in the list.

Running "sudo -u www-data php occ ldap:check-user [email protected]" multiple times gives me alternately outputs:
"The user is still available on LDAP" and then "The user does not exists on LDAP anymore"

Downgrading user_ldap app to 24.0.6 version works:

sudo rm -rf /var/www/nextcloud/apps/user_ldap
sudo cp -rfvp /var/ncdata/updater-YOURINSTANCEID/backups/nextcloud-24.0.6.1-1667847965/apps/user_ldap /var/www/nextcloud/apps/user_ldap

Also check-user --update throws an exception every second execution

sudo -u www-data php occ ldap:check-user [email protected]
The user is still available on LDAP.
An unhandled exception has been thrown:
Error: Call to a member function getDN() on null in /var/www/nextcloud/apps/user_ldap/lib/Command/CheckUser.php:147
Stack trace:
#0 /var/www/nextcloud/apps/user_ldap/lib/Command/CheckUser.php(99): OCA\User_LDAP\Command\CheckUser->updateUser()
#1 /var/www/nextcloud/3rdparty/symfony/console/Command/Command.php(255): OCA\User_LDAP\Command\CheckUser->execute()
#2 /var/www/nextcloud/3rdparty/symfony/console/Application.php(1009): Symfony\Component\Console\Command\Command->run()
#3 /var/www/nextcloud/3rdparty/symfony/console/Application.php(273): Symfony\Component\Console\Application->doRunCommand()
#4 /var/www/nextcloud/3rdparty/symfony/console/Application.php(149): Symfony\Component\Console\Application->doRun()
#5 /var/www/nextcloud/lib/private/Console/Application.php(211): Symfony\Component\Console\Application->run()
#6 /var/www/nextcloud/console.php(100): OC\Console\Application->run()
#7 /var/www/nextcloud/occ(11): require_once('...')

michel-nicol · 2022-11-08T20:56:11Z

The bug seems to be in Proxy.php. I managed to correct the bug by altering Proxy.php with the following modifications:

40a41
> use OCP\Share\IManager;
71a73,85
>                 static $fs;
>                 static $coreNotificationManager;
>                 static $avatarM;
>                 static $shareManager;
>                 $avatarM = \OC::$server->getAvatarManager();
>
>
>                if ($fs === null) {
>                        $fs = new FilesystemHelper();
>                        $coreNotificationManager = \OC::$server->getNotificationManager();
>                        $shareManager = \OC::$server->get(IManager::class);
>                }
>
>               $userManager =
>                     new Manager($ocConfig, $fs, $logger, $avatarM, new \OCP\Image(),
>                             $coreUserManager, $coreNotificationManager, $shareManager);
73d86
<               $userManager = \OC::$server->get(Manager::class);

So, the issue is with the instantiation of $userManager using the Manager class... I must say I cannot elaborate further... I'm not really used to code in php. Someone else will probably find the root cause...

EDIT: my patch was missing some variables declaration. As I said I'm not used to code in PHP

szaimen · 2022-11-08T21:05:07Z

cc @come-nc @blizzz

pngn-pro · 2022-11-09T09:21:22Z

After updating to 24.0.7, this problem appeared. Two domains are used for authorization. Left one domain - authorization has earned!
For me, this is the way out, since there are a couple of users in the second domain.

michel-nicol · 2022-11-09T09:35:26Z

If anyone needs the patched version of Proxy.php (to be placed in your nextcloud directory under apps/user_ldap/lib/ ) here is a link to the version I'm using which corrects this bug.
Please take note that I did not do extended tests, yet it restores the ability to log in from (at least) two ldap directories. So I'm providing it "as is".

EDIT: I'll remove this file as soon as an official patch has been released...

EDIT 2: Official patch is available so I removed the link.

come-nc · 2022-11-10T09:09:55Z

@michel-nicol Thanks a lot for finding the source of that!

Most likely the fix for 24 will look like what you did and we’ll try to do something prettier for 25 and master.

What we missed here is that OCA\User_LDAP\User\Manager refers the Access class which differs for each LDAP connection and thus cannot be a singleton.

blizzz · 2022-11-10T09:39:21Z

@michel-nicol can you confirm #35070 fixes the issue as well?

mnicol53 · 2022-11-11T13:47:18Z

@michel-nicol can you confirm #35070 fixes the issue as well?

I will as soon as I can.

michel-nicol · 2022-11-13T22:08:08Z

Yes the proposed patch #35070 works.

aknauss · 2023-03-28T13:16:46Z

Hi,
It seems that Nexcloud 26 had same issue...

szaimen · 2023-03-28T14:55:00Z

Hi, this must be a different bug as the issue was fixed by #35070. Please create a new bug report with up-to-date information. Thanks!

Quax1507 · 2023-04-06T10:57:29Z

If anyone needs the patched version of Proxy.php (to be placed in your nextcloud directory under apps/user_ldap/lib/ ) here is a link to the version I'm using which corrects this bug. Please take note that I did not do extended tests, yet it restores the ability to log in from (at least) two ldap directories. So I'm providing it "as is".

EDIT: I'll remove this file as soon as an official patch has been released...

EDIT 2: Official patch is available so I removed the link.

Is there any workararound or fix for Nextcloud 26?

florian-obradovic · 2023-05-24T13:49:17Z

Fix with the current commit: #35070

Backup

cd /var/www/nextcloud/apps

cp -rfv user_ldap ~/user_ldap-BACKUP

cd /var/www/nextcloud/apps/user_ldap/lib

sudo rm AccessFactory.php

sudo wget https://raw.githubusercontent.com/nextcloud/server/967955358c2693aafb1e43795b09cf24e460929b/apps/user_ldap/lib/AccessFactory.php

sudo rm Sync.php

sudo wget https://raw.githubusercontent.com/nextcloud/server/967955358c2693aafb1e43795b09cf24e460929b/apps/user_ldap/lib/Jobs/Sync.php

sudo wget https://raw.githubusercontent.com/nextcloud/server/967955358c2693aafb1e43795b09cf24e460929b/apps/user_ldap/tests/Jobs/SyncTest.php

sakwe added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug labels Nov 6, 2022

szaimen added 24-feedback 25-feedback labels Nov 7, 2022

solracsf added the feature: ldap label Nov 8, 2022

PVince81 assigned come-nc Nov 9, 2022

PVince81 added this to the Nextcloud 24.0.8 milestone Nov 9, 2022

blizzz mentioned this issue Nov 10, 2022

[LDAP] always create instance of own user manager #35070

Merged

szaimen mentioned this issue Nov 10, 2022

[Bug]: Multiple LDAP servers don't work properly #35072

Closed

9 tasks

szaimen closed this as completed in #35070 Nov 13, 2022

Dennis1993 reopened this Mar 28, 2023

szaimen closed this as completed Mar 28, 2023

bulli007 mentioned this issue Apr 13, 2023

[Bug]: Multiple Ldap doesn't working #37454

Closed

9 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

sakwe commented Nov 6, 2022 •

edited

Loading

michel-nicol commented Nov 6, 2022

sakwe commented Nov 6, 2022

michel-nicol commented Nov 6, 2022

sakwe commented Nov 6, 2022

apg1980 commented Nov 7, 2022 •

edited

Loading

Commifreak commented Nov 7, 2022 •

edited

Loading

Commifreak commented Nov 7, 2022

michel-nicol commented Nov 7, 2022

Commifreak commented Nov 7, 2022

Dennis1993 commented Nov 7, 2022

solracsf commented Nov 8, 2022

florian-obradovic commented Nov 8, 2022 •

edited

Loading

michel-nicol commented Nov 8, 2022 •

edited

Loading

szaimen commented Nov 8, 2022

pngn-pro commented Nov 9, 2022

michel-nicol commented Nov 9, 2022 •

edited

Loading

come-nc commented Nov 10, 2022

blizzz commented Nov 10, 2022

mnicol53 commented Nov 11, 2022

michel-nicol commented Nov 13, 2022

aknauss commented Mar 28, 2023

szaimen commented Mar 28, 2023

Quax1507 commented Apr 6, 2023

florian-obradovic commented May 24, 2023 •

edited

Loading

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

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

Comments

sakwe commented Nov 6, 2022 • edited Loading

⚠️ This issue respects the following points: ⚠️

Bug description

Steps to reproduce

Expected behavior

Installation method

Operating system

PHP engine version

Web server

Database engine version

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

Are you using the Nextcloud Server Encryption module?

What user-backends are you using?

Configuration report

List of activated Apps

Nextcloud Signing status

Nextcloud Logs

Additional info

michel-nicol commented Nov 6, 2022

sakwe commented Nov 6, 2022

michel-nicol commented Nov 6, 2022

sakwe commented Nov 6, 2022

apg1980 commented Nov 7, 2022 • edited Loading

Commifreak commented Nov 7, 2022 • edited Loading

Commifreak commented Nov 7, 2022

michel-nicol commented Nov 7, 2022

Commifreak commented Nov 7, 2022

Dennis1993 commented Nov 7, 2022

solracsf commented Nov 8, 2022

florian-obradovic commented Nov 8, 2022 • edited Loading

michel-nicol commented Nov 8, 2022 • edited Loading

szaimen commented Nov 8, 2022

pngn-pro commented Nov 9, 2022

michel-nicol commented Nov 9, 2022 • edited Loading

come-nc commented Nov 10, 2022

blizzz commented Nov 10, 2022

mnicol53 commented Nov 11, 2022

michel-nicol commented Nov 13, 2022

aknauss commented Mar 28, 2023

szaimen commented Mar 28, 2023

Quax1507 commented Apr 6, 2023

florian-obradovic commented May 24, 2023 • edited Loading

sakwe commented Nov 6, 2022 •

edited

Loading

apg1980 commented Nov 7, 2022 •

edited

Loading

Commifreak commented Nov 7, 2022 •

edited

Loading

florian-obradovic commented Nov 8, 2022 •

edited

Loading

michel-nicol commented Nov 8, 2022 •

edited

Loading

michel-nicol commented Nov 9, 2022 •

edited

Loading

florian-obradovic commented May 24, 2023 •

edited

Loading