[Bug]: Cannot find any users with exact match with LDAP second display name

[PVince81]

⚠️ 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.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

When searching for "V01" with share autocomplete disabled (aka exact match), the search code expects me to type the combined display name "V01 (Dept1)" instead of just "V01".

Steps to reproduce

1. Setup LDAP with the following user:

uid=V01,ou=people,dc=nextcorp,dc=local
objectClass: person
objectClass: inetOrgPerson
uid: V01
sn: V01
cn: V01
displayName: V01
userPassword: V01
mail: v01@nextcorp.local
l: Dept1

2. Set "displayName" as user search attribute for LDAP
3. Set the second display name attribute to be "l"
4. Sync the users by running cron
5. Create a folder
6. Share with "V01" => partial match gives a result "V01 (Dept1)"
7. In the sharing page, disable share autocomplete to trigger exact matching
8. Share the folder again with "V01"

Expected behavior

Only match the first display name, not the second one when exact match is enabled.

Installation method

No response

Operating system

No response

PHP engine version

No response

Web server

No response

Database engine version

No response

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

No response

Are you using the Nextcloud Server Encryption module?

No response

What user-backends are you using?

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

Configuration report

No response

List of activated Apps

Enabled:
  - accessibility: 1.10.0
  - activity: 2.16.0
  - calendar: 3.2.0
  - cloud_federation_api: 1.7.0
  - comments: 1.14.0
  - contactsinteraction: 1.5.0
  - dashboard: 7.4.0
  - dav: 1.22.0
  - federatedfilesharing: 1.14.0
  - federation: 1.14.0
  - files: 1.19.0
  - files_external: 1.16.1
  - files_sharing: 1.16.1
  - files_trashbin: 1.14.0
  - files_versions: 1.17.0
  - lookup_server_connector: 1.12.0
  - nextcloud_announcements: 1.13.0
  - oauth2: 1.12.0
  - photos: 1.6.0
  - provisioning_api: 1.14.0
  - recommendations: 1.3.0
  - serverinfo: 1.14.0
  - settings: 1.6.0
  - sharebymail: 1.14.0
  - survey_client: 1.12.0
  - systemtags: 1.14.0
  - theming: 1.15.0
  - twofactor_backupcodes: 1.13.0
  - updatenotification: 1.14.0
  - user_ldap: 1.14.1
  - user_status: 1.4.0
  - viewer: 1.8.0
  - weather_status: 1.4.0
  - workflowengine: 2.6.0
Disabled:
  - admin_audit
  - bruteforcesettings
  - contacts
  - deck
  - email_template_example-0.0.1
  - encryption
  - files_3d
  - files_accesscontrol
  - files_antivirus
  - files_automatedtagging
  - files_downloadlimit
  - files_retention
  - files_texteditor
  - files_versions_s3
  - groupfolders
  - guests
  - mail
  - music
  - officeonline
  - password_policy: 1.14.0
  - previewgenerator
  - ransomware_protection
  - registration
  - richdocuments
  - shareimporter
  - sharepermissions
  - spreed
  - support: 1.7.0
  - suspicious_login
  - terms_of_service
  - testing
  - twofactor_totp
  - user_saml
  - workflow_script

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

This is on master (git 69378e1) but likely on any other version.

This is the stack trace leading to the combination of display name, for reference:

[0] OCA\User_LDAP\User\User->composeAndStoreDisplayName @ /srv/www/htdocs/server/apps/user_ldap/lib/User/User.php:382
[1] OCA\User_LDAP\Access->cacheUserDisplayName @ /srv/www/htdocs/server/apps/user_ldap/lib/Access.php:747
[2] OCA\User_LDAP\Access->ldap2NextcloudNames @ /srv/www/htdocs/server/apps/user_ldap/lib/Access.php:687
[3] OCA\User_LDAP\Access->nextcloudUserNames @ /srv/www/htdocs/server/apps/user_ldap/lib/Access.php:643
[4] OCA\User_LDAP\User_LDAP->getUsers @ /srv/www/htdocs/server/apps/user_ldap/lib/User_LDAP.php:287
[5] OCA\User_LDAP\User_LDAP->getDisplayNames @ /srv/www/htdocs/server/apps/user_ldap/lib/User_LDAP.php:549
[6] OCA\User_LDAP\User_Proxy->getDisplayNames @ /srv/www/htdocs/server/apps/user_ldap/lib/User_Proxy.php:302
[7] OC\User\Manager->searchDisplayName @ /srv/www/htdocs/server/lib/private/User/Manager.php:322
[8] OC\Collaboration\Collaborators\UserPlugin->search @ /srv/www/htdocs/server/lib/private/Collaboration/Collaborators/UserPlugin.php:140
[9] OC\Collaboration\Collaborators\Search->search @ /srv/www/htdocs/server/lib/private/Collaboration/Collaborators/Search.php:72
[10] OCA\Files_Sharing\Controller\ShareesAPIController->search @ /srv/www/htdocs/server/apps/files_sharing/lib/Controller/ShareesAPIController.php:228
[11] OC\AppFramework\Http\Dispatcher->executeController @ /srv/www/htdocs/server/lib/private/AppFramework/Http/Dispatcher.php:225
[12] OC\AppFramework\Http\Dispatcher->dispatch @ /srv/www/htdocs/server/lib/private/AppFramework/Http/Dispatcher.php:133
[13] OC\AppFramework\App::main @ /srv/www/htdocs/server/lib/private/AppFramework/App.php:172
[14] OC\Route\Router->match @ /srv/www/htdocs/server/lib/private/Route/Router.php:298
[15] require_once @ /srv/www/htdocs/server/ocs/v1.php:62
[16] {main} @ /srv/www/htdocs/server/ocs/v2.php:23

The problem is that downstream from user_ldap, the display name is stored as "V01 (Dept1)" so the additional exact matching done in the UserPlugin will expect the compound name.

Now, please note that LDAP always uses a wildcard search and not exact matching, this is why we still need the additional matching in PHP code.

An ideal solution would have LDAP be aware of exact matching and we'd let LDAP take care of the search and trust the results without post-processing.

[PVince81]

Actually, I just tried typing in the full display name "V01 (Dept1)" but there is no result at all, so users can not be found at all.

The technically explanation for this: the search string "V01 (Dept1)" is sent to user_ldap, but user_ldap only searches the first display name field, so returns no result. Then the post-processing cannot do anything.

And if you type "V01", user_ldap will find the result, but the result gets discarded in post-processing because it's not "V01 (Dept1)".

Some wild ideas:

1. Fix the exact match code to strip the parenthesis if we know there's a second display name: it's risky in case of actual display names that contain parenthesis

2. Find a way to defer the combining of the second display name until very late in the Nextcloud code: might need to touch a lot of code paths

other ideas ?

[PVince81]

PR here: #31932

[blizzz]

PR here: #31932

is this closed, then?

[szaimen]

Hi, please update to 24.0.9 or better 25.0.3 and report back if it fixes the issue. Thank you!

My goal is to add a label like e.g. 25-feedback to this ticket of an up-to-date major Nextcloud version where the bug could be reproduced. However this is not going to work without your help. So thanks for all your effort!

If you don't manage to reproduce the issue in time and the issue gets closed but you can reproduce the issue afterwards, feel free to create a new bug report with up-to-date information by following this link: https://github.com/nextcloud/server/issues/new?assignees=&labels=bug%2C0.+Needs+triage&template=BUG_REPORT.yml&title=%5BBug%5D%3A+