nextcloud / server

☁️ Nextcloud server, a safe home for all your data
https://nextcloud.com
GNU Affero General Public License v3.0
27.56k stars 4.08k forks source link

[Bug]: LDAP Groups cannot be synced from occ cli #46517

Open Bueddl opened 4 months ago

Bueddl commented 4 months ago

⚠️ This issue respects the following points: ⚠️

Bug description

After a fresh install and configuration of the LDAP backend (using occ) verification succeeds using ldap:check-config. Sign-in is possible, however the groups the user is assigned (in fact no LDAP group is recognized) to are not recognized. Neither appear they in group:list nor the Settings UI.

An attempt to force update the group using occ ldap:check-group --update --force succeeds and reports that the group is still available. ldap:check-user --update --force also shows all groups the user has been assigned to, however occ user:info recognizes the user, shows the correct backend and quota but does not show any groups. Also if signed in as the user it is evident that the groups are not recognized indeed.

Going to the LDAP settings and hitting "Verify settings and count the groups" in the "Groups" tab gets rid of all of these problems. Now occ groups:list recognizes the groups as well as occ user:info and the UI.

After having triggered the action once via the GUI adding new groups to LDAP with a subsequent run of ldap:check-group --update --force not only succeeds but also correctly updates users and groups throughout the system without the need to retrigger the "Verify settings and count the groups" action in the UI.

Steps to reproduce

  1. Install nextcloud
  2. Configure LDAP via occ ldap:set-config commands
  3. Verify that groups are available via occ ldap:check-group and do not appear in occ group:list.

Expected behavior

LDAP groups should be available across the system.

Installation method

Community Docker image

Nextcloud Server version

29

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Nginx

Database engine version

PostgreSQL

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

Fresh Nextcloud Server install

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

Configuration report

{
    "system": {
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "dbtype": "pgsql",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "***REMOVED SENSITIVE VALUE***"
        ],
        "mail_smtpmode": "smtp",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "465",
        "mail_smtpsecure": "",
        "mail_smtpauth": true,
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "password": "***REMOVED SENSITIVE VALUE***",
            "port": 6379
        },
        "trusted_proxies": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "version": "29.0.2.2",
        "overwrite.cli.url": "http:\/\/localhost",
        "installed": true,
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "ldapProviderFactory": "OCA\\User_LDAP\\LDAPProviderFactory",
        "maintenance": false,
        "memcache.distributed": "\\OC\\Memcache\\Redis"
    }
}

List of activated Apps

Enabled:
  - activity: 2.21.1
  - bruteforcesettings: 2.9.0
  - calendar: 4.7.8
  - checksum: 1.2.4
  - circles: 29.0.0-dev
  - cloud_federation_api: 1.12.0
  - comments: 1.19.0
  - contacts: 6.0.0
  - contactsinteraction: 1.10.0
  - dashboard: 7.9.0
  - dav: 1.30.1
  - deck: 1.13.1
  - drawio: 3.0.2
  - federatedfilesharing: 1.19.0
  - federation: 1.19.0
  - files: 2.1.0
  - files_downloadlimit: 2.0.0
  - files_external: 1.21.0
  - files_pdfviewer: 2.10.0
  - files_reminders: 1.2.0
  - files_sharing: 1.21.0
  - files_trashbin: 1.19.0
  - files_versions: 1.22.0
  - fileslibreofficeedit: 1.1.0
  - firstrunwizard: 2.18.0
  - forms: 4.2.4
  - groupfolders: 17.0.1
  - impersonate: 1.16.0
  - logreader: 2.14.0
  - lookup_server_connector: 1.17.0
  - mail: 3.7.2
  - nextcloud_announcements: 1.18.0
  - notes: 4.10.0
  - notifications: 2.17.0
  - oauth2: 1.17.0
  - onlyoffice: 9.3.0
  - passman: 2.4.9
  - password_policy: 1.19.0
  - photos: 2.5.0
  - polls: 7.1.3
  - privacy: 1.13.0
  - provisioning_api: 1.19.0
  - recommendations: 2.1.0
  - related_resources: 1.4.0
  - serverinfo: 1.19.0
  - settings: 1.12.0
  - sharebymail: 1.19.0
  - support: 1.12.0
  - survey_client: 1.17.0
  - systemtags: 1.19.0
  - tasks: 0.16.0
  - text: 3.10.0
  - theming: 2.4.0
  - twofactor_backupcodes: 1.18.0
  - twofactor_totp: 11.0.0-dev
  - twofactor_webauthn: 1.4.0
  - unroundedcorners: 1.1.3
  - updatenotification: 1.19.1
  - user_ldap: 1.20.0
  - user_status: 1.9.0
  - viewer: 2.3.0
  - weather_status: 1.9.0
  - workflowengine: 2.11.0
Disabled:
  - admin_audit: 1.19.0
  - encryption: 2.17.0
  - suspicious_login: 7.0.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

No response

Additional info

No response

Bueddl commented 4 months ago

I took a look at the code and found the cause of my issue. When doing the setup, I was missing the attribute ldapGroupMemberAssocAttr of the LDAP config. This results in the LDAP group backend not being enabled: https://github.com/nextcloud/server/blob/master/apps/user_ldap/lib/Group_LDAP.php#L54

A subsequent getGroups on the backend then just results in a empty set of groups: https://github.com/nextcloud/server/blob/master/apps/user_ldap/lib/Group_LDAP.php#L1091

Clicking the "Verify settings and count the groups" button in the UI Wizard then sets the Attribute ldapGroupMemberAssocAttr to member in our case. After that the Backend is enabled and everything works which is why I had to manually press that button just once.

I think occ ldap:test-config should catch that and/or occ:ldap:check-group should report that as well instead of just reporting that the group has been found in LDAP and terminating afterwards.

If interested, I can file PRs to change that. My suggestion would be to test the Group Backend for its state when used in the check-group command and to do the same in test-config.