Active Directory integration: "Operations Error" during paged search

Symptom

The Active Directory integration source is shown as unhealthy and each sync ends right after it starts with 0 records:

This logs from Monosync integration logs.

[source] is not healthy because [Error]"Operations Error"
   at Novell.Directory.Ldap.LdapSearchResults.NextAsync(CancellationToken ct)
   at MonoSync.Providers.Helpers.PagedResultsControlHandler.RetrievePageAsync(...)
   at MonoSync.Providers.MSPIActiveDirectory.FetchDataAsync(String schema)

Cause

The source uses port 389 with the domain root as Base DN (for example DC=example,DC=local). A search from the domain root on 389 makes Active Directory return referrals to its other partitions (DomainDnsZones, ForestDnsZones, Configuration). MonoSync follows them, and the referral connection fails, so AD answers with "Operations Error" (LDAP result code 1). Referrals are normal AD behaviour; the failure happens only when they cannot be followed.

Solution

• The Global Catalog does not return referrals, so the search completes normally.

• For LDAPS use 3269 together with SSL.

• With several domain controllers, use a DC that is a Global Catalog server.

• The Global Catalog holds only the partial attribute set. Common attributes (mail, department, title, manager, userAccountControl, ...) are available; if a rarely used attribute comes back empty, check this first.

Alternative: set Base DN to the OU or container that holds the users instead of the domain root. This also avoids referrals, but users outside that container will be missing.

Quick check

To confirm this is the same problem, run a paged search on port 389 with the same account and Base DN. If the output contains # numReferences: 3, it applies; on port 3268 there are no references.

ldapsearch -x -H ldap://<dc>:389 -D "<bind-user>" -W -b "DC=example,DC=local" -E 'pr=100/noprompt' "(objectClass=user)" dn

Tip: LDAPS

If you get an error on port 636, you can try 3269.