Server: ldap_search(): Search : Critical extension is unavailable on v19.0.0

[rgl1234]

Hello
I think that I faced the following error-messages for the first time after upgrading to Nextcloud V19. Any Idea where they could come from?

[blizzz]

@rgl1234 please use the issue template. Important information is missing, e.g. PHP version, LDAP settings, logs… Also, which LDAP server do you run?

[kesselb]

As reference:

• https://github.com/Adldap2/Adldap2/issues/274 (a possible solution)
• https://help.nextcloud.com/t/php-ldap-search-search-critical-extension-is-unavailable-at-var-www-nextcloud-apps-user-ldap-lib-ldap-php-341/87848 (same problem)

[kesselb]

Index: apps/user_ldap/lib/Access.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- apps/user_ldap/lib/Access.php   (revision 09e6b26bdd5d30c27e0da9576f5ead139634b33d)
+++ apps/user_ldap/lib/Access.php   (date 1595358227845)
@@ -1955,7 +1955,7 @@
            return;
        }
        $cr = $this->connection->getConnectionResource();
-       $this->invokeLDAPMethod('controlPagedResult', $cr, 0, false);
+       $this->invokeLDAPMethod('controlPagedResult', $cr, 1000, false);
        $this->getPagedSearchResultState();
        $this->lastCookie = '';
    }

Does that work?

[blizzz]

Adldap2/Adldap2#274 (a possible solution)

:sob:

A sequence of paged search requests is abandoned by the client
sending a search request containing a pagedResultsControl with the
size set to zero (0) and the cookie set to the last cookie returned
by the server.

https://tools.ietf.org/html/rfc2696 That's an RFC they drafted themselves.

[kylejtuck]

The fix above did not resolve the errors.

Steps to reproduce
1) Configure LDAP User and Group backend

Expected behaviour / Actual behaviour
Things actually work, except that the logs are filled with error messages when cron runs (though not every time).

Server configuration
_Operating system:_ CentOS 7.8

_Web server:_ Apache/2.4

_Database:_ MariaDB 5.5.65

_PHP version:_ Currently 7.3, but experienced same under 7.4

_Nextcloud version: (see Nextcloud admin page)_ 19.0.1 (but same under 19.0.0)

_Updated from an older Nextcloud/ownCloud or fresh install:_ Both fresh 19.0.0 and upgraded 19.0.1

_Where did you install Nextcloud from:_ source

_Signing status:_ No errors have been found.

_App list:_
Enabled:

• accessibility: 1.5.0
• activity: 2.12.0
• admin_audit: 1.9.0
• bruteforcesettings: 1.6.0
• cloud_federation_api: 1.2.0
• comments: 1.9.0
• contactsinteraction: 1.0.0
• dav: 1.15.0
• documentserver_community: 0.1.7
• drawio: 0.9.7
• external: 3.6.0
• extract: 1.2.4
• federatedfilesharing: 1.9.0
• files: 1.14.0
• files_external: 1.10.0
• files_mindmap: 0.0.22
• files_pdfviewer: 1.8.0
• files_rightclick: 0.16.0
• files_sharing: 1.11.0
• files_trashbin: 1.9.0
• files_videoplayer: 1.8.0
• groupfolders: 6.0.6
• guests: 1.4.6
• logreader: 2.4.0
• lookup_server_connector: 1.7.0
• nextcloud_announcements: 1.8.0
• notifications: 2.7.0
• oauth2: 1.7.0
• onlyoffice: 4.3.0
• polls: 1.4.3
• privacy: 1.3.0
• provisioning_api: 1.9.0
• recommendations: 0.7.0
• serverinfo: 1.9.0
• settings: 1.1.0
• support: 1.2.1
• systemtags: 1.9.0
• text: 3.0.1
• theming: 1.10.0
• twofactor_backupcodes: 1.8.0
• updatenotification: 1.9.0
• user_ldap: 1.9.0
• viewer: 1.3.0
• workflowengine: 2.1.0

_Config report:_
{
"system": {
"instanceid": "REMOVED SENSITIVE VALUE",
"passwordsalt": "REMOVED SENSITIVE VALUE",
"secret": "REMOVED SENSITIVE VALUE",
"trusted_domains": [
"my.domain"
],
"datadirectory": "REMOVED SENSITIVE VALUE",
"dbtype": "mysql",
"version": "19.0.1.1",
"overwrite.cli.url": "https:\/\/my.domain\/nextcloud",
"dbname": "REMOVED SENSITIVE VALUE",
"dbhost": "REMOVED SENSITIVE VALUE",
"dbport": "",
"dbtableprefix": "oc_",
"mysql.utf8mb4": true,
"dbuser": "REMOVED SENSITIVE VALUE",
"dbpassword": "REMOVED SENSITIVE VALUE",
"installed": true,
"memcache.local": "\OC\Memcache\APCu",
"memcache.distributed": "\OC\Memcache\Redis",
"redis": {
"host": "REMOVED SENSITIVE VALUE",
"port": 6379
},
"memcache.locking": "\OC\Memcache\Redis",
"simpleSignUpLink.shown": false,
"ldapIgnoreNamingRules": false,
"ldapProviderFactory": "OCA\User_LDAP\LDAPProviderFactory",
"mail_from_address": "REMOVED SENSITIVE VALUE",
"mail_smtpmode": "smtp",
"mail_sendmailmode": "smtp",
"mail_domain": "REMOVED SENSITIVE VALUE",
"app_install_overwrite": [
"documentserver_community",
"files_external_gdrive"
],
"maintenance": false,
"loglevel": 2,
"log_rotate_size": 5242880
}
}

_Are you using external storage:_ No

_Are you using encryption:_ yes (https)/no (no encryption within NC)

_Are you using an external user-backend, if yes which one:_ LDAP

_LDAP configuration:_ LDAP user and group backend version is 1.9.0
Lots of information I would rather not share, but the LDAP backend is AD. I am using custom LDAP filters. Some values:

ldapExpertUsernameAttr: sAMAccountName
user filter includes: (&(cn=*)(|(memberOf:1.2.840.113556.1.4.1941:=base security group name)(another group)))

So, after saying all that, I just recently started noticing those errors. My LDAP settings did not change. I have tried a variety of methods to resolve the issue (installing fresh 19.0.0 including clean database, rolling PHP back to 7.3, modification of the Access.php file as described above).

Note that cron.php is involved in the errors. With "Background jobs" set to AJAX, these errors do not appear. Obviously that is not ideal, and there are some tasks that do not run when it's set to AJAX.

[blizzz]

Index: apps/user_ldap/lib/Access.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- apps/user_ldap/lib/Access.php (revision 09e6b26bdd5d30c27e0da9576f5ead139634b33d)
+++ apps/user_ldap/lib/Access.php (date 1595358227845)
@@ -1955,7 +1955,7 @@
          return;
      }
      $cr = $this->connection->getConnectionResource();
-     $this->invokeLDAPMethod('controlPagedResult', $cr, 0, false);
+     $this->invokeLDAPMethod('controlPagedResult', $cr, 1000, false);
      $this->getPagedSearchResultState();
      $this->lastCookie = '';
  }

Does that work?

This code has not changed. Now the question is which PHP version @rgl1234 runs. If < 7.3, then it don't expect it to be the reason. But with >= 7.3 we use the new API, and this works slightly different. When abandoning, we only set the parameters now, but the search operation is missing that would bring them up to the server.

[blizzz]

@kylejtuck mind trying whether this hack helps?

diff --git a/apps/user_ldap/lib/Access.php b/apps/user_ldap/lib/Access.php
index b93d92b81d..5a3b288720 100644
--- a/apps/user_ldap/lib/Access.php
+++ b/apps/user_ldap/lib/Access.php
@@ -1956,6 +1956,7 @@ class Access extends LDAPUtility {
        }
        $cr = $this->connection->getConnectionResource();
        $this->invokeLDAPMethod('controlPagedResult', $cr, 0, false);
+       $this->invokeLDAPMethod('search', $cr, $this->connection->ldapBaseUsers[0], 'objectclass=*', ['dn'], 1);
        $this->getPagedSearchResultState();
        $this->lastCookie = '';
    }

[kylejtuck]

@blizzz

Well, I spoke to soon about the error not happening at all when "Background jobs" is set to AJAX. They happen far less frequently, and with far fewer entries (fewer than 25 repeats versus hundreds), but they still appear in the log.

I applied the hack above, and by the next cron the errors returned. Also, they were preceded by the following error.

ldap_search(): Failed to create paged result control value: Bad parameter to an ldap routine (-9) at /var/www/html/nextcloud/apps/user_ldap/lib/LDAP.php#341

Immediately after that error are just over 3000 lines of alternating "Critical extension is unavailable"/"Attempt for Paging" errors.

They don't happen on _every_ cron. Still trying to determine a pattern, but it might be every 5th run.

[maxxer]

Someone on the forum reported a possible workaround:

a temporary solution is to switch to the old ldap library in apps/user_ldap/lib/LDAP.php line 46

- if (version_compare(PHP_VERSION, '7.3', '<') === true) {
+ if (true || version_compare(PHP_VERSION, '7.3', '<') === true) {

I haven't tested it myself

[kylejtuck]

@maxxer I applied that on Friday. The errors did stop appearing in the logs, and everything appears to be working OK.

But as you say, it is a workaround, not a true fix.

[blizzz]

I think I finally managed to reproduce this 💦 This is happening with the new API when user existence checks do not found the record on LDAP anymore. I can dive deep in tomorrow.

Let me use this opportunity to promote https://docs.nextcloud.com/server/latest/admin_manual/configuration_user/user_auth_ldap_cleanup.html

[blizzz]

I have a fix at https://github.com/nextcloud/server/pull/22043, testers welcome <3

[kylejtuck]

I have a fix at #22043, testers welcome <3

Patch applied. Testing underway! :)

[kylejtuck]

Looks promising. Things appear to be working, and the logs remain clear of these errors.

[blizzz]

thanks @kylejtuck :rocket: