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:

• Doing another search after paginated search causes 'Critical extension is unavailable' Error Adldap2/Adldap2#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)

😭

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.