Dovecot auth timeouts caused by LDAP referrals from Samba DC (NS7 to NS8 migration)

Bug
,
1

I have been experiencing similar issues after migrating mail and samba DC from NS 7 to NS 8. Login attempts from dovecot via ldap time out, no user is able to log in:

2026-07-07T04:59:58+02:00 [1:mail3:dovecot] auth: Error: auth-worker: Aborted PASSV request for oliver: Lookup timed out
2026-07-07T04:59:58+02:00 [1:mail3:dovecot] auth-worker(3795): conn unix:auth-worker (pid=507,uid=90): auth-worker<1>: ldap(oliver,5.149.18.5,<xxxxxxxxx>): Shutting down
2026-07-07T04:59:58+02:00 [1:mail3:dovecot] auth-worker(3795): Warning: conn unix:auth-worker (pid=507,uid=90): Auth master disconnected us while handling request for oliver for 60 secs (result=FAIL)

Digging into this, I found that this is related to ldap referrals being returned from Samba:

ldapsearch ... "(objectClass=referral)"
# extended LDIF
#
# LDAPv3
# base <dc=directory,dc=mydomain,dc=com> with scope subtree
# filter: (objectClass=referral)
# requesting: ALL
#


# search reference
ref: ldaps://directory.mydomain.com/CN=Configuration,DC=directory,DC=mydomain,DC=c
om


# search reference
ref: ldaps://directory.mydomain.com/DC=DomainDnsZones,DC=directory,DC=mydomain,DC=
com


# search reference
ref: ldaps://directory.mydomain.com/DC=ForestDnsZones,DC=directory,DC=mydomain,DC=
com


# search result
search: 2
result: 0 Success


# numResponses: 4
# numReferences: 3

Dovecot works if I

  • Bypass ldapproxy and contact samba directly in /etc/dovecot/userdb.conf.ext or
  • Limit the search base to “CN=users,DC=directory,DC=mydomain,DC=com” in /etc/dovecot/userdb.conf.ext

However, both of these solutions are temporary and wouldn’t survive a container restart.

Changing the port as suggested above is also not an option since the internal samba in NS doesn’t allow this.

The solution that works for me is adding a custom configuration file in /etc/dovecot/local.conf.d/ with this content:

import_environment = $import_environment LDAPREFERRALS=:false

Since the ldapproxy documentation on GitHub - NethServer/ns8-ldapproxy: LDAP proxy based on nginx for NS8 · GitHub explicitly states that ldap referrals will fail to work, I think that nethserver should make sure that dovecot doesn’t follow them.

1 Like
NS8 Mail AD Auth failing
2

Thanks for the detailed analysis — the reasoning is sound, and disabling referral chasing in Dovecot makes sense given that ldapproxy explicitly doesn’t support referrals.

Still, I don’t grasp why other NS7 → NS8 migrations didn’t hit this issue: referrals for Configuration and the DNS zone partitions are standard AD behavior, so I’d expect the timeout to be widespread — yet this is the first report.

What’s the history behind this AD? Was it a plain NS7-created domain, or was it modified at some point with external tools (RSAT, samba-tool, LDAP editors)? That could help us understand whether something specific in this directory triggers the referral chase.

Run also this command

runagent -m mail3 podman exec dovecot getent hosts directory.mydomain.com

What is the IP that name resolves to? Is it the DC one, or 127.0.0.1?

3

referrals for Configuration and the DNS zone partitions are standard AD behavior

Ok, I didn’t know this. I assumed they were added by some custom configuration we did.

What’s the history behind this AD?

There have been a number of custom modifications over the years. Most notably we added RFC2307 extensions (https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD) which were edited by LDAP Account Manager ( Easy LDAP management ).

We also added a samba instance running on a different host as secondary domain controller (but it was demoted before the NS7 to NS8 migration).

During the migration, after only mail was migrated and the AD was still on NS7, dovecot worked fine.

Run also this command

runagent -m mail3 podman exec dovecot getent hosts directory.mydomain.com

It resolves to 127.0.0.1

1 Like
4

Thanks for the background — the RFC2307 extensions and the demoted secondary DC are good to know, though I don’t think they’re the cause: those partition referrals are standard AD behavior, so they should be present on every Samba-backed install.

The getent result showing 127.0.0.1 is actually the expected outcome: in the past we applied a workaround for the AD zone resolver, apparently related to the issues linked below. So when libldap chases the referral, it opens a new connection to ldaps://127.0.0.1:636, outside the ldapproxy path. What puzzles me is the timeout itself: if the DC runs on a different node than Mail, the connection to 127.0.0.1:636 should be refused immediately; if the DC runs on the same node, the TLS handshake should fail immediately because the certificate is self-signed. In both cases I’d expect a fast, explicit failure — not a 60-second hang. So I’m still missing what exactly happens on your side.

That said, even without fully understanding the timeout, the fact that disabling referral chasing fixes it — combined with ldapproxy explicitly not supporting referrals — convinces me it’s the right solution for everyone: there’s no legitimate reason for Dovecot to chase referrals in this architecture.

I also did a quick check on my office server, and this fits perfectly with two past issues, probably making their workarounds obsolete:

The DNS flood we observed there could well have originated from LDAP referral chasing.

If tests confirm all of the above, REFERRALS off will be shipped in a next release.

One last detail: the : in LDAPREFERRALS=:false looks like a typo — the plain form should be LDAPREFERRALS=false (or off). Since it worked for you, libldap is apparently tolerant of the value, but I’d avoid copying that syntax into a permanent fix.

5

In my setup it returns a valid letsencrypt certificate (for *.directory.mydomain.com and directory.mydomain.com)

One last detail: the : in LDAPREFERRALS=:false looks like a typo

Thanks for the heads up (note to self: don’t copy AI answers without double-check). And yes, it also works without the colon.

1 Like
6

Filed a bug here: Dovecot chases AD LDAP referrals with unexpected direct connections to port 636 · Issue #8097 · NethServer/dev · GitHub