cron.php generates gygabites of traffic from LDAP server

[pacija]

Hi,

I have recently noticed a huge spike in traffic (more than 1Gb each 5 minutes) between nextcloud and LDAP server. This stopped after disabling cron (run from system's crontab).

What would be the reason for nextcloud to start requesting so much data from Active Directory? Could this be a bug?

OS: FreeBSD 12.1-RELEASE (both host and jail)
Nextcloud: 19.0.1

Thank you in advance,

[kesselb]

Sounds similar to #15171.

cc @nextcloud/ldap

[YeroDog]

Same Problem (like in #15171), it's a fresh 19.0.1 installation.
Around ~1500 user, ldap auth against an UNIVENTION Server (UCS).

The cron runs via crontab every 15 minutes but after several hours i notice a second (or even third) cron.php.

It has an impact on cpu time and also generates a lot of internal traffic, around 17mbps.

I can't say exactly when it occurs, but after a restart I have about half a day until it starts again to generate this unusual traffic.

[pacija]

As for my problem, I have solved it by changing manual LDAP filters which were carried over from OwnCloud installation years ago.

My LDAP server is Active Directory.

Unfortunately I don't have old filters, but new ones are almost identical to ones in official documentation.

Users:

(&(objectclass=organizationalPerson)(memberof=CN=owncloud_users,OU=Groups,DC=example,DC=org))

Login Attributes:

(&(objectclass=organizationalPerson)(memberof=CN=owncloud_users,OU=Groups,DC=example,DC=org)(samaccountname=%uid))

Old filters didn't cause excessive traffic before.

[peschuster]

I have the same issue.
What I found out is that NC searches for a user with a base DN of my groups:

initializing paged search for filter member=cn=<DN of user>, base ou=<base DN of groups>, attr ["member","cn","dn"], limit 100, offset 3865510200

This seems to happen in an endless loop.
Any idea where this query comes from?
My logs we're completely flooded with this line, so I don't have any context, a part from it being triggered by cron.php

[szaimen]

Let us track this in #15171