[Bug]: Openldap Dynamic groups (slapo-dynlist) members are not added to users groups due to ldap pagination.

artlog commented 1 year ago

⚠️ This issue respects the following points: ⚠️

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

Bug description

We are using openldap dynamic groups with a memberURL that automatically constructs members attributes, this is a openldap 2.5 version with slapo-dynlist.

When browsing users, those groups are found and users belong to groups are listed, but group column is not filled with any of those group. When login with users belonging to groups those dynamic groups are not added to user's group, while other static groups are.

After investigation we spotted ldap pagedresults should be deactivated.

we tried to deactivate ldap pagination using 0 in Paging Chunksize but this is not disabling pagination at all. We didn't find any way to instruct nextcloud to deactivate pagination to retrieve groups.

Steps to reproduce

A)

Have an openldap with dynamic groups. ( If you don't know what it is, you certainly don't have those, since they require a specific configuration ).
Configure correctly nextcloud to use those groups for users.
Log as a user within one of those groups.

what happens : when displaying confiugraiton for user, group does not appear.

B) with A setup, share a folder to a dynamic group

what happens : no user within this group can see the folder.

Expected behavior

A) user should belong to group.

B) user within dynamic group can see the shared folder.

Installation method

Community Manual installation with Archive

Nextcloud Server version

25

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Apache (supported)

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?

[x] Default user-backend (database)
[X] LDAP/ Active Directory
[X] SSO - SAML
[ ] Other

Configuration report

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": {
            "0": "localhost",
            "2": "nextcloud.univ-**REDACTED**.fr"
        },
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "25.0.5.1",
        "overwrite.cli.url": "http:\/\/localhost",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "overwritehost": "nextcloud.univ-**REDACTED**.fr",
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
        "maintenance": false,
        "theme": "",
        "loglevel": 2,
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "tls",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpauth": 1,
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "allow_local_remote_servers": "1",
        "force_language": "fr",
        "force_locale": "fr_FR",
        "updater.release.channel": "stable"
    }
}

List of activated Apps

sudo -u www-data php occ app:list
Enabled:
  - activity: 2.17.0
  - admin_audit: 1.15.0
  - bruteforcesettings: 2.5.0
  - calendar: 4.3.3
  - circles: 25.0.0
  - cloud_federation_api: 1.8.0
  - comments: 1.15.0
  - contacts: 5.2.0
  - contactsinteraction: 1.6.0
  - dashboard: 7.5.0
  - dav: 1.24.0
  - drawio: 2.1.1
  - federatedfilesharing: 1.15.0
  - federation: 1.15.0
  - files: 1.20.1
  - files_markdown: 2.4.0
  - files_mindmap: 0.0.27
  - files_pdfviewer: 2.6.0
  - files_rightclick: 1.4.0
  - files_sharing: 1.17.0
  - files_texteditor: 2.15.0
  - files_trashbin: 1.15.0
  - files_versions: 1.18.0
  - firstrunwizard: 2.14.0
  - impersonate: 1.12.0
  - integration_openproject: 2.3.4
  - logreader: 2.10.0
  - lookup_server_connector: 1.13.0
  - mail: 2.2.5
  - notes: 4.7.2
  - notifications: 2.13.1
  - oauth2: 1.13.0
  - onlyoffice: 7.8.0
  - password_policy: 1.15.0
  - photos: 2.0.1
  - privacy: 1.9.0
  - provisioning_api: 1.15.0
  - recommendations: 1.4.0
  - related_resources: 1.0.4
  - serverinfo: 1.15.0
  - settings: 1.7.0
  - sharebymail: 1.15.0
  - spreed: 15.0.5
  - 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_saml: 5.1.2
  - user_status: 1.5.0
  - viewer: 1.9.0
  - weather_status: 1.5.0
  - workflowengine: 2.7.0
Disabled:
  - cas: 0.2.9
  - deck: 1.8.3
  - encryption
  - files_external: 1.17.0
  - groupfolders: 13.1.2
  - nextcloud_announcements: 1.14.0
  - richdocuments: 7.1.3
  - suspicious_login
  - twofactor_totp

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

We traced openldap exchanges between a ldap request done manually and one done from nextcloud, the only difference was usage of pagination. We confirmed that pagination should not be used and that member attributes were correctly retrieved without pagination. This problem is related to paged result, openldap dynamic groups should not be retrieved with paged result since there is a bug preventing to obtain full result. This bug is officialy documented in openldap man page for 2.5 : https://man7.org/linux/man-pages/man5/slapo-dynlist.5.html See BUG quoting it 'Filtering on dynamic groups may return incomplete results if the search operation uses the pagedResults control.' Result are more than incomplete, there is just no member at all returned. This bug won't be fixed soon in openldap, so we tried to deactivate ldap pagination using 0 in Paging Chunksize but this is not disabling pagination at all.

Main problem here at nextcloud side is that there is no way to deactivate ldap pagination.

come-nc commented 8 months ago

You can disable pagination on LDAP server side, no?

joshtrichards commented 2 months ago

Main problem here at nextcloud side is that there is no way to deactivate ldap pagination.

We didn't find any way to instruct nextcloud to deactivate pagination to retrieve groups.

Our ldap implementation has an ldapPagingSize parameter (defaults to 500) though I must admit I've never used it.

nextcloud-command commented 1 month ago

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.

nextcloud / server